PCC-8

From IHE Wiki
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)


Note: Implementors of a Guideline Manager Actor, Care Manager Actor or a Clinical Data Source Actor shall publish an HL7 Conformance Profile that indicates the vocabularies and code sets that they support for this transaction.


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

Cm3.gif

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
Registration Event Details

The <subject> element of the <controlActProcess> element shall appear as shown in the example below, and provides details on the event that registered the the guideline with the Guideline Manager.

<subject>
  <registrationEvent>
    <statusCode code='active|obsolete'/>
    <custodian>
      <assignedEntity>
        <id root='' extension=''/>
        <addr></addr>
        <telecom></telecom>
        <assignedOrganization>
          <name></name>
        </assignedOrganization>
      </assignedEntity>
    </custodian>
    <subject2>
      <careProvisionEvent classCode='PCPR' moodCode='EVN'>
        <!-- Message Body -->
      </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.

Query Response Content
Note: The following content for careProvisionEvent is identical to that found in PCC-7.


<careProvisionEvent classCode='PCPR' moodCode='EVN'>

An example <careProvisionEvent> element is shown below.

 <careProvisionEvent classCode='PCPR' moodCode='EVN'>
   <replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
     <careProvisionEvent classCode='PCPR' moodCode='EVN'>
       <id root=' ' extension=' '/>  
     </careProvisionEvent>
   </replacementOf>
   <component typeCode='COMP'>
     <carePlan classCode='PCPR' moodCode='INT'>
       <definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
         <guideline classCode='PCPR' moodCode='DEF'>
           <id root=' ' extension=' '/>
           <title></title>
           <text></text>
           <statusCode code='active|obsolete'/>
           <effectiveTime>
             <low value=' '/>
             <high value=' '/>
           </effectiveTime>
           <!-- zero or more components containing acts of care to be monitored -->
           <component2 typeCode='COMP'>
             <!-- One of the following elements -->
             <observationDefinition classCode='OBS' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </observationDefinition>
             <substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </substanceAdministrationDefinition>
             <procedureDefinition classCode='PROC' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </procedureDefinition>
             <encounterDefinition classCode='ENC' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </encounterDefinition>
             <actDefinition classCode='ACT' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </actDefinition>
           </component2>
           <!-- zero or more components containing "sub-guidelines" that make up this guideline -->
           <component3 typeCode='COMP'>
             <!-- The content model for "sub-guidelines" is as for a guideline, with the exception
             that it need not contain an id, title, text, statusCode, or effectiveTime element.  -->
           </component3>
         </guideline>
       </definition>
     </carePlan>
   </component>
 </careProvisionEvent>

The <careProvisionEvent> elements sent by a Guideline Notification transaction, or returned in a Request Guideline Data transaction represent activations or replacements of guidelines. 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 <pertinentInformation2> element.
  • The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation3> 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.

<rule context='hl7:careProvisionEvent[not(../hl7:replacementOf)]'>
  <assert test='count(hl7:component) = 1'>
    A careProvisionEvent shall have only one component containing the guideline.
  </assert>
  <assert test='not(hl7:recordTarget)'>
    The careProvisionEvent shall not contain a recordTarget element.
  </assert>
  <assert test='not(hl7:subject)'>
    The careProvisionEvent shall not contain a subject element.
  </assert>
  <assert test='not(hl7:pertinentInformation1)'>
    Warning: The careProvisionEvent should not contain a pertinentInformation1 element.
  </assert>
  <assert test='not(hl7:pertinentInformation2)'>
    The careProvisionEvent shall not contain a pertinentInformation2 element.
  </assert>
  <assert test='not(hl7:pertinentInformation3)'>
    The careProvisionEvent shall not contain a pertinentInformation3 element.
  </assert>
</rule>
<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>

When a Guideline Notification transaction sends a replacement notification, the <careProvisionEvent> that references the guideline being replaced shall be identified in the <replacementOf> element. The <replacementOf> element shall contain a single <careProvisionEvent> element that shall contain the an <id> element giving the unique identifier of the <careProvisionElement> that was replaced, and which should not contain any other elements.

<rule context='/hl7:REPC_IN004913UV'>
  <assert test='hl7:careProvisionEvent/hl7:replacementOf'>
    A replacement transaction shall contain a replacementOf element identifying 
    the careProvisionEvent being replaced.
  </assert>
</rule>
<rule context='hl7:replacementOf/hl7:careProvisionEvent'>
  <assert test='hl7:id'>
    The careProvisionEvent that is being replaced shall contain an id element.
  </assert>
  <assert test='not(hl7:*[local-name() != "id"])'>
    Warning: The careProvisionEvent that is being replaced should not contain anything other than an id element.
  </assert>
</rule>
<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>

A <careProvisionEvent> shall have only one <component> element, containing only one <carePlan>, represented exactly as shown above.

<rule context='hl7:careProvisionEvent/hl7:component'>
  <assert test='count(hl7:carePlan) = 1'>
    The component of the careProvisionEven shall have one and only one carePlan element.
  </assert>
</rule>
<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>

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>.

<rule context='hl7:carePlan'>
  <assert test='not(*[local-name() != "definition"])'>
    The carePlan element shall be empty of all participants and relations with the exception of the definition element.
  </assert>
  <assert test='count(hl7:definition) = 1'>
    The carePlan element shall have one and only one definition element.
  </assert>
</rule>
<rule context='hl7:definition'>
  <assert test='count(hl7:guideline) = 1'>
    The definition element shall have one and only one guideline element.
  </assert>
</rule>


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

Top level guidelines shall have a unique identifier.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:id'>
    A top level guideline shall have an id element.
  </assert>
</rule>
<title></title>

Top level guidelines shall have a title.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:title'>
    A top level guideline shall have a title element.
  </assert>
</rule>
<text></text>

All guidelines may contain narrative text describing the guideline.

<statusCode code='active|obsolete'/>

Top level guidelines shall have a statusCode value that is either "active" or "obsolete".

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:statusCode'>
    A top level guideline shall have a statusCode element.
  </assert>
</rule>
<rule context='hl7:guideline/hl7:statusCode'>
  <assert test='@code="active" or @code="obsolete"'>
    The statusCode/@code attribute shall be either "active" or "obsolete".
  </assert>
<rule>
<effectiveTime><low value=' '/><high value=' '/></effectiveTime>

Top level guidelines shall contain an <effectiveTime> element that records the time period over which the guideline is effective. It shall contain a <low> element recording at the very least the date upon which the guideline was activated. An obsolete guideline shall contain a <high> element recording the last date upon which the guideline was effective. An active guideline may record the date upon which the guideline is expected to be revised.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:effectiveTime'>
    A top level guideline shall have a effectiveTime element.
  </assert>
</rule>
<rule context='hl7:guideline/hl7:effectiveTime'>
  <assert test='hl7:low and hl7:low/@value'>
    The effectiveTime element shall contain a low element containing a value attribute indicating the time at which
    the guideline became effective.
  </assert>
<rule>
<rule context='hl7:guideline[hl7:statusCode/@code="obsolete"]/hl7:effectiveTime'>
  <assert test='hl7:high and hl7:high/@value'>
    The effectiveTime element in an obsolete guideline shall contain a high element containing a value attribute 
    indicating the time at which the guideline became ineffective.
  </assert>
<rule>
<component2 typeCode='COMP'>

All guidelines are composed (at some level) of one or more definitions for acts of care which are to be monitored by a Care Manager and reported upon by a Clinical Data Source during the provision of care. These may include various observations performed (e.g., Hemoglobin A1C tests), medications or immunizations given or prescribed, procedures performed (e.g., foot care), encounters performed (e.g., eye exam), or other acts of care not elsewhere described above.

<rule context='hl7:guideline'>
  <assert test='count(.//hl7:component2/hl7:*[@moodCode='DEF']) > 0'>
    At least one act of care must be defined at some level beneath a guideline element.
  </assert>
</rule>
<observationDefinition classCode='OBS' moodCode='DEF'>
<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
<procedureDefinition classCode='PROC' moodCode='DEF'>
<encounterDefinition classCode='ENC' moodCode='DEF'>
<actDefinition classCode='ACT' moodCode='DEF'>

One of the above definitions of an act of care shall be present in a <component2> element.

<templateId root=' ' extension=' '/>

Each act of care to be monitored shall indicate the identifier of the template used to report information on that act.

<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
  <assert test='hl7:templateId'>
    A templateId element must appear in the definition.
  </assert>
</rule>

A Guideline Manager actor shall use one the IHE Template identifiers specified for PCC-1 under careProvisionCode to request information profiled in an IHE template to be returned in a PCC-10 transaction. A Clincial Data Source implementing the Care Record option shall report activites to the Care Manager using the Care Record Query Response message using the template identified.

A Guideline Manager actor may include an ActDefinition in the <guideline> to identify the HL7 Version 2 Message Profile to describe the data to be monitored by a Care Manager. A Clinical Data Source implementing the HL7 Version 2 option shall report activities to the Care Manager using the HL7 Version 2 message identified by those ActDefinition elements.

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

Each act of care to be monitored shall contain an identifier for the definition of the act. It shall also contain a code element describing the specific act of care to be monitored. Other features of the specific act allowed by the standard may be provided by the Guideline Manager to further identify the specific acts of care that a Care Manager wants to recieve (e.g., routeCode, targetSiteCode). A Clinical Data Source may use these additional features to limit the number of items it reports, but is not required to review any feature other than the "code" element when making its reports. The Care Manager is expected to use its decision support capabilities to ignore reports that are not relevant to its decision making processes.

<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
  <assert test='hl7:id'>
    An id element must appear in the definition.
  </assert>
  <assert test='hl7:code'>
    An code element must appear in the definition.
  </assert>
</rule>

A Clinical Data Source implementing the Care Record Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-10.

A Clinical Data Source implementing the HL7 Version 2 Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-11.

<component3 typeCode='COMP'>

Guidelines may cover different phases (e.g., pre-operative, post-operative) or perspectives of care (e.g., patient education, diet, medications). A guideline can therefore be constructed of other guideline components, which follow the same pattern as for the top level guideline in the careProvisionEvent, except that these subcomponents need not have a unique identity, a title, a status, or effective time.

<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 GuidelineManger
Get Care Record Query QUPC_IN040100UV_Message
Get Care Record Query Response QUPC_IN040200UV_Message
portType GuidelineManger_PortType
Query Operation GuidelineManger_QUPC_IN043100UV
SOAP 1.1 binding GuidelineManger_Binding_Soap11
SOAP 1.1 port GuidelineManger_Port_Soap11
SOAP 1.2 binding GuidelineManger_Binding_Soap12
SOAP 1.2 port GuidelineManger_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 Repository actor implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2008-2009/resources/cm.zip. For a general description of the WSDLs for Care Management see the Appendix of the same name in this volume.

Port Type
<portType name="GuidelineManger_PortType">
 <operation name="GuidelineManger_QUPC_IN040100UV">
   <input message="tns:QUPC_IN040100UV_Message"
     wsaw:Action="urn:hl7-org:v3:QUPC_IN040100UV"/>
   <output message="tns:QUPC_IN040200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN040200UV "/>
 </operation>
</portType>
Port Types for PCC-8
Bindings
<binding name="GuidelineManger_Binding_Soap12" 
   type="GuidelineManger_PortType">
 <wsoap12:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="GuidelineManger_QUPC_IN043100UV">
   <wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN040100UV"/>
   <input>
     <wsoap12:body use="literal"/>
   </input>
   <output>
     <wsoap12:body use="literal"/>
   </output>
 </operation>
</binding>
SOAP 1.2 Binding for PCC-8
<binding name="GuidelineManger_Binding_Soap11" 
   type="GuidelineManger_PortType">
 <wsoap11:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="GuidelineManger_QUPC_IN040100UV">
   <wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN040100UV"/>
   <input>
     <wsoap11:body use="literal"/>
   </input>
   <output>
     <wsoap11:body use="literal"/>
   </output>
 </operation>
</binding>
SOAP 1.1 Binding for PCC-8