Owning work group name:


Committee Approval Date:

May 10, 2023

Contributing or Reviewing Work Groups:

  • Clinical Decision Support
  • Orders & Observations
  • Patient Care

FHIR Resource Development Project Insight ID:

Project Insight 1776: Device Alerting (DEVAL) (Jira PSS-2005)

Scope of coverage:

Device Alert represents a single alert or alarm condition signaled by patient-connected health / medical device to indicate a condition that represents a patient safety risk.  It is aligned with with the ISO/IEC 60601-1-8 medical device alarms standard, and supports Distributed alert Information System (DIS) implementations.   

Alerts / alarms include:

  • Physiological alarm (for example: Patient Lucy has a low SpO2)
  • Technical alarm (for example: Infusion Pump #2 has a fluid line occlusion)
  • Advisory alert (for example: Alarm of undocumented timeout prior to a surgical procedure)

Devices that generate alert notifications are used across all healthcare delivery environments (e.g., from acute care hospitals to home health to community clinics and LTPAC) and all healthcare disciplines.

Internationally, all medical device regulatory agencies require conformance to the ISO/IEC 60601-1-8 standard as a pre-requisite to being allowed for use on patients. 

NOTE:  This specification does not support operator (e.g., clinician) "confirmation" of device alerts.  For example, remote "acknowledgement" of a device alert.  Though some DIS systems support confirmation, it is optional and often is not recommended.  

Attributes may include references to: 

  • Device /  DeviceMetric Origin of the alert signal and/or the subject of the alert/alarm condition or signal.
  • Patient – The individual who is the subject of the alert/alarm condition or signal.
  • Location – Of the Patient and / or Device, need for clinician response to resolve the condition.
  • Observation  – Related information (e.g., high blood pressure limit and actual values).

DeviceAlert may follow the Event pattern.

RIM scope:

No identified mappings to RIM 2.46 objects.

Resource appropriateness:

A device alert is not an attribute of any of the existing resources (e.g., Device), and warrants its own resource given the complex state dynamics of each instance.  At any point in time, a device can have many active alert events, each with their own state model, and must be captured independently of the device to which they are associated.  Similar to DeviceAssociation as a separate resource, the DeviceAlert is needed to allow patient information to be separate from the actual device to which the alert condition is linked.

For background, note that all medical devices must perform safety risk management and many, if not most, define alarms (visual, audible, and informational) to mitigate risks that require notifications be sent to the appropriate personnel to address the problem.  Required response times might range from seconds for life critical alarms or much longer for informational alerts.  Each alert/alarm instance requires a unique identifier and must be tracked and managed so as to ensure delivery to clinicians.  Currently, device alarm semantics are well established (e.g., in the ISO/IEEE 11073-10101, 11073-10201 and 11073-10207 standards), with implementations using IHE ACM HL7-V2 based profile.  This resource will provide an isosemantic means of achieving the same interoperability within a FHIR-based ecosystem.  

Expected implementations:

IHE-HL7 Gemini Device Interoperability SDPi+FHIR community is implementing the SDPi-Alerting profile (device-to-device plug-and-trust interoperability), which also includes a gateway to the widely implemented IHE ACM (V2-based) profile.  This alert will enable the addition of an SDPi-A FHIR Alert Gateway as a FHIR-alternative to the current ACM-based DIS systems.

System developers are currently prototyping early implementations of device alerting in a FHIR ecosystem, anticipating the provision of a DeviceAlert resource.

Content sources:

The Devices WG, as part of the Gemini SES+MDI (SDPi + FHIR) program has created the DeviceAlert structure mockup for the initial resource content, as well as created a FHIR CI build DeviceAlert draft resource.

Additionally, the following standards and specifications all form the basis for this specialized FHIR resource:

ISO/IEC 60601-1-8 medical device alarm systems standard 

Gemini SDPi-Alerting (SDPi-A) profile 

IHE Alert Communication Management (ACM) profile 

ISO/IEEE 11073-10101 Medical Device Communication Nomenclature 

ISO/IEEE 11073-10207 SDC BICEPS Standard 

ISO/IEEE 11073-10700 SDC Base Requirements for Participants in a Service-Oriented Device Connectivity (SDC) System 

ISO/IEEE 11073-10702 Alert Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System (in development)

Example Scenarios:

The following acute care scenarios provide examples of how this resource will be utilized:

  • Vital Signs Monitor detects a low heart rate and signals a high priority alarm that gets communicated to a FHIR-enabled Alarm Manager for distribution 
  • A SpO2 sensor has become detached and a clinician needs to respond and ensure that it is reattached and properly reporting information
  • An ensemble of devices around a single bed are simultaneously signaling alert conditions, each being communicated individually and uniquely to a management system that evaluates the highest priority alert(s) that should be communicated to  a clinician
  • Alert conditions from devices connected to a patient are consumed by a nursing "dashboard" application and integrated into a display that synthesizes all the information for review by clinical staff.
  • A technical alert (non-physiological) for a low battery is communicated to personnel indicating the need to restore power to the device before it fails.
  • A smart alerting system consumes medical device alerts and other information from an ensemble of devices around a patient point-of-care, analyzes the information in real-time and signals patient alert conditions that are not recognized by any single device.
  • A medication management workflow application subscribes to all the alert information from infusion pumps for a specific patient, to determine pump operational changes that may impact clinical workflow.
  • Analytics - device alerts are persisted and a quality analytics application periodically reviews the information and identifies opportunities for process improvement

Personal health scenarios include:

  • Patient-worn watch monitoring heart information identifies a dangerously hypertensive condition and issues an alarm to notify caregivers.
  • Mobile phone detects when a person falls and needs to notify the appropriate individual of the alarm condition.
  • Continuous glucose monitor detects dangerously low blood sugar and notifies the appropriate responder personnel.

Resource Relationships:

DeviceAlert directly references:

  • Device or DeviceMetric to identify the device or part thereof that originated the detection of the alert condition (e.g., the heart rate device metric that detected a tachycardia alert).  These resources may contain additional data elements to describe the alert activation states (e.g., if detection of all or a subset of alerts is on, paused or off).
  • Patient to identify the patient the physiological alert is about (e.g., a tachycardia alert). Alternatively, Device to identify the device the technical alert is about (e.g. EKG leads off).
  • Observation to identify any evidentiary data needed to interpret the alert condition or that is the reason why the alert condition is present.

Via its directly / indirectly referenced Device, DeviceAlert indirectly references Location to identify the location of the device that detected the alert condition (e.g., the location the practitioner may have to go to for acknowledging the alert condition or silencing the alert signal).

Resource Boundaries:

The following four bullets contain proposed text for a DeviceAlert "Boundaries and Relationships" section. Notes in italics complement the provided boundaries justification and are solely intended for FMG's consideration of the present resource proposal.

  • Flag:

Whereas DeviceAlert may be regarded to fall within the broad scope of Flag, DeviceAlert provides a carrier for the specific content important to the regulated and automated processing of device alerts typically resulting in near real-time notification of a person, typically a clinician in the patient vicinity able to respond.

The purpose of Flag is to highlight selected relevant information from a patient record. However, device alerts are not extracted from (or sometimes even recorded in) the patient record.

In addition, Flag focuses on the display of the warning or notification, whereas device alerts may also lead to other types of alert signal manifestations: audible (e.g. beeping patterns), tangible (e.g. vibration of handheld alert communicator).

Also note that device alerts - in acute care settings - often relate to life-threatening situations to which clinicians should react urgently. Flags will seldom have such degree of urgency.

  • DetectedIssue:

DetectedIssue indicates an actual or potential clinical issue with or between one or more active or proposed clinical actions for a patient. However, device alerts are not necessarily clinical issues (technical advisories are within scope too) and are differently processed and directed than detected issues. Moreover, device alerts are not necessarily related to clinical actions.

  • Communication:

In Communication there is a specific intended sender and receiver, and the information is delivered only once. However, Device alerts are not necessarily (or even usually) targeted at a specific intended receiver, and they are often continuous and ongoing.

Another difference w.r.t Communication is that device alerts are not sent with the purpose of "adherence to guidelines or protocols or to provide business documentation of actions taken".

Note for FMG’s consideration (not intended for future DeviceAlert “Boundaries and Relationships” text): Changing those characteristics of Communication to make device alerts fit in its scope would be a major change for Communication that would blur its current boundaries with other resources, such as with Flag.

  • Observation:

Observation is intended for capturing measurements and subjective point-in-time assessments. Device alerts do not share that intent.

Note for FMG’s consideration (not intended for future DeviceAlert “Boundaries and Relationships” text): Removing such purpose delimitation from Observation would blur its (already-huge) boundaries with existing resources such as Flag, DetectedIssue and Communication

The following four bullets contain proposed text for the "Boundaries and Relationships" sections of the four resources considered directly above:

Flags are not used to convey alerts generated by (medical) devices. These are handled using the DeviceAlert resource.

This resource does not cover clinical or technical issues detected and signaled by (medical) devices. Such issues are handled using the DeviceAlert resource, independently of any relationship to a clinical action.

DeviceAlert resources represent a potentially continuous ongoing "communication" generated by a (medical) device, often alerting anyone dealing with the patient. This is distinct from Communication where the information is delivered only once, there is a specific intended sender and receiver and there is a purpose to track adherence to guidelines or protocols or provide business documentation of actions taken.


R6 timeline

Github Users:

Todd Cooper 

Javier Espina 

John Rhoads 

Martin Rosner 

PSS-2005 Github:  https://github.com/HL7/DeviceAlerting 

When Resource Proposal Is Complete:

When you have completed your proposal, please send an email to FMGcontact@HL7.org

FMG Notes