View raw Markdown
type: resourceresource: DeviceAlert

DeviceAlert

Introduction

Scope and Usage

DeviceAlert represents a single alert condition detected and signaled by a device to create clinician's awareness of a patient safety risk that needs to be addressed.

The device is often a communicating, physical, patient-connected health/medical device operating in an acute care setting (e.g., patient monitor, ventilator, infusion pump, etc.). However, Software as a Medical Device (SaMD), non-patient connected devices, and other Health Software “apps,” as well as lower acuity care settings (e.g., a fall detector app running on a patient's mobile device at home) are in scope as well.

Alerts can relate to physiological (e.g., Patient Lucy has a low SpO2), technical (e.g., Infusion Pump #2 has a fluid line occlusion), or other conditions. Alerts can also have different priorities based on the hazard's severity and urgency of clinicians' action, ranging from High (e.g., a life-threatening condition requiring immediate response) to Advisory (e.g., information to create contextual awareness without requiring timely response).

DeviceAlert is intended for capturing device alert information for documentation and display purposes (e.g., to enable analytics towards alarm noise reduction opportunities). DeviceAlert is not intended for controlling alarms (e.g., remote pausing the audio of an alarm signal). Additionally, any actions that follow from the alert are not part of the resource.

[%dragons-start%]

Prompt, assured, and accurate notification of patient-safety–related conditions is a complex subject. Use of FHIR, in itself, is not sufficient to guarantee delivery of alerts. Critical alerting capabilities are to be considered as part of complete systems engineering activity to achieve timely, reliable, alert notification.

[%dragons-end%]

The specifics of an alert are preferably described using medical device nomenclature from the Alerts and events partition of the ISO/IEEE 11073-10101 standard for Medical Device Communication Nomenclature. DeviceAlert is also aligned with the ISO/IEC 60601-1-8 medical device alarm systems standard. Internationally, medical device regulatory agencies require conformance to ISO/IEC 60601-1-8. Moreover, DeviceAlert is aligned with other standards and specifications such as the Gemini (IHE/HL7) SDPi-Alerting (SDPi-A) Profile, the IHE Alert Communication Management (ACM) profile, and other ISO/IEEE 11073 standards from the Service-Oriented Point-of-Care Medical Device Communication (SDC) standards family.

DeviceAlert models both the concept of alert condition detection as well as its related signaling. Both concepts are combined in one resource due to their high, complex state dynamics and strong interrelationship. For instance, the “Presence” state of an alert signal (e.g., monitor beeps or not) depends on the “Presence” state of the triggering condition, the “Activation” state of the triggering condition (e.g., detectable or not), and the “Activation” state of the signal itself. More information on this can be found in the Background and Context section below.

Some of the resources listed in the Boundaries and Relationships section, below, might be used complementarily. For example, in a home care setting, a patient fall condition detected by a phone app (DeviceAlert) could trigger a remote alert signal in the caregiving family member app (DeviceAlert), while, days later, the treating physician receives a “patient fell 2–5 times in the last 3 months” message on her clinician app (Communication) or see such message flagged in the EMR (Flag).

Usage Scenarios

The following scenarios provide examples of what this resource is utilized for:

Boundaries and Relationships

Resource Relationships

This resource directly references:

Resource Boundaries

Flag

The primary distinction between Flag and DeviceAlert lies in their origin and intent: Flag highlights selected information from the patient record for general awareness, while DeviceAlert originates from a device, based on device-generated data (often outside the patient record), and is designed for regulated, automated alerting that could trigger immediate clinical response through visual, audible or haptic signals. DeviceAlert also tracks alert condition and signal states, though for low-priority alerts, a Flag could be a suitable supplementary means of annunciating through the patient record.

DetectedIssue

DetectedIssue identifies clinical concerns linked to proposed or ongoing actions, while DeviceAlert is typically triggered by physiological or physical events, not clinical decisions. These resources differ not only in origin, but also in how they are processed and directed: Detected issue is part of clinical reasoning workflows, while DeviceAlert is often part of automated device monitoring systems.

Communication

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

Observation

Observation is intended for capturing measurements and subjective point-in-time assessments, and complements DeviceAlert, identifying any evidentiary data needed to interpret the alert condition (that is, the reason why the alert condition is present).

Subscription

Subscription differs from from DeviceAlert in origin and behavior: Subscription reflects a client's request for filtered notifications from a FHIR server, while DeviceAlert represents unsolicited events triggered by devices based on physiological or physical conditions. Due to the vast number and variability of device alerts, consumer-controlled filtering (subscription) is typically impractical. Moreover, DeviceAlert supports documentation and logging use cases, while subscriptions have a run-time nature.

AuditEvent

AuditEvent is primarily for administrative and operational tracking, while DeviceAlert serves clinical purposes, often prompting action. DeviceAlert captures multiple dynamic states across an alert's lifecycle, which would be inefficient and duplicative to model using separate AuditEvents, especially since AuditEvents are usually immutable and DeviceAlert often requires updates.

Background and Context

DeviceAlert models two alert aspects: the condition detected by a device, and the signal, representing how the alert is announced (and by which attention is drawn to the existence of the alert condition). Signal behavior is determined by device design and configuration and could persist beyond the condition itself due to features like latching (extending brief alerts for visibility).

The DeviceAlert state machine showing transitions between idle, inactivated, latched, alarming, acknowledge, and signal-inactivated states; and the interplay between alert conditions and signals.

The DeviceAlert state machine showing transitions, and the interplay between alert conditions and signals.

The center row of the diagram shows the flow between the states of the device alert record taking into account both the alert condition and the signals being emitted by the device. The upper row shows the values of key attributes of the DeviceAlert resource instance and of the associated DeviceMetric or Device in the corresponding states. Note that the alert detection activation state of the associated DeviceMetric or Device is represented through a resource extension, more specifically through the `activationState` sub-extension of the Device Alert Detection extension, which could be applied to either Device or DeviceMetric. The bottom row shows values of key attributes of the DeviceAlert resource instance in the corresponding states.

StructureDefinition

Elements (Simplified)

Mappings

Resource Packs

list-DeviceAlert-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
    <id value="DeviceAlert-packs" />
    <status value="current" />
    <mode value="working" />
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

devicealert-event-mapping-exceptions.xml

Divergent Elements

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. | resource=Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

Unmapped Elements

devicealert-fivews-mapping-exceptions.xml

Unmapped Elements