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 dont 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. Ill make at least some assertions you ought to disagree with and want to discuss (not everything Ill assert I agree with myself…)
Unifying principle 1 Lets 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: its 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
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 dont 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 events 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)
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?