R6 Ballot (2nd Draft)
AdministrationPublish-box (todo)
Health Care Devices  Work Group | Maturity Level: 0 | Draft | Security Category: Patient | Compartments: Device, Patient |
Describes a noteworthycondition or occurrence determined to exist by a device.
DeviceAlert represents a single alert or alarm condition detected and signaled by a patient-connected health / medical device to create clinician’s awareness of a patient safety risk that needs to be addressed.
The patient-connected health / medical device is primarily a communicating physical device operating in an acute care setting (e.g., patient monitor, ventilator, infusion pump, etc.). However, patient-connected Software as a Medical Device (SaMD) and other Health Software “apps” as well as lower acuity care settings are in scope as well – e.g., a fall detector app running on a patient’s mobile device at home.
Alerts / alarms can be of two types:
Alerts / alarms 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., an information to create contextual awareness without requiring timely response).
The specifics of an alert / alarm are described using medical device nomenclature. The preferred value set binding is the Alerts and events partition of the ISO/IEEE 11073-10101 standard for Medical Device Communication Nomenclature.
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.
DeviceAlert is aligned with the ISO/IEC 60601-1-8 medical device alarms standard. Internationally, all medical device regulatory agencies require conformance to the ISO/IEC 60601-1-8 standard as a pre-requisite for alarming devices to being allowed for use on patients.
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 Device Alert State Patterns section of the DeviceAlert mockup page.
The nature of device alerts makes them unfit to be modelled by other FHIR resources, as further elaborated in the Resource Boundaries section below. Yet, some of the candidate resources considered in that section may be used complementarily. For example, in a home care setting, a patient fall condition detected by a patient-worn phone app (DeviceAlert) may immediately trigger a local alert signal in the app (DeviceAlert) as well as remote alert signal in the caregiving family member app (DeviceAlert), while hours / days later the treating physician may receive 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).
DeviceAlert follows the Event pattern.
The following standards and specifications all form the basis for this specialized FHIR resource:
The following acute care scenarios provide examples of how this resource will be utilized:
Personal health scenarios include:
DeviceAlert directly references:
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).
Although there is similarity in that both Flag and DeviceAlert indicate "significant information", 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 key difference between both resources is that the purpose of Flag is to highlight selected relevant information from a patient record, whereas DeviceAlert is not extracted from (or sometimes even recorded in) the patient record.
In addition, Flag focuses on the display of the warning or notification, while DeviceAlert may also lead to other types of alert signal manifestations: audible (e.g., beeping patterns) and haptic (e.g., vibration of handheld alert communicator).
Also note that DeviceAlert- in acute care settings - often relates to life-threatening situations to which clinicians should react within minutes. Flag will seldom have such degree of urgency and will often have a significantly longer notice period.
DeviceAlert also tracks both the state of the alert condition as well the state of any related alert signal(s). It is possible that for some alerts (especially low priority ones), a Flag may be an additional suitable means of annunciating.
DetectedIssue indicates an actual or potential clinical issue with or between one or more active or proposed clinical actions for a patient.
However, DeviceAlert is not necessarily triggered by clinical actions. In most cases it is triggered by physiological processes (e.g., hemodynamic deterioration) or physical phenomena (e.g., EKG lead falls off). Also, they are differently processed and directed than detected issues.
The DetectedIssue structure includes the evidence and mitigation of the issue; DeviceAlert "evidence" is typically an out-of-range Device Observation, and mitigation is out of the scope.
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 with Communication is that DeviceAlert is not sent with the purpose of "adherence to guidelines or protocols or to provide business documentation of actions taken".
Observation is intended for capturing measurements and subjective point-in-time assessments. DeviceAlert does not share that intent.
However, Observation may be used to complement DeviceAlert, identifying any evidentiary data needed to interpret the alert condition or that is the reason why the alert condition is present. An example of the latter is a DeviceAlert on tachycardia that references (through DeviceAlert.derivedFrom) an Observation of patient’s heart rate is 183 beats per minute
The Subscription resource describes a particular client's request to a FHIR server to be notified about a SubscriptionTopic. Contrarily, device alerts are events that a device determines and signals. They may be pushed onto a FHIR server or another receiving actor, but without consumer-controlled filtering. Consumer-controlled filtering (e.g., based on subscriptions to device observations for a certain Observation.code and, possibly to a certain range of Observation.value) would typically be impossible or unpractical as the consumer might not know what to exactly subscribe to, and/or the FHIR server subscription management load would create a scalability challenge:
Moreover, alerting documentation and logging are key use cases for DeviceAlert that do not fit well with the run-time nature of subscriptions.
AuditEvent records an event relevant for purposes such as operations, privacy, security, maintenance, and performance analysis. Its content is primarily intended for administrative or operational use. However, device alerts are relevant for clinical purposes, most notably to trigger a clinical action (e.g., to refill an infusion pump).
Moreover, a DeviceAlert record includes several events that are recorded through the lifecycle of an alert: a condition arises (e.g., too low heart rate), the condition is no longer present, the condition acknowledged / acted on, and each related signal (siren, light, etc.) is on/off/paused/latched. Tracking all these as independent AuditEvent resources would lead to significant duplicative information and would complicate the consolidation and review the state history around a device alert. AuditEvents are not meant to be edited, which is something that is often needed for device alerts due to their state dynamics.
The DeviceAlert resource has two aspects: the condition aspect which represents a single alert or alarm condition detected and signaled by a patient-connected health / medical device, and the signal aspect which represents the signals, that is, the audible, visible, haptic or other means by which attention is drawn to the existence of the alert condition.
The design and configuration choices applied to the device determine the signal behavior. Signals may persist when the alert condition no longer exist and may be affected by manual user controls of the device. This is the case with when the signal is designed to be subject to latching, which causes a brief alert to be extended to bring it to the attention of the user, or it may be subject to pausing, there a user causes the alert signal to be paused to stop the signal when the user has been made aware of the alert condition and wishes to stop the signal once it is no longer needed.
The center row of the diagram shows the flow between the states of the DeviceAlert 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 of the DeviceAlert resource instance and of the associated DeviceMetric in the corresponding states. The bottom row shows values of key attributes of the DeviceAlert in the states.
No references for this Resource.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
  DeviceAlert |
D | DomainResource | Describes a noteworthy condition or occurrence determined to exist by a medical device Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension | |
  identifier |
Σ | 0..* | Identifier | Instance identifier |
 status |
?!Σ | 1..1 | code | in-progress | completed | entered-in-error Binding: DeviceAlert Status Codes (Required) |
  condition |
Σ | 1..1 | BackboneElement | The condition, event, or state being reported |
 code |
Σ | 1..1 | CodeableConcept | The meaning of the alert Binding: DeviceAlert Condition Codes (Preferred) |
| presence |
Σ | 1..1 | boolean | The alert condition is currently occuring |
| timing |
0..1 | Period | The period during which the condition was active | |
 limit |
0..1 | Range | The boundaries outside of which a value was detected to cause the alert condition | |
| priority |
Σ | 0..1 | code | high | medium | low | info Binding: DeviceAlert Priority Codes (Required) |
| type |
0..1 | code | physiological | technical Binding: DeviceAlert Type Codes (Required) | |
 subject |
Σ | 1..1 | Reference(Patient | Device) | The who or what the alert is about |
| source |
0..1 | Reference(Device | DeviceMetric) | The device (or DeviceMetric) that detected the alert condition | |
| derivedFrom |
0..* | Reference(Observation) | The value causing the alert condition | |
| label |
0..1 | string | Text to be displayed for the alert condition | |
 signal |
0..* | BackboneElement | Annunciation or notification of the alert condition | |
 activationState |
Σ | 1..1 | code | on | off | paused Binding: DeviceAlert Activation State Codes (Required) |
| presence |
0..1 | code | on | latched | off | ack Binding: DeviceAlert Presence Codes (Required) | |
| annunciator |
0..1 | CodeableReference(Device) | Where the signal is being annunciated Binding: DeviceAlert Annunciation Codes (Required) | |
| manifestation |
0..* | CodeableConcept | How the signal is being annunciated Binding: DeviceAlert Manifestation Codes (Extensible) | |
| type |
0..* | CodeableConcept | Characteristics of the signal manifestation | |
| indication |
0..1 | Period | When the signal was being annuciated | |
| Documentation for this format | ||||
See the Extensions for this resource
UML Diagram (Legend)
XML Template
<DeviceAlert xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <identifier><!-- 0..* Identifier Instance identifier --></identifier> <status value="[code]"/><!-- 1..1 in-progress | completed | entered-in-error --> <condition> <!-- 1..1 The condition, event, or state being reported --> <code><!-- 1..1 CodeableConcept The meaning of the alert --></code> <presence value="[boolean]"/><!-- 1..1 The alert condition is currently occuring --> <timing><!-- 0..1 Period The period during which the condition was active --></timing> <limit><!-- 0..1 Range The boundaries outside of which a value was detected to cause the alert condition --></limit> </condition> <priority value="[code]"/><!-- 0..1 high | medium | low | info --> <type value="[code]"/><!-- 0..1 physiological | technical --> <subject><!-- 1..1 Reference(Device|Patient) The who or what the alert is about --></subject> <source><!-- 0..1 Reference(Device|DeviceMetric) The device (or DeviceMetric) that detected the alert condition --></source> <derivedFrom><!-- 0..* Reference(Observation) The value causing the alert condition --></derivedFrom> <label value="[string]"/><!-- 0..1 Text to be displayed for the alert condition --> <signal> <!-- 0..* Annunciation or notification of the alert condition --> <activationState value="[code]"/><!-- 1..1 on | off | paused --> <presence value="[code]"/><!-- 0..1 on | latched | off | ack --> <annunciator><!-- 0..1 CodeableReference(Device) Where the signal is being annunciated --></annunciator> <manifestation><!-- 0..* CodeableConcept How the signal is being annunciated --></manifestation> <type><!-- 0..* CodeableConcept Characteristics of the signal manifestation --></type> <indication><!-- 0..1 Period When the signal was being annuciated --></indication> </signal> </DeviceAlert>
JSON Template
{
"resourceType" : "DeviceAlert",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // Instance identifier
"status" : "<code>", // R! in-progress | completed | entered-in-error
"condition" : { // R! The condition, event, or state being reported
"code" : { CodeableConcept }, // R! The meaning of the alert
"presence" : <boolean>, // R! The alert condition is currently occuring
"timing" : { Period }, // The period during which the condition was active
"limit" : { Range } // The boundaries outside of which a value was detected to cause the alert condition
},
"priority" : "<code>", // high | medium | low | info
"type" : "<code>", // physiological | technical
"subject" : { Reference(Device|Patient) }, // R! The who or what the alert is about
"source" : { Reference(Device|DeviceMetric) }, // The device (or DeviceMetric) that detected the alert condition
"derivedFrom" : [{ Reference(Observation) }], // The value causing the alert condition
"label" : "<string>", // Text to be displayed for the alert condition
"signal" : [{ // Annunciation or notification of the alert condition
"activationState" : "<code>", // R! on | off | paused
"presence" : "<code>", // on | latched | off | ack
"annunciator" : { CodeableReference(Device) }, // Where the signal is being annunciated
"manifestation" : [{ CodeableConcept }], // How the signal is being annunciated
"type" : [{ CodeableConcept }], // Characteristics of the signal manifestation
"indication" : { Period } // When the signal was being annuciated
}]
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .
Changes from both R4 and R4B
This resource did not exist in Release R4
See the Full Difference for further information
This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| DeviceAlert |
D | DomainResource | Describes a noteworthy condition or occurrence determined to exist by a medical device Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension | |
| identifier |
Σ | 0..* | Identifier | Instance identifier |
| status |
?!Σ | 1..1 | code | in-progress | completed | entered-in-error Binding: DeviceAlert Status Codes (Required) |
| condition |
Σ | 1..1 | BackboneElement | The condition, event, or state being reported |
| code |
Σ | 1..1 | CodeableConcept | The meaning of the alert Binding: DeviceAlert Condition Codes (Preferred) |
| presence |
Σ | 1..1 | boolean | The alert condition is currently occuring |
| timing |
0..1 | Period | The period during which the condition was active | |
| limit |
0..1 | Range | The boundaries outside of which a value was detected to cause the alert condition | |
| priority |
Σ | 0..1 | code | high | medium | low | info Binding: DeviceAlert Priority Codes (Required) |
| type |
0..1 | code | physiological | technical Binding: DeviceAlert Type Codes (Required) | |
| subject |
Σ | 1..1 | Reference(Patient | Device) | The who or what the alert is about |
| source |
0..1 | Reference(Device | DeviceMetric) | The device (or DeviceMetric) that detected the alert condition | |
| derivedFrom |
0..* | Reference(Observation) | The value causing the alert condition | |
| label |
0..1 | string | Text to be displayed for the alert condition | |
| signal |
0..* | BackboneElement | Annunciation or notification of the alert condition | |
| activationState |
Σ | 1..1 | code | on | off | paused Binding: DeviceAlert Activation State Codes (Required) |
| presence |
0..1 | code | on | latched | off | ack Binding: DeviceAlert Presence Codes (Required) | |
| annunciator |
0..1 | CodeableReference(Device) | Where the signal is being annunciated Binding: DeviceAlert Annunciation Codes (Required) | |
| manifestation |
0..* | CodeableConcept | How the signal is being annunciated Binding: DeviceAlert Manifestation Codes (Extensible) | |
| type |
0..* | CodeableConcept | Characteristics of the signal manifestation | |
| indication |
0..1 | Period | When the signal was being annuciated | |
| Documentation for this format | ||||
See the Extensions for this resource
XML Template
<DeviceAlert xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "DeviceAlert",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // Instance identifier
"status" : "<code>", // R! in-progress | completed | entered-in-error
"condition" : { // R! The condition, event, or state being reported
"code" : { CodeableConcept }, // R! The meaning of the alert
"presence" : <boolean>, // R! The alert condition is currently occuring
"timing" : { Period }, // The period during which the condition was active
"limit" : { Range } // The boundaries outside of which a value was detected to cause the alert condition
},
"priority" : "<code>", // high | medium | low | info
"type" : "<code>", // physiological | technical
"subject" : { Reference(Device|Patient) }, // R! The who or what the alert is about
"source" : { Reference(Device|DeviceMetric) }, // The device (or DeviceMetric) that detected the alert condition
"derivedFrom" : [{ Reference(Observation) }], // The value causing the alert condition
"label" : "<string>", // Text to be displayed for the alert condition
"signal" : [{ // Annunciation or notification of the alert condition
"activationState" : "<code>", // R! on | off | paused
"presence" : "<code>", // on | latched | off | ack
"annunciator" : { CodeableReference(Device) }, // Where the signal is being annunciated
"manifestation" : [{ CodeableConcept }], // How the signal is being annunciated
"type" : [{ CodeableConcept }], // Characteristics of the signal manifestation
"indication" : { Period } // When the signal was being annuciated
}]
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .
Changes from both R4 and R4B
This resource did not exist in Release R4
See the Full Difference for further information
This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.
Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis
| Path | ValueSet | Type | Documentation |
|---|---|---|---|
| DeviceAlert.status | DeviceAlertStatusCodes (a valid code from Device Alert Status) | Required | DeviceAlert Status Codes |
| DeviceAlert.condition.code | DeviceAlertConditionCodes | Preferred | DeviceAlert Condition Codes |
| DeviceAlert.priority | DeviceAlertPriorityCodes (a valid code from Device Alert Priority) | Required | DeviceAlert Priority Codes |
| DeviceAlert.type | DeviceAlertTypeCodes (a valid code from Device Alert Type) | Required | DeviceAlert Type Codes |
| DeviceAlert.signal.activationState | DeviceAlertActivationStateCodes (a valid code from Device Alert Activation State) | Required | DeviceAlert Activation State Codes |
| DeviceAlert.signal.presence | DeviceAlertPresenceCodes (a valid code from Device Alert Presence) | Required | DeviceAlert Presence Codes |
| DeviceAlert.signal.annunciator | DeviceAlertAnnunciationCodes (a valid code from Device Alert Annunciation) | Required | DeviceAlert Annunciation Codes |
| DeviceAlert.signal.manifestation | DeviceAlertManifestationCodes (a valid code from Device Alert Manifestation) | Extensible | DeviceAlert Manifestation Codes |
Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.
| Name | Type | Description | Expression | In Common |
| annunciator-concept | token | The whether the signalling device annunciating the condition is local or remote to the detecting device | DeviceAlert.signal.annunciator.concept | |
| annunciator-device | reference | The signalling device annunciating the condition | DeviceAlert.signal.annunciator.reference | |
| code | token | Alert condition code | DeviceAlert.condition.code | |
| derived-from | reference | Whether the alert is currently occuring | DeviceAlert.derivedFrom (Observation) |
|
| identifier | token | The identifier of the alert | DeviceAlert.identifier | |
| indication | date | When the signal was being annunciated | DeviceAlert.signal.indication | |
| manifestation | token | How the alert signal is manifested | DeviceAlert.signal.manifestation | |
| patient | reference | The patient subject of the alert | DeviceAlert.subject.where(resolve() is Patient) (Patient) |
|
| presence | token | Whether the alert condition is currently occuring | DeviceAlert.condition.presence | |
| priority | token | Priority of the alert condition | DeviceAlert.priority | |
| signal-presence | token | Whether the alert is currently occuring | DeviceAlert.signal.presence | |
| source | reference | The device detecting the condition | DeviceAlert.source (Device, DeviceMetric) |
|
| status | token | Status of the alert | DeviceAlert.status | |
| subject | reference | Subject (patient or device) of the alert | DeviceAlert.subject (Device, Patient) |
|
| timing | date | When the alert condition occured | DeviceAlert.condition.timing | |
| type | token | Whether the alert is physiological or technical | DeviceAlert.type |
FHIR ®© HL7.org 2011+. FHIR R6 hl7.fhir.core#6.0.0-ballot2 generated on Mon, Aug 12, 2024 16:58+0800.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R5 |
|
Propose a change