PCC-8

From IHE Wiki
Revision as of 23:47, 19 May 2008 by Kboone (talk | contribs) (New page: === <span ID='PCC-8'>Request Guideline Data</span> === This section corresponds to Transaction PCC-8 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-8 is used by...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Request Guideline Data

This section corresponds to Transaction PCC-8 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-8 is used by the Care Manager and/or Clinical Data Source Actors to request Guideline Data from a Guideline Manager Actor. Transaction PCC-8 is similar in structure to Transaction PCC-1. The difference between PCC-8 and PCC-1 is that where PCC-1 requests clinical information matching the query parameters for a specific patient, the PCC-8 transaction requests a specific care record activating a clinical guideline identified in the query parameters.

Use Case Roles

Care Manager or Clinical Data Source   Guideline Manager
Usecase.png
Request Guideline Data
Actor
Care Manager or Clinical Data Source
Role
Requests the data required to implement a guideline.
Cooresponding HL7 Version 3 Application Roles
Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)
Actor
Guideline Manager
Role
Returns the guideline data required to implement a guideline.
Cooresponding HL7 Version 3 Application Roles
Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)


Referenced Standards

CareRecord HL7 Care Provision Care Record (DSTU)
CareQuery HL7 Care Provision Care Record Query (DSTU)
HL7QI HL7 Version 3 Standard: Infrastructure Management – Query Infrastrucure
HL7WS HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release
SOAP Simple Object Access Protocol Version 1.1 (SOAP 1.1)
SOAP12 Simple Object Access Protocol Version 1.2 (SOAP 1.2)

Interaction Diagrams

Qcdpmo.png

Get Care Record Query

Trigger Events

When a Clinical Data Source actor needs to understand the data needed to respond to a query from a Care Manager, or a Care Manager actor needs to refresh its knowledge about a guideline (e.g., to determine how to update a query for a replaced guideline) it will trigger a Get Care Record Query event. This cooresponds to the HL7 trigger event: QUPC_TE040100UV

Message Semantics

The Query Care Record Event Get Query corresponds to the HL7 Interaction QUPC_IN040100UV.

A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN040100UV.xsd. This schema includes:

  • the transmission wrapper MCCI_MT000100UV01,
  • the control act wrapper QUQI_MT020001UV01, and
  • the message payload QUPC_MT040100UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. 

<QUPC_IN040100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='QUPC_IN040100UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='AL'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN040100UV>
<QUPC_IN040100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<interactionId extension='QUPC_IN040100UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent as shown above.

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

<acceptAckCode code='AL'/>

The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.

Control Act Wrapper

The control act wrapper QUQI_MT020001UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. 

<controlActProcess moodCode="RQO">
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  
  <queryByParameter>
    <id root=' ' extension=' '/>
    <statusCode code='new'/>
    <responseModalityCode code='R'/>
    <responsePriorityCode code='I'/>
    <initialQuantity value=/>
    <initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'>
    <parameterList>
      see Query Parameter List below
    </parameterList>
  </queryByParameter>
</controlActProcess>
<controlActProcess moodCode="RQO">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "RQO" by the sender to indicate a request to perform an action, in this case, a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.

<queryByParameter>

HL7 Version 3 messages that perform a query specify the details of it in the <queryByParameter> element.

<id root=' ' extension=' '/>

The sending system shall specify the identifier of the query. This is the identifier that is used in subsequent continuation or cancel messages.

<statusCode code='new'/>

When passing the parameter list, the <statusCode> element shall be recorded as above to indicate that this is a new query.

<responseModalityCode code='R'/>

The query response shall always be in real-time.

<responsePriorityCode code='I'/>

The query response shall always be immediate.

<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883.5'>

The <initialQuantityCode> shall be sent when <initialQuantity> is sent. The code shall be the identifier of the HL7 artifact that is to be counted (e.g., R-MIM or C-MET identifer). In this profile what is being counted is clinical statements, so the code to use shall be REPC_RM000100UV.

Parameter List

The message supports specification of the data items listed in the table below as query parameters. The first column of this table provides the name of the parameter. The next column indicates the number of times it may occur in the query. The next column indicates the type of data expected for the query parameter. The next column indicates the vocabulary domain used for coded values. The Sender column indicates whether the message sender (a Care Manager or Clinical Data Source actor) must send this parameter. The Reciever column indicates whether the reciever (a Guideline Manager Actor) must support this parameter. If these last two columns contain the value R, then this parameter SHALL be send by actor, and if it is X, then this parameter SHALL NOT be sent by the actor. In this profile, all parameters not explicitly required are prohibited.

Parameter Name Cardinality Data Type Vocabulary Domain Sender Reciever
Query Parameters
careRecordId 1..1 II   R R
patientId 0..0 CD   X X
versionTimeStamp 0..0 TS   X X
includeCarePlanAttachment 1..1 BL   R R
maxHistoryClincialStatements 0..0 INT   X X

An example of the query specification is described in the figure below. 

  <parameterList>
    <careRecordId>
      <value code='' displayName='' codeSystem='' codeSystemName=''/>
    </careRecordId>
    <includeCarePlanAttachment><value value='true'/></includeCarePlanAttachment>
  </parameterList>
<parameterList>

The <parameterList> element shall be present, and contains the set of query parameters being used in this query.


<careRecordId><value root=' ' extension=' '/></careRecordId>

The identifier of the care record event that activated the guideline shall be specified in this element. The root and extension attributes shall be present.

<includeCarePlanAttachment><value value='true'/></includeCarePlanAttachment>

The <includeCarePlanAttachment> element shall be sent and the value shall be true. As guidelines always appear in a Care Record message under the Care Plan, the Care Plan must be present in the response.

Expected Actions -- Care Manager or Clinical Data Source

The clinical data consumer shall send a query as specified in the QUPC_IN040100UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.

The name of the query response message shall be QUPC_IN040100UV_Message in the WSDL. The following WSDL snippet defines the type for this message:

Query Message Type Definition 
<types>
   <xsd:schema elementFormDefault="qualified" 
      targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
    <!-- Include the message schema -->
    <xsd:include namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN040100UV.xsd"/>
  </xsd:schema>
</types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Query Message WSDL Declaration 
<message name='QUPC_IN040100UV_Message'>
  <part element='hl7:QUPC_IN040100UV' name="Body"/>
</message>

Other WSDL declarations required for this transaction are defined under the Domain Content section.

Get Care Record Profile Response

Trigger Events

This message is triggered upon reciept of a Query Care Record Event Get Query. This corresponds to HL7 trigger event: QUPC_TE043200UV

Message Semantics

The Query Care Record Event Get Query Response corresponds to the HL7 Interaction QUPC_IN040200UV. A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN040200UV.xsd. This schema includes:

  • the transmission wrapper MCCI_MT000300UV01,
  • the control act wrapper MFMI_MT700712UV01, and
  • the message payload REPC_MT004000UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper MCCI_MT000300UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.

An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. 

<QUPC_IN040200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='QUPC_IN040200UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='NE'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE"> 
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN040200UV>
<QUPC_IN040200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<interactionId extension='QUPC_IN040200UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent as shown above.

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

<acceptAckCode code='NE'/>

The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement, and shall be sent as shown above. Query responses shall not require acknowledgements.

Control Act Wrapper

The control act wrapper MFMI_MT700712UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. 

<controlActProcess moodCode="EVN">=
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  <subject>
     See Query Response below
  </subject>
  <queryAck>
    <queryId root=' ' extension=' '/>
    <statusCode code=' '/>
    <queryResponseCode code=' '/>
    <resultTotalQuantity value=' '/>
    <resultCurrentQuantity value=' '/>
    <resultRemainingQuantity value=' '/>
  </queryAck>
</controlActProcess>
<controlActProcess moodCode="EVN">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate a response to a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.

<subject>

The <subject> element shall be present to record the responses in a query request.

<queryAck>

The queryAck element is transmitted in any message that is a response to a query, query continuation or query cancellation message.

<queryId root=' ' extension=' '/>

The <queryId> element shall be transmitted in a queryAck element. It shall contain an identifier that was used in the original query message.

<statusCode code=' '/>

The statusCode element in the queryAck element indicates the status of the query. It may contain the value 'deliveredResponse' or 'aborted'.

<queryResponseCode code=' '/>

The queryResponseCode element indicates at a high level the results of performing the query. It may have the value 'OK' to indicate that the query was performed and has results. It may have the value 'NF' to indicate that the query was performed, but no record was found. It may have the value 'QE' to indicate that an error was detected in the incoming query message, or 'AE' to indicate some other application error occurred.

<resultTotalQuantity value=' '/>

The resultTotalQuantity element shall be present and enumerates the number of results found (1). This element gives the count of the total number of results located by the query.

Note: For this use of the query, the resultTotalQuantity value should always be 1
<resultCurrentQuantity value=' '/>

The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.

Note: For this use of the query, the resultCurrentQuantity value should always be 1
<resultRemainingQuantity value=' '/>

This resultRemainingQuantity element shall be present. It shall enumerate the number of results that follow the results currently returned (0).

Note: For this use of the query, the resultRemainingQuantity value should always be 0
Query Response

The <subject> element of the <controlActProcess> element shall appear as shown in the example below. 

<subject>
  <registrationEvent>
    <statusCode code='active|obsolete'/>
    <custodian>
      <assignedEntity>
        <id root='' extension=''/>
        <addr></addr>
        <telecom></telecom>
        <assignedOrganization>
          <name></name>
        </assignedOrganization>
      </assignedEntity>
    </custodian>
    <subject2>
      <careProvisionEvent>
        <component typeCode='COMP'>
          <carePlan>
            <!-- Domain Content -->
          </carePlan>
        </component>
      </careProvisionEvent>
      <parameterList>
      </parameterList>
    </subject2>
  </registrationEvent>
</subject>
<subject>

The <subject> element shall be present, and is where the results are returned.

<registrationEvent>

Only one <registrationEvent> element shall be be present.

The <registrationEvent> is used to record the information about how the <careProvisionEvent> being returned was recorded or "registered" in the custodial system (the Guideline Manager actor) .

<statusCode code='active|obsolete'/>

The <statusCode> element records the status of the data records. Queries return active and obsolete (replaced) records.

<custodian>

The <custodian> element records the custodian, or "owner", of the guideline. A Guideline Manager actor may return records from multiple custodians.

<assignedEntity>

The <assignedEntity> element shall be present, and provides contact and identification information about the <custodian>.

<id root=' ' extension=' '/>

The <id> element shall be present, and shall uniquely identify the custodian of the guideline.

<addr></addr>

The <addr> element shall be present, and shall provide a postal address for the custodian of the guideline.

<telecom></telecom>

At least one <telecom> element shall be present that provides a telephone number to contact the custodian of the guideline. A <telecom> element may be present that provides the web service end-point address of the custodian of the guideline.

For Public Comment How might the web service end-point address be used? Is it a good idea to include it, or should we omit this from the profile?
<assignedOrganization>
 <name></name>
</assignedOrganization>

The name of the organization that is the custodian of the guideline shall be provided.

<subject2>

The <subject2> element provides the data content requested from the query.

<careProvisionEvent>

The <careProvisionEvent> elements returned by the Care Record Query in this transaction represent activations or replacements of guidelines. A guideline is accessed through the <careProvisionEvent> element. This element references a <carePlan> element beneath the <component> relationship. A <careProvisionEvent> shall have only one <component> element, containing only one <carePlan>. The <carePlan> element shall be empty of all participants and relations with the exception of the <definition> of the <carePlan>. The <definition> element contains one and only one <guideline>. That <guideline> is composed of one or more parts in <compent2> and <component3> relationships.


As such these elements shall not contain any of the following participants:

  • The <careProvisionEvent> element SHALL NOT contain a <recordTarget>, as guidelines are not specific to a single patient record.
  • The <careProvisionEvent> element SHALL NOT contain a <subject> element, as guidelines are not specific to a device being maintained.

The <careProvisionEvent> may contain other participants not otherwise prohibited above.

Furthermore, these elements shall not contain any of the following relationships which would be only relevant to a single patient:

  • The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation3> element.
  • The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation2> element.

Furthermore, the <careProvisionEvent> element SHOULD NOT contain a <pertinentInformation1> element, as this information is not directly relevant to the guideline being retrieved.

The <careProvisionEvent> may contain other relationships not otherwise prohibited above, but the use of these elements is not described in this profile.

<care>
 <!-- Domain Content>
<pertinentInformation3>

This data element shall be present. It shall contain one of the data elements found in the Data Repository that matches the specified query parameters. The content of this data element is a care statement that varies depending upon the specific transaction, and is futher defined in the section on Domain Content. Each care statement shall have at least one <author> element that indicates to whom the care statement is attributed. Each care statement may have zero or more <informant> elements that indicates who provided information related to the care statement. See the section below on Authors and Informants for more information on how this information should be recorded.

<parameterList>

The <parameterList> shall be present, and shall contain content that is identical to the <parameterList> passed in the query.

Expected Actions -- Data Repository

The Data Repository shall send a response as specified in the QUPC_IN043200UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V. The name of the query response message shall be QUPC_IN043200UV_Message in the WSDL. The following WSDL snippet defines the type for this message:

Query Response Message Type Definition 
 <types>
   <xsd:schema elementFormDefault="qualified" 
     targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
     <xsd:import namespace="urn:hl7-org:v3"
       schemaLocation="QUPC_IN043200UV.xsd"/>
     <xsd:element name="QUPC_IN043200UV"/>
   </xsd:schema>
 </types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Query Respone Message WSDL Declaration 
 <message name='QUPC_IN040200UV_Message'>
   <part element='hl7:QUPC_IN040200UV' name="Body"/>
 </message>

Other WSDL declarations required for this transaction are defined under the Domain Content section.

Response to a New Query

The Guideline Manager, shall:

  1. Recieve and validate the query message.
  2. Create the response message.
  3. Add an ILLEGAL detected issue alert to the response message if the content is invalid (e.g., does not pass schema validation or is otherwise malformed), and immediately return a response indicating the error, and that the query was aborted. Set the text of the alert to the name of the first data element that is not valid. The Guideline Manager may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the query are not valid.
  4. Add a NAT detected issue alert to the response message if the requesting party is not authorized to perform the query, and immediately return a response indicating the error, and that the query was aborted.
  5. Add a ILLEGAL detected issue alert to the response message if the the data repository does not recognize the identity domain used to identify the guideline. Set the text value on the alert to careRecordId.
  6. If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
  7. Add an ISSUE alert to the response message if at any time during response generation, an application error occurs that prevents further processing. Set the text of the alert to the reason for the application error (e.g., a stack trace or exception message). Set queryAct/statusCode/@code to aborted, and queryAct/responseCode/@code to AE, and return the response.
  8. Query for the guideline requested by the query.
  9. If results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
  10. Set queryAck/statusCode/@code to deliveredResponse.
  11. Add the result to the response.
Raising Alerts

If the content of the request is not valid (e.g., according to the Schema or the rules of this profile), at least on ILLEGAL alert shall be raised indicating the data element that was invalid. A response will be sent indicating that the request was invalid, and no further processing shall be performed.

If the requesting party is not authorized to perform the query, the minimum response shall be sent indicating only that the requested is not authorized to perform the query.

In other cases, all possible alerts shall be accumulated before returning a response to the caller.

This enables Clinical Data Consumer actors to send a test query that will enable them to verify the vocabulary and other request parameters that are desired.

An alert is raised by sending a response containing one or more <reasonOf> elements, coded as shown below. 

<reasonOf>
  <detectedIssueEvent>
    <code code='' displayName='' codeSystem='' codeSystemName=''/>
    <text></text>
    <mitigatedBy>
      <detectedIssueManagement moodCode="RQO">
        <code code='' displayName='' codeSystem='' codeSystemName=''/>
        <text></text>
      </detectedIssueManagement>
    </mitigatedBy>
  </detectedIssueEvent>>
</reasonOf>
<reasonOf>

The <reasonOf> element is required to indicate that an alert has occured.

<detectedIssueEvent>

The details of the alert shall be present in the <detectedIssueEvent> element.

<code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.5.4' codeSystemName='ActCode'/>

The <code> element shall contain ISSUE or one of its descendants from the HL7 ActCode vocabulary.

<text></text>

If a validation or other business rule error occurred, the erroneous parameter shall be identified in <text> element using the element name, and nothing else should be present.

If an application error occured, the <text> element shall contain diagnostic information (e.g., stack trace or exception message).

If the reason for the alert was an unrecognized code (CODE_INVALID), the text element shall contain the name of the erroneous parameter, and may contain a space separated list of OIDs identifying value sets which would be valid.

If the reason for the alert was an unrecognized identifier (KEY204) for the vocabulary used in the careProvisionCode or careProvisionReason element, the text element shall contain the name of the erroneous paramater, and may contain a space separated list of the OIDs for code systems which would be valid.

Expected Actions -- Clinical Data Consumer

The Care Manager or Clinical Data Source processes the query response data. No additional data other than the single requested guideline will be returned, so no provision is made in this profile for continuations or canceling the query.

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-8
WSDL Item Value
wsdl:definitions/@name GuidelineMangerDataSource
Get Care Record Profile Query QUPC_IN043100UV_Message
Get Care Record Profile Response QUPC_IN043200UV_Message
General Query Activate Continue / Cancel QUQI_IN000003UV01_Messsage
portType GuidelineMangerDataSource_PortType
Query Operation GuidelineMangerDataSource_QUPC_IN043100UV
Continue Operation GuidelineMangerDataSource_QUQI_IN000003UV01_Continue
Cancel Operation GuidelineMangerDataSource_QUQI_IN000003UV01_Cancel
SOAP 1.1 binding GuidelineMangerDataSource_Binding_Soap11
SOAP 1.1 port GuidelineMangerDataSource_Port_Soap11
SOAP 1.2 binding GuidelineMangerDataSource_Binding_Soap12
SOAP 1.2 port GuidelineMangerDataSource_Port_Soap12

The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Guideline Manger Data Source actor implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2007-2008/resources/Query.zip. For a general description of the WSDLs for QED see the Appendix of the same name in this volume.

Port Type
<portType name="GuidelineMangerDataSource_PortType">
 <operation name="GuidelineMangerDataSource_QUPC_IN043100UV">
   <input message="tns:QUPC_IN043100UV_Message"
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043100UV"/>
   <output message="tns:QUPC_IN043200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV "/>
 </operation>
 <operation name="GuidelineMangerDataSource_QUQI_IN000003UV01_Continue">
   <input message="tns:QUQI_IN000003UV01_Message"
     wsaw:Action="urn:hl7-org:v3:QUQI_IN000003UV01"/>
   <output message="tns:QUPC_IN043200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV "/>
 </operation>
 <operation name="GuidelineMangerDataSource_QUQI_IN000003UV01_Cancel">
   <input message="tns:QUQI_IN000003UV01_Message"
     wsaw:Action="urn:hl7-org:v3:QUQI_IN000003UV01"/>
   <output message="tns:QUPC_IN043200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV "/>
 </operation>
</portType>
Port Types for PCC-8
Bindings
<binding name="GuidelineMangerDataSource_Binding_Soap12" 
   type="GuidelineMangerDataSource_PortType">
 <wsoap12:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="GuidelineMangerDataSource_QUPC_IN043100UV">
   <wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN043100UV"/>
   <input>
     <wsoap12:body use="literal"/>
   </input>
   <output>
     <wsoap12:body use="literal"/>
   </output>
 </operation>
</binding>
SOAP 1.2 Binding for PCC-8 
<binding name="GuidelineMangerDataSource_Binding_Soap11" 
   type="GuidelineMangerDataSource_PortType">
 <wsoap11:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="GuidelineMangerDataSource_QUPC_IN043100UV">
   <wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN043100UV"/>
   <input>
     <wsoap11:body use="literal"/>
   </input>
   <output>
     <wsoap11:body use="literal"/>
   </output>
 </operation>
</binding>
SOAP 1.1 Binding for PCC-8
Retrieved from "http://wiki.ihe.net/index.php?title=PCC-8&oldid=18225"