Event Communications

1. Event Communications Overview of Concepts

2. 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.

3. 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.

4. Event communications – infusion pumps • Challenge – pumps usually not “aware” of how they are being used clinically • Numerous distinct use cases and variations

5. 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

6. 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

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

8. 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

9. 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

10. 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 • …

11. 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

12. 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

13. 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

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

15. Event patterns • E.g. descending or ascending pattern of values, specific sequences of events • Often used to determine when to apply a business rule

16. Window • Bounded portion of an event stream

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

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

19. Event types • Change of state, physiological or technical • Threshold crossing (as in a measurement crossing an alarm limit)

20. 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

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

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

23. 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

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

25. Jitter, contd. • Often the absolute latency is less of a concern if it is consistent (lacks substantial jitter)

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

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

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

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

30. UML Timing diagrams

31. ACM alarm (event) attributes sometimes relevant • Not always

32. ACM alarm (event) identity - relevant

33. Alarm State

34. ACM Alarm Limits

35. Latching

36. ACM Alarm priority encodings

37. HL7 V2 Representation issues

38. 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

39. 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…

40. What else do we want to be able to communicate about events? • ??? • Your turn…