Page tree
Skip to end of metadata
Go to start of metadata

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


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 that 


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:

NameFlagsCard.typeDescription and Constraints
DeviceAlert

DomainResource
identifier
0..*identifier
code

CodeableConcept11703 Code for AlertCondition
status
0..1codein-progress | completed ß Suspended, see AudibleSignal and VisualSignal
priority
0..1codeLow, Medium, High  ß Low, Medium, High, None (for information signals)
subject

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

dateTime|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
device

Reference(Device|DeviceMetric)Device Reference for MDS, VMD, Channel and DeviceMetric for indiv. Metric (e.g. HR in a HR HIGH Alarm).
derivedFrom

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

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

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

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

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

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

Draft Mappings Between Proposed DeviceAlert FHIR Resource and Other Standards

NametypeDescription and ConstraintsDIM 11073-10201 Reference

SDC 11073-10207
Reference

IHE DEV ACMComments
DeviceAlertDomainResource




identifieridentifier




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



statuscodein-progress | completed ß Suspended, see AudibleSignal and VisualSignal

Alert::Alert-Condition::controls

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

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

pm:AlertSignalDescriptor + pm:AlertSignalState

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




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



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



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




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



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




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




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




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

Alert::Alert-Condition::alert-flags




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





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.