Add alert trigger event
Add Unsolicited Observation Message Patient-Device AssociationTrigger Event
V 2.9 HL7 ProposalChange Request ID:
File Name: /
Add_Unsolicited_Patient_Device_Association_Observation_Message_Trigger_Event.doc
Description:Status: / proposed
HL7-Version / 2.9
Chapter/Section / 7.3
Sponsoring Person / Todd Cooper
Sponsoring Business Unit / Breakthrough Solutions Foundry, Inc.
Date Originated: / 2012.05.16
Date HL7 approved:
Backward Compatible:
Forward Compatible:
HL7 Status & Date
Justification Detail
ORU messages are commonly used to communicate the majority of medical device-acquired information. A new usage of ORU messages has been identified that leverages the same static message definitionto support association and disassociation of a patient to one or more health care devices. Numerous existing HL7 v2 messages were considered; however, this was selected because:
- ORU_R01 messages are currently used to communicate both patient identifer and multiple device identifier information
- Additional information may be included such as device configuration (e.g., hardware / software revisions) that is already supported in usages of this message
This message/trigger would be sent by a system that collects and manages patient-device associations to those systems that need to consume such information.
Proposal
See next page.
V3 Implications
none
v2.xml Implications
none
[Based on draft text from version 2.8, currently in ballot 2011.08]
7.3.12 ORU – Unsolicited Alert Observation Message (Event R40)
The R40 trigger event is used for observation reports that include an alertable condition, i.e., for which some timely human or application intervention in patient care may be indicated by the findings. The ORA^R41 provides the application level response to the ORU^R40.
The ORU^R40 message is outside of the order-fulfilling cycle of the ORU and OUL messages with other trigger events, and is supplemental to those order-fulfilling observations. As such, the results conveyed in the ORU^R40 do not replace, edit, or override the results of messages with other trigger events.
The ORU^R40 message represents a unitary alert, which is to be acknowledged as a whole by an ORA message. Multiple alerts requiring separate acknowledgement must be sent as individual messages.
The ORDER_OBSERVATION Segment Group which has OBR-49 value A (Alert provider when abnormal) conveys the alert observation(s). One or more OBX segments in this Segment Group will typically have OBX-8 Interpretation Codes value of LL. HH, or AA. At least one OBR segment shall have OBR-49 value A. Other ORDER_OBSERVATION Segment Groups within the message shall be considered supporting information for the alert observation(s).
An alert observationreport may simply replicate observations conveyed in another observationmessage, e.g., sent in an ORU^R01 (the source observation). In such an instance the ORDER_OBSERVATION Segment Group shall replicate the OBR (and ORC, if present) of the source observation.
An alert observationreporting application may also derive a new alertable observation, e.g., from a combination of other observations from multiple orders, processed by a clinical decision support rule set. In this case, the ORDER_OBSERVATION Segment Group with the alertable observation may use an OBR representing the “order” for clinical decision support, with this instance uniquely identified in the OBR-51 Observation Group ID. Supporting source observations may be conveyed in subsequent ORDER_OBSERVATION Segment Groups in the message using their original OBR information.
If the reporting application can identify a preferred recipient for the alert, that may be conveyed in the PRT segment related to the OBR or OBX (with PRT-4 value RCT “Results Copies To”). This recipient may not be the same as the recipient(s) identified in a source observation. There is no expectation that the reporting application will a priori know a preferred recipient, nor that the receiving application will deliver the alert to the identified recipient (e.g., it may be delivered to an “on-call” clinician in lieu of the identified recipient).
ORU^R40^ORU_R01: Observation Message
Segments / Description / Status / ChapterMSH / Message Header / 2
[{ SFT }] / Software Segment / 2
[UAC] / User Authentication Credential / 2
{ / --- PATIENT_RESULT begin
[ / --- PATIENT begin
PID / Patient Identification / 3
[PD1] / Additional Demographics / 3
[{PRT}] / Participation (for Patient) / 7
[{NTE}] / Notes and Comments / 2
[{NK1}] / Next of Kin/Associated Parties / 3
[{ARV}] / Access Restrictions / 3
[{ / --- PATIENT_OBSERVATION begin
OBX / Observation (for Patient ID) / 7
[{PRT}] / Participation (Observation Participation) / 7
}] / --- PATIENT_OBSERVATION end
[ / --- VISIT begin
PV1 / Patient Visit / 3
[PV2] / Patient Visit - Additional Info / 3
[{PRT}] / Participation (for Patient Visit) / 7
] / --- VISIT end
] / --- PATIENT end
{ / --- ORDER_OBSERVATION begin
[ / --- COMMON_ORDER begin
ORC / Order common / 4
[{PRT}] / Participation (for common order) / 7
] / --- COMMON_ORDER end
OBR / Observations Request / 7
[{PRT}] / Participation (for Observation) / 7
{[NTE]} / Notes and comments / 2
[{ / --- TIMING_QTY begin
TQ1 / Timing/Quantity / 4
[{TQ2}] / Timing/Quantity Order Sequence / 4
}] / --- TIMING_QTY end
[CTD] / Contact Data / 11
[{ / --- OBSERVATION begin
OBX / Observation related to OBR / 7
[{PRT}] / Participation (Observation Participation) / 7
{[NTE]} / Notes and comments / 2
}] / --- OBSERVATION end
[{FT1}] / Financial Transaction / 6
{[CTI]} / Clinical Trial Identification / 7
[{ / --- SPECIMEN begin
SPM / Specimen
[{ / --- SPECIMEN OBSERVATION begin
OBX / Observation (for Patient ID) / 7
[{PRT}] / Participation (Observation Participation) / 7
}] / --- SPECIMEN OBSERVATION end
}] / --- SPECIMEN end
} / --- ORDER_OBSERVATION end
} / --- PATIENT_RESULT end
[DSC] / Continuation Pointer / 2
ACK^R01^ACK : Observation Message
Segments / Description / Status / ChapterMSH / Message header / 2
[{ SFT }] / Software segment / 2
[UAC] / User Authentication Credential / 2
MSA / Message acknowledgment / 2
[{ ERR }] / Error / 2
7.3.13ORA – Observation Report Alert Acknowledgement (Event R41)
This message enables application level acknowledgements in response to the ORU^R40 alert observation message.
The R41 trigger event is used to indicate that the alert observation has been delivered to, and acknowledged by, a clinical user. If the clinical user can be identified, that identity can be conveyed in the PRT segment (with PRT-4 value AAP Alert Acknowledging Provider).
Considering that the alerts may be received by multiple providers, multiple acknowledgements may be returned. The behavior associated with the user acknowledgement may be specified in a local implementation agreement or implementation guide and may be indicated in MSH-21 Message Profile Identifier.
ORA^R41^ORA_R41: Observation Report Alert Acknowledgement
Segments / Description / Status / ChapterMSH / Message Acknowledgment / 2
[{ SFT }] / Software segment / 2
[UAC] / User Authentication Credential / 2
MSA / Message Acknowledgment / 2
[{ ERR }] / Error / 2
[{ PRT }] / Participation (Acknowledging User) / 7
[Based on draft text from 2.9 proposal #715]
IS THIS THE TEXT ACTUALLY QUEUED UP FOR 2.9 BALLOT?
7.3.14 ORU – Unsolicited Device Event Observation Message (Event R42)
The R42 trigger event is used for observation reports that identify a device-sourced event (e.g., transition on an infusion pump between primary and secondary modes of operation) that is relevant to clinical workflow but that does not require a response from a clinician or clinical management system (in which case, an R40 alert message should be used). These events are episodic (vs. periodic), require low latency and appropriate prioritized handling (i.e., should be communicated immediately after the event is signaled), and typically require low transmission bandwidth. R42 messages do not need to provide for an application level response, as does the ORU^R40 message (via the ORA^R41 message).
Use examples of this message include:
- Electronic medication administration record (eMAR) systems that record the pre-programmed transition event of an infusion pump between primary and secondary operational modes, or when it is manually paused and then restarted;
- Clinical decision support systems (CDSS) that track a patient’s progress by monitoring, among other events, ventilator transitions from the primary operational mode to a backup mode (e.g., patient triggered to fully mechanical breaths);
- Clinical information systems that note an event when a patient’s physiological monitor is placed into Standby Mode;
- Computerized Maintenance Management Systems (CMMS) records usage events and technical (non-alert) maintenance events to determine when a piece of equipment should be evaluated for proper operation.
In contrast to ORU^R42, the ORU^R01 message is typically used to periodically report “bulk” or full-disclosure device data that may include event information, albeit not reported in a timely manner and in a way that requires more processing to identify. As mentioned, the ORU^R40 message supports a class of episodic events, but focuses on those alerts and alarms that require some level of clinical response to resolve. The ORU^R42 message explicitly does not require clinical action to be taken in response to receipt of the message.
The OBX-8 field for these messages should be left blank or set to “N” for normal. Any abnormal or other non-normal indications would indicate usage of the ORU^R40 message.
The ORU^R40 message is outside of the order-fulfilling cycle of the ORU and OUL messages with other trigger events, and is supplemental to those order-fulfilling observations. As such, the results conveyed in the ORU^R40 message do not replace, edit, or override the results of messages with other trigger events.
ORU^R42^ORU_R01: Observation Message
Segments / Description / Status / ChapterMSH / Message Header / 2
[{ SFT }] / Software Segment / 2
[UAC] / User Authentication Credential / 2
{ / --- PATIENT_RESULT begin
[ / --- PATIENT begin
PID / Patient Identification / 3
[PD1] / Additional Demographics / 3
[{PRT}] / Participation (for Patient) / 7
[{NTE}] / Notes and Comments / 2
[{NK1}] / Next of Kin/Associated Parties / 3
[{ / --- PATIENT_OBSERVATION begin
OBX / Observation (for Patient ID) / 7
[{PRT}] / Participation (Observation Participation) / 7
}] / --- PATIENT_OBSERVATION end
[ / --- VISIT begin
PV1 / Patient Visit / 3
[PV2] / Patient Visit - Additional Info / 3
[{PRT}] / Participation (for Patient Visit) / 7
] / --- VISIT end
] / --- PATIENT end
{ / --- ORDER_OBSERVATION begin
[ / --- COMMON_ORDER begin
ORC / Order common / 4
[{PRT}] / Participation (for Observation) / 7
] / --- COMMON ORDER end
OBR / Observations Request / 7
{[NTE]} / Notes and comments / 2
[{PRT}] / Participation (for Observation) / 7
[{ / --- TIMING_QTY begin
TQ1 / Timing/Quantity / 4
[{TQ2}] / Timing/Quantity Order Sequence / 4
}] / --- TIMING_QTY end
[CTD] / Contact Data / 11
[{ / --- OBSERVATION begin
OBX / Observation related to OBR / 7
[{PRT}] / Participation (Observation Participation) / 7
{[NTE]} / Notes and comments / 2
}] / --- OBSERVATION end
[{FT1}] / Financial Transaction / 6
{[CTI]} / Clinical Trial Identification / 7
[{ / --- SPECIMEN begin
SPM / Specimen
[{ / --- SPECIMEN_OBSERVATION begin
OBX / Observation (for Patient ID) / 7
[{PRT}] / Participation (Observation Participation) / 7
}] / --- SPECIMEN_OBSERVATION end
}] / --- SPECIMEN end
} / --- ORDER_OBSERVATION end
} / --- PATIENT_RESULT end
[DSC] / Continuation Pointer / 2
ACK^R42^ACK : Observation Message
Segments / Description / Status / ChapterMSH / Message header / 2
[{ SFT }] / Software segment / 2
[UAC] / User Authentication Credential / 2
MSA / Message acknowledgment / 2
[{ ERR }] / Error / 2
[This is the new text per this CP]
7.3.15 ORU – Unsolicited Patient-Device Association Observation Message (Event R43)
The R43 trigger event is used for observation reports that indicate the association of one patient to one or more health care devices. This includes both patient-device association as well as disassociation when a device is removed from active use with a patient. Other messages may beutilized for this purpose (e.g., ADT); however, this message was chosen given the general use of ORU_R01 messages to communicate device data, including unique device identifiers (e.g., OBX-18), and the possible need to include additional device data such as hardware / software configuration. The R43 trigger provides indication of the specialized usage of this message.
Use cases that this message supports include:
- Simple patient-device association where a system that integrates a bar code or RFID reader is used to capture patient and device identifiers at the point of care and then communicate those to other devices and systems that process device data associated with the same patient.
- When one or more devices are no longer associated with a patient, this message can be used to communicate this change of status
- Systems may not only perform the identifier acquisition from patients and devices, but may also authenticate the identifiers and support cross-referencing (e.g., when there are multiple patient identifiers)
In the latter use case, this message can be used to establish a “source of truth” for patient-device associations. There are many systems in and supportive of the point of care that make associations between patients and health care devices, all of which need to be coordinated to ensure there are no mis-matches between information sources and the patients to which they are associated.
The message shall identify a patient with optional location information, and one or more device observations, each including a unique device identifier along with an indication of whether the device is being associated or disassociated with the specified patient. In addition, a single observation can be specified to disassociate all devices for a given patient.
ORU^R43^ORU_R01: Observation Message
Segments / Description / Status / ChapterMSH / Message Header / 2
[{ SFT }] / Software Segment / 2
[UAC] / User Authentication Credential / 2
{ / --- PATIENT_RESULT begin
[ / --- PATIENT begin
PID / Patient Identification / 3
[PD1] / Additional Demographics / 3
[{PRT}] / Participation (for Patient) / 7
[{NTE}] / Notes and Comments / 2
[{NK1}] / Next of Kin/Associated Parties / 3
[{ARV}] / Access Restrictions / 3
[{ / --- PATIENT_OBSERVATION begin
OBX / Observation (for Patient ID) / 7
[{PRT}] / Participation (Observation Participation) / 7
}] / --- PATIENT_OBSERVATION end
[ / --- VISIT begin
PV1 / Patient Visit / 3
[PV2] / Patient Visit - Additional Info / 3
[{PRT}] / Participation (for Patient Visit) / 7
] / --- VISIT end
] / --- PATIENT end
{ / --- ORDER_OBSERVATION begin
[ / --- COMMON_ORDER begin
ORC / Order common / 4
[{PRT}] / Participation (for Observation) / 7
] / --- COMMON ORDER end
OBR / Observations Request / 7
{[NTE]} / Notes and comments / 2
[{PRT}] / Participation (for Observation) / 7
[{ / --- OBSERVATION begin
OBX / Observation related to OBR / 7
[{PRT}] / Participation (Observation Participation) / 7
{[NTE]} / Notes and comments / 2
}] / --- OBSERVATION end
[{FT1}] / Financial Transaction / 6
{[CTI]} / Clinical Trial Identification / 7
} / --- ORDER_OBSERVATION end
} / --- PATIENT_RESULT end
[DSC] / Continuation Pointer / 2
ACK^R43^ACK : Observation Message
Segments / Description / Status / ChapterMSH / Message header / 2
[{ SFT }] / Software segment / 2
[UAC] / User Authentication Credential / 2
MSA / Message acknowledgment / 2
[{ ERR }] / Error / 2
1