PCC-9

Care Management Data Query

This section corresponds to Transaction PCC-9 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-9 is used by the Care Manager and Clinical Data Repository Actors.

Transaction PCC-9 is a variation of the pattern used in transaction PCC-1 of the PCC Technical Framework. Information specific to this transaction is described in futher detail below in the section on Domain Content.

Use Case Roles

Care Manager		Clinical Data Repository
Care Management Data Query

Actor

Care Manager

Role

Requests a collection of clinical data matching the selection criteria from the Clinical Data Repository.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)

Actor

Clinical Data Repository

Role

Returns clinical data matching the selection criteria supplied by the Care Manager.

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

-->>Need to fix this picture<<--

Get Care Record Profile Query

Trigger Events

When the Care Manager needs to obtain information about a patient or population it will trigger a Get Care Record Care Profile event. This cooresponds to the HL7 trigger event: QUPC_TE043100UV

Message Semantics

The Query Care Record Event Profile Query corresponds to the HL7 Interaction QUPC_IN043100UV.

A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN043100UV.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 for PCC-9 is nearly identical to the transmission wrapper used in PCC-1, and appears below.

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_IN043100UV 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_IN043100UV' 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>
 <respondTo typeCode="RSP">
   <entityRsp determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' '/>
   </entityRsp>
 </respondTo><controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN043100UV>

<QUPC_IN043100UV 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_IN043100UV' 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.

<respondTo typeCode="RSP">
<entityRsp determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' '/>

This element may be used to indicate the destination of the response when it is other than the sender of the query. The server and port address where the response is being sent shall appear in a URI in the value attribute of the <telecom> element. This element shall only be used in queries that are requesting a response in HL7 Version 2 format.

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. With the exception of the responsePriorityCode, the controlActProcess element defined for this transaction is identical to the same element defined in PCC-1, PCC-2, PCC-3, PCC-4, PCC-5 and PCC-6.

<controlActProcess moodCode="RQO">
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  
  <queryByParameter>
    <id root=' ' extension=' '/>
    <statusCode code='new'/>
    <responseModalityCode code='R|B'/>
    <responsePriorityCode code='D'/>
    <initialQuantity value=/>
    <initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'/>
    <executionAndDeliveryTime xsi:type="PIVL_TS">
      <phase value="20080601000000"/>
      <period value='24' unit='h|d|wk|mo|a'/>
    </executionAndDeliveryTime>
    <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 identifierr 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|B'/>

The query response may be in real-time (R) or batch (B). When the responseModalityCode is set to batch, an executionAndDeliveryTime element shall be sent to identify the schedule for the responses.

<responsePriorityCode code='D'/>

The query response shall always be deferred.

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

Please note, the initial response to this query may include a large number of clinical statements providing historical data for the patients selected by the query. The use of initialQuantityCode allows the Care Manager to control the amount of historical data that the Clinical Data Source sends.

For Public Comment

There is some question here about what to do with the acknowledgement, should it be delayed until the Care Manager has processed or stored the information. What happens with the remaining data? Is a continuation required to be sent to alert the Clinical Data Source that it can send more data?

<executionAndDeliveryTime xsi:type="PIVL_TS">
<phase value="20080601000000"/>
<period value=' ' unit='h|d|wk|mo|a'/>

The <executionAndDeliveryTime> element shall be sent when the responseModalityCode is batch (B). It shall not be sent when the responseModalityCode is real-time (R). The data type for this element shall be set to PIVL_TS to indicate that the batches are to be returned periodically. The period between batches shall be specified in the <period> element, using the unit values described above. The <phase> element may be sent to indicate the time window in which the batch response is expected, either as a single value to indicate the time at which it is scheduled, or as an interval (using <high> and <low> elements) marking the time window in which the response can be sent. Responders will make their best efforts to respond according to the schedule specified, but this profile does not guarantee that they must respond in the specified time frame.

The phase of the schedules is aligned to the appropriate calendar component matching the units specified. To request a batch message to be sent on the first of each month, set the phase to indicate the first day of any month, and the units to "mo".

For Public Comment

How critical is it to address time zone shifts during daylight savings time vs. standard time? If so, how would you recommend dealing with this issue? Is is necessary for the reciever to always be able to expect a message at 1am local time, or is it OK for the reciever to get the message at 1am at some times of the year, and at 2am at others?

Parameter List

The parameterList element describes the data being requested. At least one of these elements shall be present in the queryByParameter element. When multiple parameterList elements are included, the data returned by the Clinical Data Repository will concist of all data meeting the criteria in any of the parameterList elements.

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 Consumer column indicates whether the Care Manager must send this parameter. The Repository column indicates whether the Data Repository must support this parameter.

A Care Manager may supply parameters other than those required by this profile, but must appropriately handle any detected issue alert raised by the Data Repository in its response.

Query Parameters

Parameter Name	Cardinality	Data Type	Vocabulary Domain	Consumer	Repository
careProvisionCode	0..1	CD		O	R
careProvisionReason	0..*	CD		O	O
careRecordTimePeriod	0..1	IVL<TS>		O	R
clinicalStatementTimePeriod	0..1	IVL<TS>		O	R
includeCarePlanAttachment	0..1	BL		R	R
maximumHistoryStatements	0..1	INT		O	R
patientAdministrativeGender	0..1	CE	AdministrativeGender	O	R
patientBirthTime	0..1	TS		O	R
patientId	1..1	II		R	R
patientName	0..1	PN		O	R

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

  <parameterList>
    <careProvisionCode>
      <value code='' displayName='' codeSystem='' codeSystemName=''/>
    </careProvisionCode>
    <careProvisionReason>
      <value code='' displayName='' codeSystem='' codeSystemName=''/>
    </careProvisionReason>
    <careRecordTimePeriod>
      <value><low value=''/><high value=''/></value>
    </careRecordTimePeriod>
    <clinicalStatementTimePeriod>
      <value><low value=''/><high value=''/></value>
    </clinicalStatementTimePeriod>
    <includeCarePlanAttachment><value value='true|false'/></includeCarePlanAttachment>
    <maximumHistoryStatements><value value=''/></maximumHistoryStatements>
    <patientAdministrativeGender>
      <value code='' displayName='' 
        codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
    </patientAdministrativeGender>
    <patientBirthTime><value value=''/></patientBirthTime>
    <patientId><value root='' extension=''/></patientId>
    <patientName><value></value></patientName>
  </parameterList>

<parameterList>

At least one <parameterList> element shall be present, and contains a set of query parameters being used in this query.

<careProvisionCode><value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/></careProvisionCode>

This <careProvisionCode> shall be present. This element describes the information that is being looked for in the <value> element.

Specific results or categories of results may be requested using the codes listed in the domain content section below.

<careProvisionReason><value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/></careProvisionReason>

This element identifies the reason why the result was recorded. If specified, only those results which are recorded for the specified reason will be returned.

<careRecordTimePeriod><value><low value=' '/><high value=' '/></value></careRecordTimePeriod>

This element describes the time period over which the results were recorded. A query could for example, request new entries that have been processed for this patient since the last query request. If specified, only those results that were authored within the specified time period will be returned.

<clinicalStatementTimePeriod><value><low value=' '/><high value=' '/></value></clinicalStatementTimePeriod>

This element describes the effective time for the clinical statement. If specified, only those results that were effective within the clinical statement effective time will be returned.

The effectiveTime range of the returned clinical statements shall overlap or be wholely contained within the time range described by the <clinicalStatementTimePeriod> element. In the example below, the clinical statements with the effectiveTime values represented by time ranges B, C and D would be returned, while those with effectiveTime values represented by time ranges A and E would not, because they fall outside of the specified <clinicalStatementTimePeriod> value.

Effective Time and Clinical Statement Time Period

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

The <includeCarePlanAttachment> element shall be sent, and must be set to either true or false depending upon whether care plans should be returned or not. A Data Repository may choose not to honor this request when the value is set to true, but must then raise a BUS detected issue alert to indicate that this capability is not supported. Note that many data repositories will not associate a care plan attachment with a specific result.

<maximumHistoryStatements><value value=' '/></maximumHistoryStatements>

This value indicates the maximum number of each type of result that will be returned by the query. No more than the maximum number will be returned. This value is NOT the maximum number of clinical statements returned, rather it is the maximum number of clinical statements returned for individual type of clinical statement specified in the careProvisionCode. Thus, if all results are requested (e.g., all Vital Signs), and maximumHistoryStatements/value/@value = 1, you will receive the most current value for each kind of result requested (e.g., one each of the most recent value for height, weight, blood pressure, tempurature, et cetera).

For Public Comment

Is maximumHistoryStatements relevant for care management? (Personally I think not)

<patientAdministrativeGender>
 <value code=' ' displayName=' ' codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

The patient gender may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient gender of the patient specified in patientId. If the two values do not match, the Clinical Data Repository will raise a detected issue alert.

<patientBirthTime><value value=' '/></patientBirthTime>

The patient birth time may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient birth time of the patient specified in patientId. If the two values do not match, the Clinical Data Repository will raise a detected issue alert.

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

The patient identifier shall be specified in this element. The root and extension attributes shall be present. When used in cross enterprise settings, the root attribute shall the affinity domain identity OID. To perform a query across a population, the extension attribute may be set to the value '*'.

Sending a query with a known invalid patientId element can be used to ping a Data Repository. For example, setting the root attribute to "0" and omitting the extension attribute should result in a response that raises an ILLEGAL detected issue alert on the patientId field, since the value "0" will never be used as the OID of a patient identity domain. This capability can be used by a Care Manager to verify that it can connect to a Data Repository when configuration parameters are modified.

<patientName><value></value></patientName>

The patient name may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient name of the patient specified in patientId. If the two values do not match, the Data Repository will raise a detected issue alert.

This element shall not be sent when a patient population is queried.

Expected Actions -- Care Manager

The Care Manager shall send a query as specified in the QUPC_IN043100UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.

The Care Manager shall send an audit message to the audit log repository indicating that a query was initiated, and the parameters of query that were supplied (see the queryByParameter element above).

Expected Actions -- Clinical Data Source

The Clinical Data Source shall send an acknowledgement of the query as specified in the HL7 MCCI_IN000002UV01 interaction in the response to the query message, and shall trigger a QUPC_TE043200UV event to initiate the sending of historical data for all matching patients (see below).

The Clinical Data Source shall send an audit message to the audit log repository indicating that a query was recieved, and the parameters of query that were supplied (see the queryByParameter element above).

The name of the query message shall be QUPC_IN043100UV_Message in the WSDL. The name of the acknowledgement response message shall be MCCI_IN000002UV01 in the WSDL.

The following WSDL snippet defines the types used for this transaction:

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_IN043100UV.xsd"/> <xsd:include namespace="urn:hl7-org:v3" schemaLocation="MCCI_IN000002UV01.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_IN043100UV_Message'> <part element='hl7:QUPC_IN043100UV' name="Body"/> </message> <message name='MCCI_IN000002UV01_Message'> <part element='hl7:MCCI_IN000002UV01' name="Body"/> </message>

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

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-1

WSDL Item	Value
wsdl:definitions/@name	CareManager
Get Care Record Query	QUPC_IN043100UV_Message
Message Acknowledgement	MCCI_IN000002UV01_Message
portType	CareManager_PortType
Query Operation	CareManager_QUPC_IN043100UV
SOAP 1.1 binding	CareManager_Binding_Soap11
SOAP 1.1 port	CareManager_Port_Soap11
SOAP 1.2 binding	CareManager_Binding_Soap12
SOAP 1.2 port	CareManager_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 Care Manager actor can be found at ftp://ftp.ihe.net/TF_Implementation_Material/PCC/CareManager.wsdl. For a general description of the WSDLs for PCC see the Appendix of the same name in this volume.

Port Type

Port Types for PCC-1

<portType name="CareManager_PortType"> <operation name="CareManager_QUPC_IN043100UV"> <input message="tns:QUPC_IN043100UV_Message" wsaw:Action="urn:hl7-org:v3:QUPC_IN043100UV"/> <output message="MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/> </operation> </portType>

Bindings

SOAP 1.2 Binding for PCC-1

<binding name="CareManager_Binding_Soap12" type="CareManager_PortType"> <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="CareManager_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.1 Binding for PCC-1

<binding name="CareManager_Binding_Soap11" type="CareManager_PortType"> <wsoap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="CareManager_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>