Agenda
Discussion of relationship between domain model of proposed DeviceAlert FHIR resource and the existing practices in HL7 V2, as represented by the IHE Alert Communication Management profile
Attendance
John Garguilo
Brian Reinhold
Jan-Alrik Petersen
Javier Espina
Joe Quinn
Ken Fuchs
Koichiro Matsumoto
Stefan Karl
John Rhoads
Meeting Notes
Review of IEEE MDC Domain Information Model (DIM) model of an alert, and how it is represented in IHE Alert Communication Management profile
- IHE PCD ACM profile HL7 V2 message represents only a check of a single alert condition and does not represent combinations and prioritizations of multiple alert conditions that the orginating device may provide. That is, it represents an Alert object rather than an AlertStatus or AlertMonitor object in the sense of the MDC DIM. This is to support the use case of providing the basic information on a device alert condition to an Alert Manager, with the Alert Manager assuming the responsibility for dispatching alert information to professionally qualified persons responsible for responding to the alerts.
- The profile defines a mapping of selected attributes of an alert into a single HL7 observation message. Because it must carry alert attributes that are not natively provided for in a basic HL7 unsolicited observation message, its extra content is packaged in multiple OBX observation segments. These attributes are about single alert condition that must have a persistent unique identifier, and the ORU segment provides for such an identifier.
The identity of the alert condition is represented by a code from the MDC Nomenclature event partition - what the abnormal condition is - and another code representing , in the case of an abnormal condition in a measurement what measurement the condition is based on, or in the case of a technical condition, what component the condition is coming from using a code from the MDC Object partition.
The AlarmState reflects whether the alarm condition is inactive, sctive or latched, meaning it was formerly active but is no longer, but is being held or 'latched' so that clinicians are made aware of a transitory condition that formerly existed but may not currently be actuve.
The EventCurrentPhase enumeration distinguishes whether the current message notifies of a time point event (tpoint) that has no duration, the first message concerning a particular event (start), a subsequent message indicating the the alert condition is continuing and has not yet ended (continue), that the message reflects a change in some attribute of the alert (update), or that the alert condition has become more higher-priority (escalate) or lower-priority (de-escalate) since the last reporting message.
The IEC 60601-1-8 standard divides the priority scale of alarms into no-alarm, LOW_PRIORITY, MEDIUM_PRIORITY (prompt action required), and HIGH_PRIORITY (immediate action required), and distinguishes physiological alarms (pertaining to the state of the patient) and technical ones (pertaining to the equipment). The IEEE priority combines the physiological - technical dichotomy of origin with the low, medium, high priority level.
Note that this state diagram is driven by the transitions in the underlying alert condition and the presence or absence of the latching option. It does not conflate alert signaling state with alert condition state.
In the IHE Alert Communication Management profile adapts the semantics of a single Alert to the lack of provision for some of the elements of the elements of the semantics in an ordinary HL7 V2 observation report by splitting the report into mutliple OBX observation segments, each conveying part of the semantics.
