Event Communications

Overview of Concepts

Event communications – infusion pumps

• Distinguishes non-alarm events – operational milestones and key parameter changes

• Vs. Alarms – “intended to engage immediate response from the clinician”. These are handled by ACM Profile.

Event communications – infusion pumps

• Document gives detailed use cases and message examples

• Proposes new PCD event message, PCD-10

• To enable receiving systems such as CDSS and clinical workflow applications to more easily separate event information from the overall data stream.

Event communications – infusion pumps

• Challenge – pumps usually not “aware” of how they are being used clinically

• Numerous distinct use cases and variations

OBX-13 User defined access checks

• Definition: This field permits the producer to record results-dependent codes for classifying the observation at the receiving system.

• Ex. Filtering out microbial sensitivities so that ordinary users don’t see results with exotic expensive antibiotics.

• Data type ST string, not repeatable

OBX-13 User defined access checks

• That is, this is somewhat of a grungy wastebasket category.

• That said, where HL7 V2 gives you a hook, however grungy, we tend to need to use it… Ex. Our “enriched” set of OBX-8 Abnormal flags

Generalizing to events in the non-pump world

• The pump discussion gives patterns for much of the non-pump world

• But let us now do some free association about what other things events may be as well

• This will ideally be a Group rumination, not a presentation. I’ll make at least some assertions you ought to disagree with and want to discuss (not everything I’ll assert I agree with myself…)

Unifying principle 1• Let’s not alienate event communication from

observation reporting: it is observation reporting, though of a particular kind

• That applies to alarms as well: they are another particular kind of observation reporting

• If we keep the communication unified, it simplifies comprehension, and perhaps implementation as well

Another unification• Another kind of observation reporting we

already have treated to some degree is aperiodic or episodic observation reporting

• Periodic observation reports are triggered on the clock tick – aperiodics, like events, are triggered by something else

Aperiodics triggered on “something else”

For example:

• pushing the start button on a cuff pressure

• completion of a one-shot thermodilution cardiac output estimation procedure

• beat-to-beat or breath-to-breath measurements

• …

Q. What is different about events vs. other observation

reports?

Possible partial answer: it’s in the (multifarious) ways we process them:

• Time-critical response often (not always) involved

• They are a different kind of algorithm input in being discrete, and tightly time-located

Event processing generalities and abstractions

• Event operational definitions –

• Event Processing Technical Society – event: anything that happens, or is contemplated to happen

• Event object an object that represents, encodes, or records an event, generally for the purpose of computer processing

Events can be raw or processed

• Raw event – records a real-world event

• Derived event – “event generated as a result of applying a method or process to one or more other events” (EPTS)

• Complex event – “abstraction of other events, called its members

Composite event

• “derived complex event that is created by combining events using a specific set of event constructors such as conjunction, disjunction, and sequence” (e.g. HR < threshold and SpO2 < threshold)

Event patterns

• E.g. descending or ascending pattern of values, specific sequences of events

• Often used to determine when to apply a business rule

Window

• Bounded portion of an event stream

Instantaneous event

• Operational definition: “An event whose duration is less than the granularity of any clock that is applied in the system” (EPTS)

• Some events are a priori instantaneous – from their logical definition they plain don’t have a duration (e.g. threshold crossing)

Events have attributes

• Timestamps, often more than one, measured against more than one clock (more later)

• Event source

• Event type

• Location (if significant)

• Associated data (e.g. may link to a measurement vector in a pump scenario)

Event types

• Change of state, physiological or technical

• Threshold crossing (as in a measurement crossing an alarm limit)

Event objects propagate in networks

• Event producer

• Event consumer

• Event pathway

• Collection of event pathways can constitute a complex network, with complex additional processing at nodes – e.g. in clinical decision support systems

Clock (EPTS)

• A process that creates an ordered ascending sequence of type Time with a uniform interval between them. Each value is produced at a tick (or clock tick).

• There may be many clocks in a system. This leads to a large class of challenges in clock error propagation and clock error mitigation (cf. NTP algorithms)

Clock granularity

• The length of the interval between clock ticks is termed “granularity” by the EPTS.

• In our world of periodic sampling, we might think of it as a sampling interval (or reciprocal sampling frequency).

Latency

• Very generally, a time delay

• Many kinds, depending on context

• An important one for us is latency as time delay between an event’s actual occurrence and its (first) detection in the system

Jitter

• Also many kinds depending on context

• Ex. Variable deviation between intended time and actual time of measurement, as in clock tick jitter

• Typical measures statistical, e.g. median absolute deviation or root mean square deviation (a/k/a standard deviation))

Jitter, contd.

• Often the absolute latency is less of a concern if it is consistent (lacks substantial jitter)

HL7 an event-driven communications specification

• “The Standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event.” (HL7 Ch 2)

HL7 an event-driven communications specification 2

• “For example, the trigger event a patient is admitted may cause the need for data about that patient to be sent to a number of other systems.” (HL7 Ch. 2)

• (event producer to multiple event consumers)

HL7 an event-driven communications specification 3

• “The trigger event, an observation (e.g., a CBC result) for a patient is available, may cause the need for that observation to be sent to a number of other systems.” (HL7 Ch. 2)

• (i.e. event producer to multiple event consumers)

HL7 an event-driven communications specification 4

• “When the transfer of information is initiated by the application system that deals with the triggering event, the transaction is termed an unsolicited update” (HL7 Ch. 2)

UML Timing diagrams sd UMLTiming Diagrams

Tim

eL

ine

1

inactiv e

> threshold

activ e

< threshold & !latched

inactiv e

Tim

eL

ine

2

operational

initializing

idleState lifeline

value lifeline

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100

Tim

eL

ine

1

inactiv e

> threshold

activ e

< threshold & !latched

inactiv e

Tim

eL

ine

2

operational

initializing

idleState lifeline

value lifeline

ACM alarm (event) attributes sometimes relevant

• Not always

ACM alarm (event) identity - relevant

class Alarm Content

Ev entCodeIEEE

notesCode from MDC Nomenclature Event partition. Usually requires alarm source (a metric or a device) to disambiguate. Least significant bit indicates whether source is metric or device.

«enumeration»Ev entSourceIEEE

notesCode from MDC Nomenclature SCADA partition indicating for a limit alarm what parameter is out of l imits, or for a technical alarm, a code from the object partition indicating the source of the technical alarm

Alarm identity

Alarm State class Alarm Content

«enumeration»AlarmState

inactive active latched

notesSent as OBX-5 Observation Value of a child OBX segment of the alarm bundle

«enumeration»AlarmInactiv ationStateIEEE

enabled audio-paused audio-off alarm-paused alarm-off

notesPertains to a set of device alarms - individual, group, system

Sent as OBX-5 Observation Value of a child OBX segment of the alarm bundle

Alarm state

«enumeration»Ev entCurrentPhase

tpoint start continue end update escalate de-escalate reset

notesSent as OBX-5 Observation Value of a child OBX segment of the alarm bundle

ACM Alarm Limits

class Alarm Content

NumericAlarmRange

- low-limit: float- high-limit: float

Latching sd Latching

Tim

eL

ine

1

inactiv e

> threshold

activ e

< threshold & !latched

inactiv e

Tim

eL

ine

3

inactiv e

> threshold

activ e

latch released

inactiv e

If value goes back below threshold here on a latched alarm, the alarm stays active until the latch is released (by operator pressing "silence") -- you don't want to miss an important, but short duration, alarm

if alarm is not latched, it goes inactive as soon as the value goes back below threshold

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100

Tim

eL

ine

1

inactiv e

> threshold

activ e

< threshold & !latched

inactiv e

Tim

eL

ine

3

inactiv e

> threshold

activ e

latch released

inactiv e

If value goes back below threshold here on a latched alarm, the alarm stays active until the latch is released (by operator pressing "silence") -- you don't want to miss an important, but short duration, alarm

if alarm is not latched, it goes inactive as soon as the value goes back below threshold

ACM Alarm priority encodings

class Alarm Content

«enumeration»AlarmType

phys tech

notesDerived from nature of EventSourceIEEE, which is represented in low-order bit of EventCodeIEEE

Maps to following OBX-8 Abnormal flags values:

SP - Alarm source physiological ST - Alarm source technical

«enumeration»AlarmPriorityIEC

no-alarm LOW_PRIORITY MEDIUM_PRIORITY HIGH_PRIORITY

notesMaps to following OBX-8 Abnormal Flags:

Priorityno-alert - PNLow - PLMedium - PMHigh - PH

AlarmPriorityIEEE

«enum»+ no-alarm = 0+ low-pri-t-al = 1+ med-pri-t-al = 2+ hi-pri-t-al = 4+ low-pri-p-al = 256+ med-pri-p-al = 512+ hi-pri-p-al = 1024

notesMaps to AlarmPriorityCen and AlarmTypeCen

HL7 V2 Representation issues class HL7Representation

ChildOBXContent

- sub-id: Sub-ID- observationIdentifier: int- observationValue: int

notesTypical pattern:OBX-3 contains code identifying the individual attributeOBX-5 contains value

OBRContent

notesAll attributes of a particular alarm instance are constrained to be "belong to" an OBR, so as to bind together all the aspects of the alam

Sub-ID

- mds: int- vmd: int- chan: int- parametric-instance: int- child-instance: ChildOBXAttributeIdentifier

notesDistinguishes:

-specific source within MDC containment tree-specific attribute of the alarm - attribute identified by child-instance

AlarmHL7Representation

- obr- obx

MetricSpecificOBXSegment

notesOBX-3 Observation Identifier contains MDC nomenclature identifier for out-of-l imit metric

OBX-5 Observation Value contains current (out-of-l imit)numeric value

OBX-7 Reference Range contains alarm limits set on the device

OBX-8 Abnormal Flags contains severity and whether alarm source physiological or technical

OBX-14 Date/Time of observation

«enumeration»ChildOBXAttributeIdentifier

EventSourceIEEE AlarmPhase AlarmPriorityIEC AlarmState AlarmTypeIEC

notesFixed values for attributes:

Dev iceSpecificOBXSegment

notesOBX-3 Observation Identifier contains MDC nomenclature object identifier for technical alarmsource

Ev entMainOBXSegment

notesOBX-3 Observation Identifier

OBX-5 Observation Value contains current (out-of-l imit)numeric value

OBX-14 Date/Time of observation (start)

AlarmAttributeCarrierOBXSegment

notesCarries a general attribute of the alarm, distinguised by ChildOBXAttributeIdentifier part of sub-ID

What else do we want to be able to communicate about

events?• They can be created by non-device

information systems – this is an important function of clinical decision support systems

What else do we want to be able to communicate about

events?

• They need to be composable – a raw event may need to convey supporting data, a derived alarm may need to carry the events it is built on, and their supporting data…

• ???

• Your turn…

What else do we want to be able to communicate about

events?