Add alert trigger event

Add Alert Trigger Event

V 2.8 HL7 Proposal
Change Request ID: / 625
File Name: /
Add_Alert_Trigger_Event.doc
Description:
Status: / proposed
HL7-Version / 2.8
Chapter/Section / 7.3, 4.5.3.39, 2.C.2
Sponsoring Person / Harry Solomon
Sponsoring Business Unit / GE Healthcare
Date Originated: / 5/11/2009
Date HL7 approved:
Backward Compatible:
Forward Compatible:
HL7 Status & Date

Justification Detail

It would be useful to have an additional Trigger Event associated with the ORU message type to identify an observation that has been identified as an alert.

The use case is than an observation creator, or a clinical decision support application that is monitoring observations, identifies a condition as an alert that requires notification. This observation is sent with an alert Trigger Event, possibly in addition to the message with the original observation with the usual R01 Trigger Event (although the specific use of this message in combination with other messages is beyond the scope of this specification).

This Trigger Event would allow message handling processes (e.g., interface engines) to provide appropriate routing of such observations to alert notification applications. The receiver behavior associated with this Trigger Event is the presentation of the alert to a human or computer application for possible intervention in patient care. That presentation is acknowledged in a specific application level Acknowledgment message that allows the identification of the receiver.

It is the application level Ack behavior associated with the alert observation message that requires definition of a new trigger event

.

Discussion

WGM 2009/05/14

  • How addressed with OUL?
  • Assumption is that ORU data is sufficient as the alert is less data, more summary.
  • Why trigger instead of PRT or other attribute?
  • Want application level acknowledgement that the alert was received.
  • How do we avoid the “second” ORU to override the first if the placer/filler number is the same?
  • Needs further thought.
  • Did we cover all alerts through this mechanism?
  • What vocabulary do we use in observation ID to encode the alert? Particularly if the alert is raised as the result of multiple observations.
  • How do we link the source observations to the summary alert?
  • Does the alert include the underlying observations or only reference?
  • Do we have all the application acknowledgement statuses that we need?
  • Should the acknowledgement include PID/ORC/OBR/OBX segments to enable responses to a specific component of the initial message.
  • Is there a use case for multiple patients to be included in an alert? If not, may not need some of that.
  • Should use case only stay at alert message level?
  • If the initial alert message consists of multiple alerts, can the acknowledgement be only all or none, or also some?
  • Assumption: The alert sending system has the responsibility to track whether all targeted providers indeed send an acknowledgement as that may happen over time (not all at once).
  • Describe use cases of CDS type alerts derived from multiple separate ordered observations

All points addressed in _02 version.

WGM 2009/09/25

  • Break out general update to 7.3 intro to a separate proposal
  • In queue ack can be done through ACK rather than ORA, remove from proposal
  • Replace order-specific rules for Segment Group with use of OBR-49 result handling flag
  • Define ORU^R40 separate from ORU^R01 to avoid confusion

All points addressed in _03 version.

Proposal

See next page.

V3 Implications

none

v2.xml Implications

none

Add to Chapter 7

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

Analert 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 observationreportingapplication 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 subsequentORDER_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 mot 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 theidentified 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 / Chapter
MSH / 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
[ORC] / Order common / 4
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^R01^ACK : Observation Message

Segments / Description / Status / Chapter
MSH / 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).

The behaviorassociated with the user acknowledgement may be specified in a local implementation agreement or implementation guide and may be indicated in MSH-21Message Profile Identifier.

ORA^R41^ORA_R41: Observation Report Acknowledgement

Segments / Description / Status / Chapter
MSH / Message Acknowledgment / 2
[{ SFT }] / Software segment / 2
[UAC] / User Authentication Credential / 2
MSA / Message Acknowledgment / 2
[{ ERR }] / Error / 2
[{ PRT }] / Participation (Acknowledging User) / 7
Update to Chapter 4 – change Table 0507 to HL7-defined (as allowed by 2.8.2.f.1)
4.5.3.39OBR-49 Result Handling (CWE) 01647

Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)> ^ <Second Alternate Identifier (ST)> ^ <Second Alternate Text (ST)> ^ <Second Name of Alternate Coding System (ID)> ^ <Second Alternate Coding System Version ID (ST)> ^ <Coding System OID (ST)> ^ <Value Set OID (ST)> ^ <Value Set Version ID (DTM)> ^ <Alternate Coding System OID (ST)> ^ <Alternate Value Set OID (ST)> ^ <Alternate Value Set Version ID (DTM)> ^ <Second Alternate Coding System OID (ST)> ^ <Second Alternate Value Set OID (ST)> ^ <Second Alternate Value Set Version ID (DTM)>

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to UserHL7-defined Table 0507 - Observation Result Handling for suggested values. If this field is not populated then routine handling is implied.

UserHL7-defined Table 0507 – Observation Result Handling

Value / Description / Comment
F / Film-with-patient
N / Notify provider when ready
A / Alert provider when abnormal
Update to Chapter 2.C

2.C.2.2660507 - Observation Result Handling

Table Metadata

Table / Steward / V3 Harmonization / V3 Equivalent / Where used / Status
0507 / OO / TBD / TBD / OBR-49 / Active

UserHL7-defined Table 0507 - Observation Result Handling

Value / Description / Comment
F / Film-with-patient
N / Notify provider when ready
A / Alert provider when abnormal

2.C.2.3130912- Participation

Table Metadata

Table / Steward / V3 Harmonization / V3 Equivalent / Where used / Status
0912 / OO / TBD / TBD / 7.4.4.4 / Active

HL7-defined Table 0912 - Participation

Value / Description / Used with
…
AAP / Alert Acknowledging Provider / PRT-4

1