Community Based Home Health Special Interest Group

Community Based Home Health Special Interest Group

Meeting Minutes Salt Lake City Utah October 4, 2001

Present John Firl Co-Chair McKesson Inc ()

Bob Barker SIEMENS Health Services, Home Health Division(

John Campbell LACounty Mental Health(

Ric Marshall Health Victoria Austrlia ()

Donni Toth Cognitech (

Old Business:

• Joint Meeting with LAPOCT on October 2, 2001 – This meeting was conducted with SIG IEEE also participating and the following was decided;
• A sub group of CBHS, LAPOCT, and IEEE will conduct a one half day meeting in San Diego to review/create use cases for Point of Care Devices. After use cases are review/approved, the Patient Care TC will review POC message requirements.
• It was agreed between now and the San Diego meeting that emails would be exchanged by HL7 Canada, the Sandia, and AMS groups for the purpose of reviewing Point of care data managers and equipment usage.
• There was a brief review of LAPOCT trigger proposal defined jointly by the point-of-care (POC) Connectivity Industry Consortium (CIC) and the O/O committee recommended. This proposal approach was approved by the TSC at the May 2001 meeting. It was reported that this proposal was anticipated to be used by McKesson Extended Care Solution Division in a proof of concept demo within the year. The proposal explained use of the OUD^R30 (Un-Ordered Observation - Place an Order), ORU^R31 (New Observation – Search for an Order), ORU^R32 (Pre-Ordered Observation) , and the R33 Acknowledgement triggers for POC use cases. Descriptive material from this proposal is included as an appendix A to these minutes.
• We need additional Version 3 ballot story boards for CBHS domain.
• Need to obtain a copy of the document Auto6-a volume 21 # 0 dated July 20, 2001 presented by Charles Hawker or Jeff Perry 610 688-0100 at the LAPOCT joint session.
• Review of previous 05/2001 minutes was done/approved offline by the group’s May attendees since they were not available at today’s meeting and approved.

New Business:

• We had a lengthy discussion on how Behavioral/Mental Health and Occupational Health can implement hl7 for their business needs. John Campbell and Donni Toth were present to discuss this. They both agreed to provide Story Boards for this type of business for the San Diego meeting and to solicit additional attendees representing those Domains. We also discussed using the Outreach program used by the attachments SIG to send letters to individuals to encourage them to attend..
• PAFM has asked for assistance from CBHS to define the artifacts required to support Version 3 outpatient messaging, members of this SIG will be working prior to the San Diego meeting to completed this.

• There is a need for an Implementation Guide to address Behavioral and Mental Health Occupational Health provisions in the HL7 specification. In the past, the Australia members explained how Australia proposed to handle these messaging requirements. Within this proposal there was liberal usage of Z messages, Z segments, Z fields and possibly Z data types. We will ask for a copy of that specification from the Australia hl7 affiliate in order to continue this effort in the United States.
• There is a need to review the CBHS messaging requirements for handling an interface for ordering and shipping supplies.
• Meeting Schedule for San Diego
• One Half day Joint Meeting with LAPOCT
• One Half day CBHS (1:45pm till 8pm)
• Joint Meeting with Attachments.

For San Diego

• Use cases for Behavioral and Mental Health.
• Use cases for Occupational Health.
• Use cases for LAPOCT (POC Devices)
• Review of Outpatient messaging coverage in new V3 ballot material.
• Review of messaging requirements for ordering and shipping supplies.

Appendix A:

ORU^R31 – New Observation – Search for an Order

This use case employs the ORU message with the existing R31 trigger. In this case, the Observation Reviewer does not know if an order has been placed. This message and trigger instruct the Observation Recipient to search for an existing order for the associated results. If the Observation Recipient finds an existing order, it should return the accession number to the Observation Reviewer in the Acknowledgement message.

The institution’s business rules will determine what the Observation Recipient does if it can’t find a matching order, Possibilities include automatically placing an order (as in use case 1), or logging an exception rather than recording the result.

ORU^R31 / Unsolicited Observation Message / Chapter
MSH / Message Header / 2
{
[
PID / Patient Identification / 3
[PD1] / Additional Demographics / 3
[{NTE}] / Notes and Comments / 2
[{NK1[HLS1]}] / Next of Kin/Associated Parties / 3
[
PV1 / Patient Visit / 3
[PV2] / Patient Visit - Additional Info / 3
]
]
{
[ORC] / Order common / 4
OBR / Observations Report ID / 7
{[NTE]} / Notes and comments / 2
[CTD] / Contact Data / 11
{
[OBX] / Observation/Result / 7
{[NTE]} / Notes and comments / 2
}
[{FT1}] / Financial Transaction / 6
{[CTI]} / Clinical Trial Identification / 7
}
}
[DSC] / Continuation Pointer / 2
ACK^R01 / Acknowledgment / Chapter
MSH / Message header / 2
MSA / Message acknowledgment / 2

ORU^R32 – Pre-Ordered Observation

This use case employs the ORU message with the R32 trigger. From a traditional central laboratory perspective, this use case is probably the predominant (if not exclusive) one. However, in the POC environment, it is actually uncommon to have an order already generated when a test is performed. It does happen sometimes, though. In these cases order information is provided by either of the following schemes:

1. The user enters an accession number (to identify the order) at the POC device when performing the test
2. If the device doesn't support that input capability or the accession number isn't known at the POC, the Observation Reviewer (e.g. POC Data Manager retrospectively determines the appropriate order to match to the test result

In either case, the Observation Recipient receives a message containing both the result and the associated order information.

The main motivation for the R32 trigger is to instruct the Observation Recipient to place the result with the order information included in the ORU message.

ORU^R32 / Unsolicited Observation Message / Chapter
MSH / Message Header / 2
{
[
PID / Patient Identification / 3
[PD1] / Additional Demographics / 3
[{NTE}] / Notes and Comments / 2
[{NK1[HLS2]}] / Next of Kin/Associated Parties / 3
[
PV1 / Patient Visit / 3
[PV2] / Patient Visit - Additional Info / 3
]
]
{
[ORC] / Order common / 4
OBR / Observations Report ID / 7
{[NTE]} / Notes and comments / 2
[CTD] / Contact Data / 11
{
[OBX] / Observation/Result / 7
{[NTE]} / Notes and comments / 2
}
[{FT1}] / Financial Transaction / 6
{[CTI]} / Clinical Trial Identification / 7
}
}
[DSC] / Continuation Pointer / 2
ACK^R01 / Acknowledgment / Chapter
MSH / Message header / 2
MSA / Message acknowledgment / 2

Error Handling

Proper usage of the R30 and R32 triggers requires the Observation Reviewer to know something about the state of the Observation Recipient (i.e. whether or not an order has been placed). Such a situation violates general principles for robust messaging system design. However, it is required to support the non-regimented workflow that describes the clinical use model for most point-of-care devices.

As a consequence, it is possible for the Observation Reviewer to transmit erroneous information. The following sections discuss the most common possible sources for these errors and suggest system behavior to deal with these errors. These examples are provided for informative purposes and are not normative.

1. A Result plus Order is submitted with incorrect order information

In this case, the Observation Recipient should generate an exception, returned in the ACK message. The Observation Reviewer is responsible for displaying these exceptions. In a typical hospital POC environment, one of the responsibilities of the Point-of-Care Coordinator is to review these exception lists and try to resolve the problem and resubmit the Result and Order.

1. A Result is submitted without Order information even though an order has been generated

This example represents an unavoidable and unfortunate problem. It can happen if the POC device does not have order input capability, and the Observation Reviewer is unable to match the result to the outstanding order before submitting the message (i.e. failure of the matching heuristic). The consequence is to end up with a result that looks un-ordered, and an order that looks un-resulted. From a POC workflow perspective, it is impossible to avoid this potential problem.

1. An ordered test is submitted as a Result without order

This case represents a failure of the Order-Result matching heuristics. To identify these cases, an Observation Reviewer could log all results that were placed without order information. The POC Coordinator could review this log to determine if any of these results actually had an associated order. Once identified, the cause of the Order-Result matching algorithm’s failure can be identified and fixed.

[HLS1]1 Approved by TC in 00/09 Meeting.

[HLS2]1 Approved by TC in 00/09 Meeting.