In an acute-care hospital unit, a critical component of the electronic message flow is the notifications of patient physiological alarms and events. Devices themselves give visible and audible alarm indications, but prompt notification direct to the proper clinician, who is not necessarily best positioned to hear or see the device, is a necessity to get the needed response as efficiently as possible.

In literature about devices, this process is often called alerting, but in FHIR an Alert resource is about something quite different, with different requirements and data flows, so in this discussion we will use the term Device Alert and the name for the not-yet-real FHIR resource for it as DeviceAlert.

<integration with other standards 60601-1-8, SDC, Classic, ACM, ...>

<what is an alert:  RCM>

<events vs. alerts>

<link to SDPi-Alerting>  <reference sequence diagrams + grouped actors ... in the SDPi-A pages?>

<link to Quiet Hospital narrative>

<mapping between device informatics standards w/ alerting capability to FHIR>

<DIS, DAS, CDAS + external control (levels) + delegation> - what can you do in FHIR ... now ... future>

<role of PKP & KIP's layers>

<section for device alert standards for support by Device Alert specification>

<section for Device alert specification>

Device Alerting using FHIR

<general>

<what can you do?  How far can you go?  What is the SES component of this?>


What Lays Below ...


Discussion Notes & Tasks

See also related discussion notes at Meeting Logs & Notes.    Also there may be related Topics of Interest items, as well as content on Tools & Conformity AssessmentPaper: SES MDI, and Narrative: Quiet Hospital.


NOTE:  Order newest & future-est to oldest.

.

Agenda

No advance agenda available.

Participants

John Rhoads Bjoern Andersen Brian Reinhold Kathrin Riech Stefan Karl Todd Cooper

Discussion Notes

  1. Device Alerting Topic - Restart 
    1. Bjoern Andersen will lead resuming work on defining a new FHIR DeviceAlert resource, building on the content below when this work was paused earlier in the year (due to insufficient resources and priority of other tasks)
    2. Discussion included HOW and WHERE to craft the specification for a new FHIR resource ...
      1. DECISION was to keep the technical content discussions on this page, while in parallel
      2. ACTIONJohn Rhoads Bjoern Andersen) will investigate the tooling and formal process for advancing the specification within HL7 FHIR 
    3. Note that for the near term logistics, Gemini MDI tooling will be used, including
      1. Confluence pages (starting with this page) to keep the information in one place
      2. Confluence "tasks" (see below) to capture the action items
      3. IHE Github sdpi-fhir repository for persistence & Issue tracking
        1. Note that the related Github sdpi-fhir Issue reference can be linked into the related Confluence task item below (e.g., by adding "(GitHub Issue #<xyz>)" to the end of the Confluence task texts with a hyperlink to the repo Issue
      4. Revision history will be maintained (in the near term) via the integrated Confluence history and Github repository history.
    4. Everyone expressed strong thanks to Bjoern Andersenfor taking up this very important task going into 2021!
  2. January FHIR CAT DoF Track Discussion
    1. Todd Cooper Updated the group on the proposed 2021-01 Isolation ICU Bed Device Integration Use Case (Gemini MDI Project) and Call for Participation! 
    2. Noted that (a) having a "devices" / DoF presence at CAT events is important; (b) this use case will be in the initial SDPi Supplement + will be a key use case in the Gemini projects through the year.  
    3. Since this is the January CAT, the objectives will be to have a discussion to work on the use case / scenarios detail + understand the integration of FHIR (for enterprise connectivity) and SDC/SDPi for acute Isolation ICU PoC integration.  
    4. IF no one signs up, though, and helps put it on, then the track will be canceled ... which would be a travesty 
    5. ACTION( Todd & John) To plan and recruit etc. 
  3. Tooling Discussion (Ran out of time - Deferred to January)

Action Items / Tasks


DescriptionDue dateAssigneeTask appears on
  • Bjoern Andersen Review work on this page and re-establish the requirements, technical sources and crafting of this new resource
Bjoern AndersenDoF: Alerting
  • Bjoern Andersen  Plan an update presentation / discussion of the DoF Alerting topic during the WGM's in 2021 January
Bjoern AndersenDoF: Alerting
John RhoadsDoF: Alerting
Todd CooperDoF: Alerting


Architectural Approaches for Device Alerting

<60601-1-8 / ACM / SDC / DIM / etc. incl. "gateways" - both for normalization & aggregation>

<DIS DAS CDAS ...>

<include sequence diags HERE or in the SDPi-Alerting section? Both?  definitely linked but one fact / one place>

NOTE See 2020-01 SDPi Appendix C Use Case analysis by Kenneth FuchsPeter Kranich and update appropriately to this section.


Use Case:  Alert Logging

One key application for device alerting using FHIR is related to alert logging,   In addition to the device alert "distribution" applications discussed above (i.e., for DIS and DAS systems), the intent of this use case is to collect device alert and related information (e.g., changes to alert limits or alert silencing events) over time to enable analytics for care quality improvement purposes.  For example, capturing infusion pump alerting and settings information to determine if a given device or care setting (e.g., NICU) has a higher level of sustained "occlusion" alerts at a particular time of week.  This use case provides application context around the definition (below) of how a device alert should be represented and communicating using FHIR resources.

Of course, when considering alert logging scenarios, many questions arise:

  1. What additional contextual data should be logged with or linked to specific device alerts?
    1. Device user / clinician interactions such as silencing or confirming an alert?
    2. Modification (by user or external system) of an alert limit
    3. "smart alerts" (based on multiple independent information sources incl. multiple devices)?
    4. Delegated alerts?
    5. Associated patient and caregiver information?
    6. Care
  2. At what point does this become a "full disclosure" repository that has device alert info vs. a specialized alert logger?
  3. What architectural "paradigms" should be supported?
    1. FHIR 100% ... info reported in using FHIR ... searches invoked using FHIR ...
    2. SDC/SDPi SOMDA :
      1. Data collected from SOMDA Participants and integrated into a specialized Alert Log system that also integrates the FHIR Gateway actor?
        1. Data collected from a specialized SOMDA Connector and forwarded (using FHIR or V2 or other) to a Alert Logger 
        2. Data collected in a SOMDA Alert Logger system (SOMDA Consumer) and made available using the FHIR Gateway for analytics searches
        3. ...
    3. IHE ACM / V2-based integration?  
      1. For example, as an ACM/ACON actor that is grouped with a FHIR server
    4. 21 CFR part 11 
      1. see: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application#iiic
  4. What is the relationship (if any) with the AAMI 2700-2 ICE/Forensic Data Logger standard?
  5. What is the relationship (if any) with the proposed MDIRA Profile "Forensics Data Logger" actor?
  6. For SDPi+FHIR, is this a sufficiently complex use case to motivate a separate set of profiles / IGs?
  7. What analytics / log searches need to be supported?
  8. ...

Background information related to alert logging:

  1. (Todd Cooper ) see if there is anything related to infusion pump CQI
    1.  Discussion w/ IHE Pump WG:
      1. Todd Cooper provided back ground for this alert logging "analytics" question, including cloud-based products from ages past that collected pump information and regular reports based on infusion device analytics
      2. No one on the call had any additional information - no current products or reports that anyone could think of
  2. (Todd Cooper ) Check with ECRI to see if there are any studies on this topic that could be leveraged - note latest Top 10 List
    1. Initial discussion scheduled for 2021.02.09


Standards Coordination / Mapping

Device alerting is a topic that is addressed in a number of international standards, including the following:

StandardDevice Alerting Support
ISO/IEEE 11073-1010xDevice nomenclature / terminology with an extensive list (actively being updated) of concepts for device-related events and alerts.
ISO/IEEE 11073-10201:2018"Classic" domain information model includes a 
ISO/IEEE 11073-10207:2018Service-oriented Device Connectivity builds on the alerting support in -10201; however, it simplifies the options, aligns it with a SOA model, and includes capabilities like "alert delegation" <include reference>
IHE DEV PCD ACM
IEC 60601-1-8

The good news, is that there is a high degree of cohesiveness between these standards, especially regarding semantic alignment.


In the SDPi+FHIR project, the SDPi+Alerting profile - focused on device-to-device interoperability - includes "gateway" actors to HL7 FHIR and HL7 v2 (and proprietary) environments.  In the case of FHIR, the semantics used across the above standards, and especially SDC, should be consistently mapped to FHIR resource(s) and data elements.  The following table provides the initial correlations between concepts & constructs in the standards identified above:

Draft Proposed FHIR Resource:  DeviceAlert

Given that the FHIR Alert resource is focused on a very different set of use cases, the DoF team determined that a specialized DeviceAlert resource should be defined, especially given the unique regulatory & legal requirements related to the handling and functioning of these items.  The table below provides a description of the semantics for this new resource proposal:

Data Model available at: Device Alarms | DEVAlarms - SIMPLIFIER.NET


NameFlagsCard.typeDescription and Constraints
DeviceAlert

DomainResource
identifier
0..*identifierBusiness identifier
status
1..1code

StefanK: Suggest to keep this as resource status (with codes derived from the Event pattern):

CodeDisplayDefinition
in-progressIn ProgressThe alert is currently occurring.
stoppedStoppedThis alert record was terminated prior to the full completion of the alert, e.g., by deactivation of alert detection.
completedCompletedThis alert record has now concluded, i.e., alert condition ceased and all derived signals off.
entered-in-errorEntered in ErrorThis electronic record should never have existed, though it is possible that real-world decisions were based on it.
code

CodeableConcept11703 Code for AlertCondition

activationState


0..1code

PeterK.: isn't this rather the alert phase (start, in-progress, updated, completed)?  Suspended is rather the state of the alert → see audibleSignal and visualSignal below!?

JohnR: Agree with Peter, there's more: the FHIR convention is that "status" is the status of the FHIR resource. We want to represent the state of the underlying alert process separate, don't we? And also the suspended information is distinct

JanP: Removed "status" to alarmState, to avoid confusion with "status" of FHIR resource datatype.  EventPhase (IHE PCD TF Vol 2.) might be more relevant for a Message-Based approach?

I added activationState and presence, that are derived from BICEPS.

On|Off|Psd

One could argue, that an inactive alarm can be regarded as not present, in which case, we could use a field alertState instead, accordingly:

activationState (11073)

presence

(11073)

alertState (IHE PCD TF Vol 2.)
OFF|PSDFalseInactive
OFF|PSDTrue Inactive
ONFalseInactive
ONTrueActive

Remark: alertState also allows the value "latched". This is covered in audibleSignal and visualSignal.

StefanK: Making activationState and presence explicit elements of the DeviceAlert resource means that DeviceAlert instances need to be created even if there is no device alert present. Is this intended?


JanP:  Related: Should a DeviceAlert

a) represent the state of a particular Alert on a Device regardless, of its presence or activation OR

b) represent an active Alert that is "in process" (start, end, in progress)?


  • Even if was more consistent with a Device being represented as a Set of Resources, that represent a state, usually only those Alarms will be of any interest that are relevant: b).
  • In this case, we might be able to remove this field because alarms that are not active are not represented by DeviceAlert 


 

Idea: Drag the activationState out and put  the information into the referenced device (s. attribute: device).

Stefan Karl To write a brief sum up to discuss this concept.

I suggest making activationState an element or extension of Device and DeviceMetric (see below), which allows data consumers keeping track of alert activation state even if no DeviceAlert is present. In a hierarchical device model as defined in the PoCD IG, scope of activationState is the MDS, VMD, channel, or device metric that an active alert reports in its DeviceAlert.device reference.

Deactivation of an ongoing alert can be indicated by DeviceAlert.status "stopped" instead of "completed".

Peter Kranich & Vitor: we agree Stefan Karl. For us, the activation state belongs to the Device / DeviceMetric but not to the FHIR alert resource. Please clarify if the activation state refers to the alert condition or the alert signals!!!

presence
1..1boolean

True, if the Alert Condition has been detected and is present. Otherwise False.

JanP: Deleted. The presence is indicated by conditionPeriod/conditionDateTime. 


priority
0..1code

Low, Medium, High, None (for information signals)

 type
 1..1 code Physiological Alert, Technical Alert, or Advisory
subject

Reference(Patient|Device)

Patient for physiological and Device if it is a technical Alarm.


PeterK & VitorA: technical alert could also refer to a patient e.g. "Low perfusion" for SpO2 sensor

conditionTime

StefanK:
condition[x]
with choices
conditionDateTime
conditionPeriod



dateTime|PeriodOfTime


The Time of presence of the Alarm Condition aka Determination Time of onset of Alarm Condition and if applicable the offset of the Alarm Condition

PeterK.: shall be period when onset time of the alert is given and the end time of the alert can be determined. In this case, the alert status goes through the phases start, in-progress, and finally completed (do we also need the "start" status?). DateTime shall only be used when the length of the alert condition cannot be determined. FHIR meta data property lastUpdated indicates when the alert was reported to the system - especially in the "start" phase of the alert.

StefanK: I recommend keeping Period as choice for alert condition time, because this is valuable information for retrospective analysis. We may add alert signal time as separate element. 2022-01-17 meeting: This could be a choice  (effective[x]) of dateTime or Period.

BrainR: Is Period simpler than the choice.



 

TypeMeaning
conditionPeriod with a StartTime and no Endtime

If an AlertConditions becomes present, a conditionPeriod with a Start-Time only is given.

While the AlertConditions is present, no Endtime is given.

conditionPeriod with StartTime and EndtimeThe AlertConditions has been and is not present anymore.
conditionDateTimeAt the given point in time, an AlertCondition was present.
device

Reference(Device|DeviceMetric)Device Reference for MDS, VMD, Channel and DeviceMetric for indiv. Metric (e.g. HR in a HR HIGH Alarm).
derivedFrom
0..Reference(Observation|Device|DeviceMetric)Evidentiary data that is needed to interpret the condition or that is the reason why the condition is present
alarmLabel
0..stringAlertString: Display Text that may combine the alarm  concept code as well as the measurement type and potentially also bodysites
signals
0..n

Current state of the local audible AlertSignal that relates to the Alarm Condition with a value-set of: On, Latched, Ack, Off.

Peter K.: not sure if Latched would make sense for the audible signal I rather missed "paused".  JanP: Should be addressed in the backbone element below:

AlertSignalState: 

{

ActivationState: ON|OFF|PAUSED

Presence: ON|OFF|LATCHED|ACKNOWLEGDED

Manifestation: Aud|Tang|Vis|Oth

alertSignalTime: dateTime|PeriodOfTime

Location: LOCAL|REMOTE|MOBILE

}

PeterK and VitorA: alertSignalTime: in our opinion, a PeriodOfTime is not needed. If there is a change, this is an event and will update the DeviceAlert resource. A dateTime is sufficient.


remoteAudible
0..boolean

condition can be audible at at least one remote location (i.e., not suppressed)

StefanK: As an alternative, we could define a backbone element (0..*) for alert signal related sub-elements: location (local, remote, mobile, …), visual/audible signal status (on, off, latched, acknowledged) and time period.

JanP: Let's discuss where toput this.

PeterK and VitorA: how does this influence the signals above? Are there two signal entries per manifestation - one for LOCAL and one for REMOTE? What about the Location value "MOBILE" - how is this used ("MOBILE" is also "REMOTE")? Only the consumer can control the signalling. So, Location could only be a recommentation!? Alert source does not know how the consumer handles the alert signal.

limits
0..ReferenceRangeCurrent Alert Limits that are applied in the determination of the alarm condition if applicable.
safetyClass
0..codeMedA, MedB, MedC, Inf
signalGenerationDelay
0..PeriodOfTime

the default period from the onset of an ALERT CONDITION to the generation of the ALERT SIGNAL. The implied value SHALL be "PT0S".

PeterK and VitorA: only alert source can specify its delay when the alert signal is available at the interface. Additional delays apply during transport of the alert data and processing at the receiver of the alert message.
We assume the property only relates to the alert source.

What is a default period? Usually, this is a typical delay derived by statistical methods, or worst case value. 

rank
0..intMay indicitate a rank within a priority between several alarms.

Additions to FHIR Resource: Device

Extension: device-alertDetection

NameFlagsCard.TypeDescription and Constraints
alertDetection
0..*Extension
    code
0..1CodeableConcept

Alert code for specific alert activation state

    activationState
1..1codeon | off | paused

Note:
If code is not present, activationState represents the overall state within the scope of the device or device component. Additional entries may provide deviating state for specific alerts.

Additions to FHIR Resource: DeviceMetric

NameFlagsCard.TypeDescription and Constraints
alertDetection
0..*BackboneElement
    code
0..1CodeableConcept

Either alert code for specific alert activationState or metric code for components 

    activationState
0..1codeon | off | paused
    limitRange
0..1BackboneElementAlarm limits that are applied in the determination of the alert condition
        low
0..1decimalLower limit. Unit is in DeviceMetric.unit.
        high
0..1decimalUpper limit. Unit is in DeviceMetric.unit.

Note:
If code is not present, activationState represents the overall state for the device metric. Additional entries may provide deviating state for specific alerts.
If code is not present, limitRange applies to DeviceMetric.type. For metrics with multiple components (e.g., blood pressure measurement) the code identifies the component.

Draft Mappings Between Proposed DeviceAlert FHIR Resource and Other Standards

NametypeDescription and ConstraintsDIM 11073-10201 Reference

SDC 11073-10207
Reference

IHE DEV ACMComments
DeviceAlertDomainResource

AlertSignalDescriptor

AlertSignalState

AlertConditionDescriptor

AlerSignalState

PCD-04,

PDC-05,

PCD-06



identifieridentifier

B.21 AbstractDescriptor/Type

B.188 CodedValue/@Code

PCD-04 OBX
codeCodeableConcept11703 Code for AlertCondition

Alert::Alert-Condition::alert-code

AlertStatus::Tech-Alert-List|Physio-Alert-List::alert-code

AlertMonitor::Device-T-Alarm-List|Device-P-Alarm-List::al-code

pm:AlertConditionDescriptor

pm:LimitAlertConditionDescriptor

pm:AlertConditionState


B.21 AbstractDescriptor/Type



activationStatecode

on|off|psd

Alert::Alert-Condition::controls

AlertStatus::Tech-Alert-List|Physio-Alert-List::controls

AlertMonitor::Device-T-Alarm-List|Device-P-Alarm-List::al-state

B.2 AbstractAlertState@Activation



presenceboolean

B.100 AlertConditionState/@Presence

prioritycodeLow, Medium, High  ß Low, Medium, High, None (for information signals)

Alert::Alert-Condition::alert-type

AlertStatus::Tech-Alert-List|Physio-Alert-List::alert-type

AlertMonitor::Device-T-Alarm-List|Device-P-Alarm-List::al-type

B.88 pm:AlertConditionDescriptor/@Priority

pm:AlertConditionPriority 

PCD-04

OBX


subjectReference(Patient|Device)Patient for physiological and Device if it is a technical Alarm.

B.89 AlertConditionDescriptor/@Kind  (Tech/Phys)

PCD-04 PID
effectiveTimedateTime|PeriodOfTimeThe Time of presence of the Alarm Condition aka Determination Time of onset of Alarm Condition and if applicable the offset of the Alarm Condition

B.101 AlertConditionState/@DeterminationTime

janP: Discuss whether to get rid of PeriodOfTime, here?

PCD-04 OBX
deviceReference(Device|DeviceMetric)Device Reference for MDS, VMD, Channel and DeviceMetric for indiv. Metric (e.g. HR in a HR HIGH Alarm).

Alert::Alert-Condition::alert-source

AlertStatus::Tech-Alert-List|Physio-Alert-List::alert-source

AlertMonitor::Device-T-Alarm-List|Device-P-Alarm-List::al-source

Containment Tree Reference.

derivedFromReference(Observation |Device|DeviceMetric)Evidentiary data that is needed to interpret the condition or that is the reason why the condition is present

B.88 pm:AlertConditionDescriptor/@Source



alarmLabelstringAlertString: Display Text that may combine the alarm  concept code as well as the measurement type and potentially also bodysites

Alert::Alert-Condition::alert-info

AlertStatus::Tech-Alert-List|Physio-Alert-List::alert-info

AlertMonitor::Device-T-Alarm-List|Device-P-Alarm-List::alert-info

B.21 AbstractDescriptor/Type

B.193 CodedValue/ConceptDescription

PCD04

OBX


audibleSignalcodeCurrent state of the local audible AlertSignal that relates to the Alarm Condition with a value-set of: On, Latched, Ack, Off

Alert::Alert-Condition::alert-flags

B:114 AlertSignalState/@Presence

visualSignalcodeCurrent state of the local visual AlertSignal that relates to the Alarm Condition with a value-set of: On, Latched, Ack, Off

Alert::Alert-Condition::alert-flags

B:114 AlertSignalState/@Presence

remoteAudiblebooleancondition can be audible at at least one remote location (i.e., not suppressed)

Alert::Alert-Condition::alert-flags

B:115 AlertSignalState/@Location

limitsReferenceRangeCurrent Alert Limits that are applied in the determination of the alarm condition if applicable.

Alert::Limit-Specification

AlertStatus::Limit-Spec-List

AlertMonitor::Limit-Spec-List

B.234 LimitAlertConditionState/MonitoredAlertLimits

On we decided that limits rather belong to the referenced DeviceMetric (s. device, dericedFrom)

safetyClasscodeMedA,MedB,MedC,Info

B.1 AbstractAlertDescriptor / SafetyClassification





Resource Documentation Draft


Scope and Usage


Alerts are used in in healthcare, used to mark potentially or actual hazardous situations. They are derived from alert sources such as point of care devices or distributed alarm systems.

Alert data is often communicated unsolicitedly to enable alerts to be annunciated remotely from the source. For such scenarios, message based communication profiles

have been established like HL7 IHE ACM or IEC 11073. The FHIR Alert Resource allows to represenent alert data in FHIR and allows to store this data in a FHIR repository.

Stored Alert Data is used in Alarm Analysis, Alarm History Reports and forensic investigations.


Examples for Alerts include

  • Actionable Alarms (e.g. Asystolie)
  • Limit-Alarms (e.g. IBP measurement exceeds threshold)
  • Technical Alerts (e.g. Network communication interupted)


Boundaries and Relationships

There are three related resources:

Device - Can be the Source of an Alert or the Subject of a technical alert.

DevicMetric, Observation - Evidentiary Data related to an alert.

Patient - Can be the Subject of a physiological alert.





Additional considerations:

  1. Level of Mapping Detail
    1. Table above should be sufficient to understand high-level coverage and mapping BUT detailed mapping would be in linked sub-pages w/ mapping tables (e.g., Excel in Confluence type stuff).
  2. SDC Integration:
    1. Mapping / Role of pm:AlertSystemDescriptor  + pm:AlertSystemState/@ActivationState etc.
    2. Utilization of / integration of alert delegation ?



NOTE:  "SDC/SDPi Mapping" is included given the intent to tightly couple this with the Gemini SDPi+FHIR work.