PCC-11

V2 Care Management Update

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

Transaction PCC-11 sends the appropriate HL7 Version 2 message defined by the guideline in the Guideline Notification transaction and that was requested in the Care Management Data Query.

The Clinical Data Source actor must be able to understand what kind of HL7 Version 2 message is being requested when interpreting the Care Management Data Query transaction issued by the Care Manager actor. How HL7 messages are described using the HL7 Version 3 act structure is now described below.

To fully describe an HL7 Version 2 message, this profile makes use of two infrastructure attributes specified on all RIM classes, and the <code> element of the act:

The XML fragment below is an act, in definition mood, that describes the definition of acts of interest to a Care Manager. These acts are represented in a <guideline> element as described in the Guideline Notification transaction. An example appears below:

<actDefinition classCode='ACT' moodCode='DEF'>
  <typeId root='2.16.840.1.113883.12.354' extension='ADT_A01'/>
  <templateId root='2.16.840.1.113883.9.2.2'/>
     :
  
</actDefinition>

typeId

Describes the constraints imposed by a message type definition. In HL7 Version 2, Table 354 identifies the message structures (or types of messages) that can be sent using the HL7 Version 2 standard. This table can be found in Chapter 2 (Control/Query) of the HL7 Version 2 standard. The example above describes the message of interest as using message structure ADT_A01, which is used to convey that a patient has arrived at a facility.

templateId

Describes the constraints imposed by a template definition. Conformance profiles introduced in HL7 Version 2 are templates which further constrain a specific message structure. HL7 makes available a registry of conformance profiles that have been registered with HL7 to its members at http://www.hl7.org/memonly/conformance/. In the example given above, the profile identifer is given in the <templateId> element, and identifies the specific HL7 Conformance profile that further constrains the message.

code

Describes the specific event (or act) which is of interest in the code attribute. The value for the code attribute comes from table 3 of the HL7 Version 2 standard, which is identified using the codeSystem value 2.16.840.1.113883.12.3. In the example above, the act is the trigger event, A01 (Admit/Visit Notification). We further specify that the code (A01) used to identify that act comes from version 2.4 of the specified codeSystem.

Having demonstrated how to represent a kind of HL7 message in a guideline, we next demonstrate how it appears in a query, as shown in the example below.

<parameterList>
   :
  <careProvisionCode>
    <value code='A01' codeSystem='2.16.840.1.113883.12.3' codeSystemVersion='2.4'/>
  </careProvisionCode>
</parameterList>

For Public Comment

As you can see, the <parameterList> element above does not completely identify the act that is of interest (the message to be returned by the Clinical Data Source). There are several approaches we have considered to address this: Create a code system whose values are the template identifiers (or Conformance profile identifiers in this example), an use those template identifiers in the code attribute of the <value> element. This is a hack that will work. Allow the meaning of templateId to be context sensitive, so that in the context of a query parameter, a templateId might simply assert that the expected response to the query would be an item matching that templateId, also a hack that will work. Leave the query for an HL7 V2 response as shown above, with the expectation that the specific conformance profile used to respond to the query will be provided out of band. Our expectation is that the V2 Care Mnaagement Update message will initially require out of band configuration in any case, as the Clinical Data Sources using the HL7 Version 2 Option are not be required to support reciept of the Care Management Data Query transaction.

Use Case Roles

Care Manager		Clinical Data Source
V2 Care Management Update

Actor

Care Manager

Role

Recieves the HL7 Version 2 message matching the selection criteria in a prior PCC-9 transaction, or otherwise configured out of band with the Clinical Data Source.

Actor

Clinical Data Source

Role

Sends the HL7 Version 2 message matching the selection criteria found in a prior PCC-9 transaction from the Clinical Data Repository, or preconfigured.

Referenced Standards

HL7V2.3	HL7 Version 2.3 Messaging Standard
HL7V2.3.1	HL7 Version 2.3.1 Messaging Standard
HL7V2.4	HL7 Version 2.4 Messaging Standard
HL7V2.5	HL7 Version 2.5 Messaging Standard
HL7V2.5.1	HL7 Version 2.5.1 Messaging Standard
CareQuery	HL7 Care Provision Care Record Query (DSTU)
MLLP	Minimal Lower Layer Message Protocol, Release 2

Interaction Diagrams

Send Message

Trigger Events

When the indicated trigger event occurs, or at the times scheduled in the Care Management Data Query transaction, the Clinical Data Source shall send an HL7 Version 2 message, or if requested in the query transaction, the next batch of HL7 Version 2 messages to the recipient indicated in the <respondTo> element of the query.

Message Semantics

The semantics of the message are determined by the HL7 Version 2 Conformance Profile that has been specified for use in the guidelines being applied to the specific use of the Care Management profile (see http://www.hl7.org/memonly/conformance/index.cfm).

Expected Actions -- Clinical Data Source

Real-Time Mode

1. Upon detection of a qualifying event, the clinical data source shall produce and send the appropriate HL7 Version 2 message for the event to the recipient indicated in the <respondTo> element of the Care Management Data Query) transaction triggering the notification.
2. The Clinical Data Source shall await an acknowledgement of the message.
3. If errors are noted in any of the messages sent in the batch, an operator will be alterted.

Batch Mode

1. The Clinical Data Source shall take note of qualifying events.
2. At the scheduled time (see <executionAndDeliveryTime> in Care Management Data Query), the clinical data source shall produce the appropriate HL7 Version 2 message for each event noted above identified by the query (and guideline).
3. The Clinical Data Source shall send an HL7 Version 2 Batch message to the recipient indicated in the <respondTo> element of the Care Management Data Query) transaction. This message shall contain all of the HL7 Version 2 messages it produced in the previous step. If no messages are produced, it shall produce an empty HL7 Version 2 batch.
4. The Clinical Data Source shall await an acknowledgement of the batch.
5. If errors are noted in any of the messages sent in the batch, an operator will be alterted.

Message Acknowledgement

The Care Manager shall send an acknowledgement indicating that it has recieved the messages.

Trigger Events

The trigger event for the response is the reciept of a new real-time or batch response from the sender.

Message Semantics

Expected Actions -- Care Manager

Real-Time Mode

The Care Manager will validate the message content, and return an acknowledgement to the sender.

Batch Mode

The Care Manager will validate the message content for each message in the batch, and return batch acknowledgement to the sender. The batch acknowledgement shall contain only negative responses.

Expected Actions -- Clinical Data Source

The Clinical Data Source will correct any errors reported by the Care Manager and will resend the corrected messages at the next opportunity.