PCC-10
V3 Care Management Update
This section corresponds to Transaction PCC-10 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-10 is used by the Care Manager and Clinical Data Repository Actors.
Transaction PCC-10 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 | |
 V3 Care Management Update | ||
- Actor
- Care Manager
- Role
- Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction 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
- Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)
Referenced Standards
Interaction Diagrams
Get Care Record Profile Response
Trigger Events
This message is triggered upon reciept of a Query Care Record Event Profile Query Message. This corresponds to HL7 trigger event: QUPC_TE043200UV
Message Semantics
The Get Care Record Profile Response corresponds to the HL7 Interaction QUPC_IN043200UV. A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN043200UV.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. This message wrapper is similar to the transmission wrapper used for the same interaction in PCC-1, save that the acceptAckCode is different.
<QUPC_IN043200UV 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_IN043200UV' 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_IN043200UV>
<QUPC_IN043200UV 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_IN043200UV' 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 reciever wants to recieve an acknowledgement, and shall be sent as shown above. Query responses in this transaction shall require an acknowledgement.
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=' '/> <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 or continuation response.
<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'. If the value is 'aborted', no additional messages should be sent to the data repository for the specified query.
<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 results were located. 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.
<resultCurrentQuantity value=' '/>
The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.
<resultRemainingQuantity value=' '/>
This resultRemainingQuantity element may be present. It shall enumerate the number of additional results known to follow the results currently returned. Because these queries have long lifetimes, additional results may be added at any time.
Query Response
The <subject> element of the <controlActProcess> element shall appear as shown in the example below.
<subject>
<registrationEvent>
<statusCode code='active'/>
<custodian>
<assignedEntity>
<id root='' extension=''/>
<addr></addr>
<telecom></telecom>
<assignedOrganization>
<name></name>
</assignedOrganization>
</assignedEntity>
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root='' extension=''/>
<addr></addr>
<telecom value='' use=''/>
<statusCode code='active'/>
<patientPerson>
<name></name>
<administrativeGenderCode code='' displayName=''
codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
<birthTime value=''/>
</patientPerson>
</patient>
</recordTarget>
<pertinentInformation3>
<!-- Domain Content -->
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
</subject>
<subject>
The <subject> element shall be present, and is where the results are returned.
<registrationEvent>
At least one <registrationEvent> element shall be be present for each set of records returned from a different custodial source or patient (in the case of population queries).
The <registrationEvent> is used to record the information about how the <careProvisionEvent> being returned was recorded or "registered" in the custodial system. The response to a Care Profile query is a CareProvisionEvent that is constructed in response to the query. This <careProvisionEvent> is transitory in nature, and is has limited "registration" information content.
A Data Repository that aggregates information from two or more other data repositories shall separate the information into multiple <registrationEvent> elements so as to record the different custodians of the information.
<statusCode code='active'/>
The <statusCode> element records the status of the data records. Queries always return active records, not replaced records, so the value of this element shall always be returned as 'active'. Note that an active record may reference the record that it replaces in the result. The replaced record so referenced does not count towards the number of results returned.
<custodian>
The <custodian> element records the data repository that is the custodian, or "owner", of the data record. A Data Repository actor may return records from multiple custodians, but shall separate the data records from each custodian into different <registrationEvent> elements.
<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 data records.
<addr></addr>
The <addr> element shall be present, and shall provide a postal address for the custodian of the data records.
<telecom></telecom>
At least one <telecom> element shall be present that provides a telephone number to contact the custodian of the data records.
A <telecom> element may be present that provides the web service end-point address of the custodian of the data records.
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 data records shall be provided.
<subject2>
The <subject2> element provides the data content requested from the query.
<careProvisionEvent>
The <careProvisionEvent> elements returned by the Care Record Profile Query are compositions based upon the information requested in the query. It is transitory in nature, and does not necessarily coorespond to a single care provision activity stored within the data repository.
<recordTarget>
The <recordTarget> element records information about the patient for whom the Data Repository is returning results.
<patient>
The <patient> element contains information identifying the patient and providing contact information.
<id root=' ' extension=' '/>
At least one <id> element shall be present that identifies the patient. This <id> element shall be the same as the value of the <patientId> passed in the query. Other <id> elements may be present.
<addr></addr>
At least one <addr> element shall be present to provide a postal address for the patient. It may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<telecom value=' ' use=' '/>
At least one <telecom> element shall be present to provide a telephone number to contact the patient. It may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera). Other <telecom> elements may be present to contain other contact methods, e.g., e-mail. One cannot determine from a <telecom> element with the nullFlavor attribute whether it is supposed to contain a telephone number, e-mail address, URL, or other sort of telecommunciations address. Due to this limitation, the assumption will be made that a <telecom> element with a nullFlavor attribute represents a telephone number that is unavailable.
<statusCode code='normal'/>
The <statusCode> element shall be present, and shall be represented exactly as shown above. This indicates that the role of patient is in one of the normal states, e.g., has not been explicitly removed or "nullified".
<patientPerson>
The <patientPerson> element shall be present, and provides further identification information about the patient.
<name></name>
The <name> element shall be present, and normally provides the patient's name. The <name> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<administrativeGenderCode code=' ' displayName=' '
codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
The <administrativeGenderCode> element shall be present, and normally provides the patient's gender using the HL7 AdministrativeGender vocabulary. The <administrativeGender> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<birthTime value=' '/>
The <birthTime> element shall be present, and normally provides the patient's birthTime. The <birthTime> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<pertinentInformation3>
<!-- 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.
Expected Actions -- Clinical Data Source
The Clinical Data Source 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 Clinical Data Source shall populate the message with the appropriate responses using the appropriate templates specified in Care Management Data Query under the <careProvisionCode> query parameter.
Expected Actions -- Care Manager
The Care Manager processes the query response data. The Care Manager shall respond with an acknowledgement as specified in the QUPC_IN043200UV interaction.
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:include namespace="urn:hl7-org:v3"
schemaLocation="MCCI_IN000002UV01.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_IN043200UV_Message'>
<part element='hl7:QUPC_IN043200UV' name="Body"/>
</message>
<message name='MCCI_IN000002UV01_Message'>
<part element='hl7:MCCI_IN000002UV01' name="Body"/>
</message>
General Query Activate Query Continue
Note:
Do we need to address continuations? If not, how will the Care Manager handle "flow control"? Control-S and Control-Q just doesn't seem to cut it