FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

8.16 Resource DeviceAlert - Content

Responsible Owner: Health Care Devices icon Work Group DraftSecurity Category: Patient Compartments: Device, Encounter, Group, Patient, Practitioner, RelatedPerson

Describes a noteworthy condition or occurrence determined to exist by a device.

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

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 should be considered as part of complete systems engineering activity to achieve timely, reliable, alert notification.

 

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, may be used complementarily. For example, in a home care setting, a patient fall condition detected by a phone app (DeviceAlert) may trigger a remote alert signal in the caregiving family member app (DeviceAlert), while, 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).

8.16.1.1 Usage Scenarios

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

  • A vital signs monitor detects a low heart rate condition and signals an alarm that gets communicated to a FHIR-enabled system for information documentation purposes.
  • A patient-worn watch monitoring heart information identifies a hypertensive condition and issues an alarm to notify the user.
  • Alert conditions from devices associated with 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 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, or filters out lower-priority/duplicative alert conditions detected by individual devices.
  • 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.
  • A quality analytics application periodically reviews device alert information and identifies opportunities for process improvement.

8.16.1.2 Boundaries and Relationships

8.16.1.2.1 Resource Relationships

This resource 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, or Device to identify the device the technical alert is about. Additional potential subjects of an alert could be Location, Medication, BiologicallyDerivedProduct, Specimen, or NutritionProduct.
  • Observation to identify any evidentiary data needed to interpret the alert condition or that is the reason why the alert condition is present.
  • Procedure and Encounter to identify relevant context of the alert condition.

8.16.1.2.2 Resource Boundaries

8.16.1.2.2.1 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 may 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 may be a suitable supplementary means of annunciating through the patient record.

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

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

8.16.1.2.2.4 Observation

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

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

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

8.16.1.3 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 may 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 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 icon extension, which may be applied to either Device or DeviceMetric. The bottom row shows values of key attributes of the DeviceAlert resource instance in the corresponding states.

8.16.2 References to this Resource

8.16.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
.. DeviceAlert D DomainResource Documentation of an alert (a.k.a. alarm) generated by a device indicating a noteworthy condition

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Business identifier for this device alert

... procedure Σ 0..* Reference(Procedure) Procedure during which the alert occurred

... status ?!Σ 1..1 code in-progress | completed | entered-in-error | unknown
Binding: DeviceAlert Status Codes (Required)
... type 0..1 CodeableConcept physiological | technical
Binding: DeviceAlert Type Codes (Extensible)
... priority Σ 0..1 CodeableConcept high | medium | low | info
Binding: DeviceAlert Priority Codes (Extensible)
... code Σ 1..1 CodeableConcept The meaning of the alert
Binding: DeviceAlert Condition Codes (Preferred)
... subject Σ 1..1 Reference(Patient | Device | BiologicallyDerivedProduct | Group | Location | Medication | NutritionProduct | Specimen) Who or what the alert is about
... encounter Σ 0..1 Reference(Encounter) Encounter during which the alert condition occurred
... presence Σ 1..1 boolean Whether the alert condition is currently active
... occurrence[x] Σ 0..1 When the alert condition occurred/is occurring
.... occurrenceDateTime dateTime
.... occurrencePeriod Period
... device Σ 0..1 Reference(Device | DeviceMetric) The Device (or DeviceMetric) that detected the alert condition
... acknowledged 0..1 boolean Whether the alert condition has been acknowledged
... acknowledgedBy 0..1 Reference(Patient | Device | Practitioner | PractitionerRole | RelatedPerson) Who acknowledged the alert condition
... location Σ 0..1 Reference(Location) Location of the subject when the alert was raised
... derivedFrom 0..* BackboneElement The value causing the alert condition

.... observation Σ 1..1 Reference(Observation) The Observation having a value causing the alert condition
.... component 0..1 Coding The Observation.component having a value causing the alert condition
Binding: LOINC Codes (Example)
.... limit 0..1 Range The boundaries beyond which a value was detected to cause 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 CodeableConcept on | off | paused
Binding: DeviceAlert Activation State Codes (Extensible)
.... presence 0..1 CodeableConcept on | latched | off | ack
Binding: DeviceAlert Presence Codes (Extensible)
.... annunciator 0..1 CodeableReference(Device) Where the signal is being annunciated
Binding: DeviceAlert Annunciation Codes (Required)
.... manifestation 0..1 CodeableConcept How the signal is being annunciated
Binding: DeviceAlert Manifestation Codes (Extensible)
.... type 0..* CodeableConcept Characteristics of the signal manifestation
Binding: DeviceAlert Signal Type Codes (Example)

.... indication 0..1 Period When the signal was being annunciated

doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

DeviceAlert (DomainResource)Business identifiers assigned to this alert, by the source device, gateway software, manufacturers, or other systems or organizations. These identifiers remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]The procedure (or procedures) during which the alert condition was raisedprocedure : Reference [0..*] « Procedure »The current state of the device alert (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)DeviceAlertStatusCodes! »Partitions the device alert into one or more categories that can be used to filter searching, to govern access control and/or to guide system behaviorcategory : CodeableConcept [0..*] « null (Strength=Example)DeviceAlertCategoryCodes?? »physiological | technicaltype : CodeableConcept [0..1] « null (Strength=Extensible)DeviceAlertTypeCodes+ »The alert priority is usually reported by the source device. A priority of `info` may indicate that the alert is “for information only” and not urgent action is required. The element may be omitted if the priority is unknownpriority : CodeableConcept [0..1] « null (Strength=Extensible)DeviceAlertPriorityCodes+ »A code that indicates the specific condition that triggered the alertcode : CodeableConcept [1..1] « null (Strength=Preferred)DeviceAlertConditionCodes? »Who or what the alert is aboutsubject : Reference [1..1] « Patient|Device| BiologicallyDerivedProduct|Group|Location|Medication| NutritionProduct|Specimen »The Encounter during which the alert condition was raisedencounter : Reference [0..1] « Encounter »Whether the alert condition is currently activepresence : boolean [1..1]This element is used to record the date or time period when the alert condition did occur or is occurringoccurrence[x] : DataType [0..1] « dateTime|Period »Indicates the device that detected the alert condition. The device may be a top-level Device or component Device (such as an MDS, VMD, or Channel); or may identify the specific DeviceMetric of a Device (e.g., a heart rate reading) that was in an alert conditiondevice : Reference [0..1] « Device|DeviceMetric »An indication of whether (true) or not (false) the alert condition has been acknowledgedacknowledged : boolean [0..1]An indication of who or what acknowledged the alert conditionacknowledgedBy : Reference [0..1] « Patient|Device|Practitioner| PractitionerRole|RelatedPerson »The principal physical location of the subject at the time the alert condition occurred. This may be different from the location of the alerting device at that time, and from the current location of either the subject or the alert condition detecting devicelocation : Reference [0..1] « Location »The label may combine information from the alert code, priority, the measurement type, measurement value, body sites and other sources, e.g., “HR > 180”label : string [0..1]DerivedFromIndicates the Observation whose value is causing the alert condition; or, if `component` is present, the Observation with a component causing the alert conditionobservation : Reference [1..1] « Observation »If applicable, the code of the component (of the Observation identified in `derivedFrom.observation`) having a value causing the alert condition. This may be used when the alert is associated with a specific component of an Observation, rather than the overall Observation; for example, a low diastolic blood pressure. Since the component is identified by matching `Observation.component.code`, if more than one component have the same code, the specific component is ambiguous. Repetitions of this element indicate additional components contributing to the alert conditioncomponent : Coding [0..1] « null (Strength=Example)LOINCCodes?? »The limits beyond which a value was detected to cause the alert condition. The actual value is the `Observation.value[x]` referenced by `derivedFrom.observation` or, if specified, the `Observation.component.value[x]` of the component (with `Observation.component.code` matching `derivedFrom.component`) of the reference Observationlimit : Range [0..1]SignalPaused indicates that annunciation has temporarily been disabled ("snooze")activationState : CodeableConcept [1..1] « null (Strength=Extensible) DeviceAlertActivationStateCod...+ »Indicates whether the signal is currently being annunciated. An on signal is currently being annunciated; a latched signal is currently being being annunciated although the alert condition has ended; an off signal is not currently being annunciated; and an acknowledged signal is not currently being annunciated because the user has acknowledged the signalpresence : CodeableConcept [0..1] « null (Strength=Extensible)DeviceAlertPresenceCodes+ »Signalling by the source device is local; signalling elsewhere is considered remote. A reference to the "top level" signalling device may also be presentannunciator : CodeableReference [0..1] « Device; null (Strength=Required) DeviceAlertAnnunciationCodes! »How the signal is being annunciatedmanifestation : CodeableConcept [0..1] « null (Strength=Extensible) DeviceAlertManifestationCodes+ »Details of the signal manifestation, such as a 1 meter visual indicator or a 4 meter visual indicatortype : CodeableConcept [0..*] « null (Strength=Example)DeviceAlertSignalTypeCodes?? »The period during which the signal was being annunciated. If there is no indicated period end, the annunciation is on-goingindication : Period [0..1]The value causing the alert conditionderivedFrom[0..*]Annunciation or notification of the alert conditionsignal[0..*]

XML Template

<DeviceAlert xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Business identifier for this device alert --></identifier>
 <procedure><!-- 0..* Reference(Procedure) Procedure during which the alert occurred --></procedure>
 <status value="[code]"/><!-- 1..1 in-progress | completed | entered-in-error | unknown -->
 <category><!-- 0..* CodeableConcept High level categorization of device alert --></category>
 <type><!-- 0..1 CodeableConcept physiological | technical --></type>
 <priority><!-- 0..1 CodeableConcept high | medium | low | info --></priority>
 <code><!-- 1..1 CodeableConcept The meaning of the alert --></code>
 <subject><!-- 1..1 Reference(BiologicallyDerivedProduct|Device|Group|Location|
   Medication|NutritionProduct|Patient|Specimen) Who or what the alert is about --></subject>
 <encounter><!-- 0..1 Reference(Encounter) Encounter during which the alert condition occurred --></encounter>
 <presence value="[boolean]"/><!-- 1..1 Whether the alert condition is currently active -->
 <occurrence[x]><!-- 0..1 dateTime|Period When the alert condition occurred/is occurring --></occurrence[x]>
 <device><!-- 0..1 Reference(Device|DeviceMetric) The Device (or DeviceMetric) that detected the alert condition --></device>
 <acknowledged value="[boolean]"/><!-- 0..1 Whether the alert condition has been acknowledged -->
 <acknowledgedBy><!-- 0..1 Reference(Device|Patient|Practitioner|PractitionerRole|
   RelatedPerson) Who acknowledged the alert condition --></acknowledgedBy>
 <location><!-- 0..1 Reference(Location) Location of the subject when the alert was raised --></location>
 <derivedFrom>  <!-- 0..* The value causing the alert condition -->
  <observation><!-- 1..1 Reference(Observation) The Observation having a value causing the alert condition --></observation>
  <component><!-- 0..1 Coding The Observation.component having a value causing the alert condition --></component>
  <limit><!-- 0..1 Range The boundaries beyond which a value was detected to cause the alert condition --></limit>
 </derivedFrom>
 <label value="[string]"/><!-- 0..1 Text to be displayed for the alert condition -->
 <signal>  <!-- 0..* Annunciation or notification of the alert condition -->
  <activationState><!-- 1..1 CodeableConcept on | off | paused --></activationState>
  <presence><!-- 0..1 CodeableConcept on | latched | off | ack --></presence>
  <annunciator><!-- 0..1 CodeableReference(Device) Where the signal is being annunciated --></annunciator>
  <manifestation><!-- 0..1 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 annunciated --></indication>
 </signal>
</DeviceAlert>

JSON Template

{doco
  "resourceType" : "DeviceAlert",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Business identifier for this device alert
  "procedure" : [{ Reference(Procedure) }], // Procedure during which the alert occurred
  "status" : "<code>", // R!  in-progress | completed | entered-in-error | unknown
  "category" : [{ CodeableConcept }], // High level categorization of device alert
  "type" : { CodeableConcept }, // physiological | technical
  "priority" : { CodeableConcept }, // high | medium | low | info
  "code" : { CodeableConcept }, // R!  The meaning of the alert
  "subject" : { Reference(BiologicallyDerivedProduct|Device|Group|Location|
   Medication|NutritionProduct|Patient|Specimen) }, // R!  Who or what the alert is about
  "encounter" : { Reference(Encounter) }, // Encounter during which the alert condition occurred
  "presence" : <boolean>, // R!  Whether the alert condition is currently active
  // occurrence[x]: When the alert condition occurred/is occurring. One of these 2:
  "occurrenceDateTime" : "<dateTime>",
  "occurrencePeriod" : { Period },
  "device" : { Reference(Device|DeviceMetric) }, // The Device (or DeviceMetric) that detected the alert condition
  "acknowledged" : <boolean>, // Whether the alert condition has been acknowledged
  "acknowledgedBy" : { Reference(Device|Patient|Practitioner|PractitionerRole|
   RelatedPerson) }, // Who acknowledged the alert condition
  "location" : { Reference(Location) }, // Location of the subject when the alert was raised
  "derivedFrom" : [{ // The value causing the alert condition
    "observation" : { Reference(Observation) }, // R!  The Observation having a value causing the alert condition
    "component" : { Coding }, // The Observation.component having a value causing the alert condition
    "limit" : { Range } // The boundaries beyond which a value was detected to cause the alert condition
  }],
  "label" : "<string>", // Text to be displayed for the alert condition
  "signal" : [{ // Annunciation or notification of the alert condition
    "activationState" : { CodeableConcept }, // R!  on | off | paused
    "presence" : { CodeableConcept }, // 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 annunciated
  }]
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:DeviceAlert;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: fhir:id, fhir:meta, fhir:implicitRules, and fhir:language
  # from DomainResource: fhir:text, fhir:contained, fhir:extension, and fhir:modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Business identifier for this device alert
  fhir:procedure  ( [ Reference(Procedure) ] ... ) ; # 0..* Procedure during which the alert occurred
  fhir:status [ code ] ; # 1..1 in-progress | completed | entered-in-error | unknown
  fhir:category  ( [ CodeableConcept ] ... ) ; # 0..* High level categorization of device alert
  fhir:type [ CodeableConcept ] ; # 0..1 physiological | technical
  fhir:priority [ CodeableConcept ] ; # 0..1 high | medium | low | info
  fhir:code [ CodeableConcept ] ; # 1..1 The meaning of the alert
  fhir:subject [ Reference(BiologicallyDerivedProduct|Device|Group|Location|Medication|NutritionProduct|
  Patient|Specimen) ] ; # 1..1 Who or what the alert is about
  fhir:encounter [ Reference(Encounter) ] ; # 0..1 Encounter during which the alert condition occurred
  fhir:presence [ boolean ] ; # 1..1 Whether the alert condition is currently active
  # occurrence[x] : 0..1 When the alert condition occurred/is occurring. One of these 2
    fhir:occurrence [  a fhir:DateTime ; dateTime ]
    fhir:occurrence [  a fhir:Period ; Period ]
  fhir:device [ Reference(Device|DeviceMetric) ] ; # 0..1 The Device (or DeviceMetric) that detected the alert condition
  fhir:acknowledged [ boolean ] ; # 0..1 Whether the alert condition has been acknowledged
  fhir:acknowledgedBy [ Reference(Device|Patient|Practitioner|PractitionerRole|RelatedPerson) ] ; # 0..1 Who acknowledged the alert condition
  fhir:location [ Reference(Location) ] ; # 0..1 Location of the subject when the alert was raised
  fhir:derivedFrom ( [ # 0..* The value causing the alert condition
    fhir:observation [ Reference(Observation) ] ; # 1..1 The Observation having a value causing the alert condition
    fhir:component [ Coding ] ; # 0..1 The Observation.component having a value causing the alert condition
    fhir:limit [ Range ] ; # 0..1 The boundaries beyond which a value was detected to cause the alert condition
  ] ... ) ;
  fhir:label [ string ] ; # 0..1 Text to be displayed for the alert condition
  fhir:signal ( [ # 0..* Annunciation or notification of the alert condition
    fhir:activationState [ CodeableConcept ] ; # 1..1 on | off | paused
    fhir:presence [ CodeableConcept ] ; # 0..1 on | latched | off | ack
    fhir:annunciator [ CodeableReference(Device) ] ; # 0..1 Where the signal is being annunciated
    fhir:manifestation [ CodeableConcept ] ; # 0..1 How the signal is being annunciated
    fhir:type  ( [ CodeableConcept ] ... ) ; # 0..* Characteristics of the signal manifestation
    fhir:indication [ Period ] ; # 0..1 When the signal was being annunciated
  ] ... ) ;
]

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

NameFlagsCard.TypeDescription & Constraints    Filter: Filtersdoco
.. DeviceAlert D DomainResource Documentation of an alert (a.k.a. alarm) generated by a device indicating a noteworthy condition

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Business identifier for this device alert

... procedure Σ 0..* Reference(Procedure) Procedure during which the alert occurred

... status ?!Σ 1..1 code in-progress | completed | entered-in-error | unknown
Binding: DeviceAlert Status Codes (Required)
... type 0..1 CodeableConcept physiological | technical
Binding: DeviceAlert Type Codes (Extensible)
... priority Σ 0..1 CodeableConcept high | medium | low | info
Binding: DeviceAlert Priority Codes (Extensible)
... code Σ 1..1 CodeableConcept The meaning of the alert
Binding: DeviceAlert Condition Codes (Preferred)
... subject Σ 1..1 Reference(Patient | Device | BiologicallyDerivedProduct | Group | Location | Medication | NutritionProduct | Specimen) Who or what the alert is about
... encounter Σ 0..1 Reference(Encounter) Encounter during which the alert condition occurred
... presence Σ 1..1 boolean Whether the alert condition is currently active
... occurrence[x] Σ 0..1 When the alert condition occurred/is occurring
.... occurrenceDateTime dateTime
.... occurrencePeriod Period
... device Σ 0..1 Reference(Device | DeviceMetric) The Device (or DeviceMetric) that detected the alert condition
... acknowledged 0..1 boolean Whether the alert condition has been acknowledged
... acknowledgedBy 0..1 Reference(Patient | Device | Practitioner | PractitionerRole | RelatedPerson) Who acknowledged the alert condition
... location Σ 0..1 Reference(Location) Location of the subject when the alert was raised
... derivedFrom 0..* BackboneElement The value causing the alert condition

.... observation Σ 1..1 Reference(Observation) The Observation having a value causing the alert condition
.... component 0..1 Coding The Observation.component having a value causing the alert condition
Binding: LOINC Codes (Example)
.... limit 0..1 Range The boundaries beyond which a value was detected to cause 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 CodeableConcept on | off | paused
Binding: DeviceAlert Activation State Codes (Extensible)
.... presence 0..1 CodeableConcept on | latched | off | ack
Binding: DeviceAlert Presence Codes (Extensible)
.... annunciator 0..1 CodeableReference(Device) Where the signal is being annunciated
Binding: DeviceAlert Annunciation Codes (Required)
.... manifestation 0..1 CodeableConcept How the signal is being annunciated
Binding: DeviceAlert Manifestation Codes (Extensible)
.... type 0..* CodeableConcept Characteristics of the signal manifestation
Binding: DeviceAlert Signal Type Codes (Example)

.... indication 0..1 Period When the signal was being annunciated

doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

DeviceAlert (DomainResource)Business identifiers assigned to this alert, by the source device, gateway software, manufacturers, or other systems or organizations. These identifiers remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]The procedure (or procedures) during which the alert condition was raisedprocedure : Reference [0..*] « Procedure »The current state of the device alert (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)DeviceAlertStatusCodes! »Partitions the device alert into one or more categories that can be used to filter searching, to govern access control and/or to guide system behaviorcategory : CodeableConcept [0..*] « null (Strength=Example)DeviceAlertCategoryCodes?? »physiological | technicaltype : CodeableConcept [0..1] « null (Strength=Extensible)DeviceAlertTypeCodes+ »The alert priority is usually reported by the source device. A priority of `info` may indicate that the alert is “for information only” and not urgent action is required. The element may be omitted if the priority is unknownpriority : CodeableConcept [0..1] « null (Strength=Extensible)DeviceAlertPriorityCodes+ »A code that indicates the specific condition that triggered the alertcode : CodeableConcept [1..1] « null (Strength=Preferred)DeviceAlertConditionCodes? »Who or what the alert is aboutsubject : Reference [1..1] « Patient|Device| BiologicallyDerivedProduct|Group|Location|Medication| NutritionProduct|Specimen »The Encounter during which the alert condition was raisedencounter : Reference [0..1] « Encounter »Whether the alert condition is currently activepresence : boolean [1..1]This element is used to record the date or time period when the alert condition did occur or is occurringoccurrence[x] : DataType [0..1] « dateTime|Period »Indicates the device that detected the alert condition. The device may be a top-level Device or component Device (such as an MDS, VMD, or Channel); or may identify the specific DeviceMetric of a Device (e.g., a heart rate reading) that was in an alert conditiondevice : Reference [0..1] « Device|DeviceMetric »An indication of whether (true) or not (false) the alert condition has been acknowledgedacknowledged : boolean [0..1]An indication of who or what acknowledged the alert conditionacknowledgedBy : Reference [0..1] « Patient|Device|Practitioner| PractitionerRole|RelatedPerson »The principal physical location of the subject at the time the alert condition occurred. This may be different from the location of the alerting device at that time, and from the current location of either the subject or the alert condition detecting devicelocation : Reference [0..1] « Location »The label may combine information from the alert code, priority, the measurement type, measurement value, body sites and other sources, e.g., “HR > 180”label : string [0..1]DerivedFromIndicates the Observation whose value is causing the alert condition; or, if `component` is present, the Observation with a component causing the alert conditionobservation : Reference [1..1] « Observation »If applicable, the code of the component (of the Observation identified in `derivedFrom.observation`) having a value causing the alert condition. This may be used when the alert is associated with a specific component of an Observation, rather than the overall Observation; for example, a low diastolic blood pressure. Since the component is identified by matching `Observation.component.code`, if more than one component have the same code, the specific component is ambiguous. Repetitions of this element indicate additional components contributing to the alert conditioncomponent : Coding [0..1] « null (Strength=Example)LOINCCodes?? »The limits beyond which a value was detected to cause the alert condition. The actual value is the `Observation.value[x]` referenced by `derivedFrom.observation` or, if specified, the `Observation.component.value[x]` of the component (with `Observation.component.code` matching `derivedFrom.component`) of the reference Observationlimit : Range [0..1]SignalPaused indicates that annunciation has temporarily been disabled ("snooze")activationState : CodeableConcept [1..1] « null (Strength=Extensible) DeviceAlertActivationStateCod...+ »Indicates whether the signal is currently being annunciated. An on signal is currently being annunciated; a latched signal is currently being being annunciated although the alert condition has ended; an off signal is not currently being annunciated; and an acknowledged signal is not currently being annunciated because the user has acknowledged the signalpresence : CodeableConcept [0..1] « null (Strength=Extensible)DeviceAlertPresenceCodes+ »Signalling by the source device is local; signalling elsewhere is considered remote. A reference to the "top level" signalling device may also be presentannunciator : CodeableReference [0..1] « Device; null (Strength=Required) DeviceAlertAnnunciationCodes! »How the signal is being annunciatedmanifestation : CodeableConcept [0..1] « null (Strength=Extensible) DeviceAlertManifestationCodes+ »Details of the signal manifestation, such as a 1 meter visual indicator or a 4 meter visual indicatortype : CodeableConcept [0..*] « null (Strength=Example)DeviceAlertSignalTypeCodes?? »The period during which the signal was being annunciated. If there is no indicated period end, the annunciation is on-goingindication : Period [0..1]The value causing the alert conditionderivedFrom[0..*]Annunciation or notification of the alert conditionsignal[0..*]

XML Template

<DeviceAlert xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Business identifier for this device alert --></identifier>
 <procedure><!-- 0..* Reference(Procedure) Procedure during which the alert occurred --></procedure>
 <status value="[code]"/><!-- 1..1 in-progress | completed | entered-in-error | unknown -->
 <category><!-- 0..* CodeableConcept High level categorization of device alert --></category>
 <type><!-- 0..1 CodeableConcept physiological | technical --></type>
 <priority><!-- 0..1 CodeableConcept high | medium | low | info --></priority>
 <code><!-- 1..1 CodeableConcept The meaning of the alert --></code>
 <subject><!-- 1..1 Reference(BiologicallyDerivedProduct|Device|Group|Location|
   Medication|NutritionProduct|Patient|Specimen) Who or what the alert is about --></subject>
 <encounter><!-- 0..1 Reference(Encounter) Encounter during which the alert condition occurred --></encounter>
 <presence value="[boolean]"/><!-- 1..1 Whether the alert condition is currently active -->
 <occurrence[x]><!-- 0..1 dateTime|Period When the alert condition occurred/is occurring --></occurrence[x]>
 <device><!-- 0..1 Reference(Device|DeviceMetric) The Device (or DeviceMetric) that detected the alert condition --></device>
 <acknowledged value="[boolean]"/><!-- 0..1 Whether the alert condition has been acknowledged -->
 <acknowledgedBy><!-- 0..1 Reference(Device|Patient|Practitioner|PractitionerRole|
   RelatedPerson) Who acknowledged the alert condition --></acknowledgedBy>
 <location><!-- 0..1 Reference(Location) Location of the subject when the alert was raised --></location>
 <derivedFrom>  <!-- 0..* The value causing the alert condition -->
  <observation><!-- 1..1 Reference(Observation) The Observation having a value causing the alert condition --></observation>
  <component><!-- 0..1 Coding The Observation.component having a value causing the alert condition --></component>
  <limit><!-- 0..1 Range The boundaries beyond which a value was detected to cause the alert condition --></limit>
 </derivedFrom>
 <label value="[string]"/><!-- 0..1 Text to be displayed for the alert condition -->
 <signal>  <!-- 0..* Annunciation or notification of the alert condition -->
  <activationState><!-- 1..1 CodeableConcept on | off | paused --></activationState>
  <presence><!-- 0..1 CodeableConcept on | latched | off | ack --></presence>
  <annunciator><!-- 0..1 CodeableReference(Device) Where the signal is being annunciated --></annunciator>
  <manifestation><!-- 0..1 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 annunciated --></indication>
 </signal>
</DeviceAlert>

JSON Template

{doco
  "resourceType" : "DeviceAlert",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Business identifier for this device alert
  "procedure" : [{ Reference(Procedure) }], // Procedure during which the alert occurred
  "status" : "<code>", // R!  in-progress | completed | entered-in-error | unknown
  "category" : [{ CodeableConcept }], // High level categorization of device alert
  "type" : { CodeableConcept }, // physiological | technical
  "priority" : { CodeableConcept }, // high | medium | low | info
  "code" : { CodeableConcept }, // R!  The meaning of the alert
  "subject" : { Reference(BiologicallyDerivedProduct|Device|Group|Location|
   Medication|NutritionProduct|Patient|Specimen) }, // R!  Who or what the alert is about
  "encounter" : { Reference(Encounter) }, // Encounter during which the alert condition occurred
  "presence" : <boolean>, // R!  Whether the alert condition is currently active
  // occurrence[x]: When the alert condition occurred/is occurring. One of these 2:
  "occurrenceDateTime" : "<dateTime>",
  "occurrencePeriod" : { Period },
  "device" : { Reference(Device|DeviceMetric) }, // The Device (or DeviceMetric) that detected the alert condition
  "acknowledged" : <boolean>, // Whether the alert condition has been acknowledged
  "acknowledgedBy" : { Reference(Device|Patient|Practitioner|PractitionerRole|
   RelatedPerson) }, // Who acknowledged the alert condition
  "location" : { Reference(Location) }, // Location of the subject when the alert was raised
  "derivedFrom" : [{ // The value causing the alert condition
    "observation" : { Reference(Observation) }, // R!  The Observation having a value causing the alert condition
    "component" : { Coding }, // The Observation.component having a value causing the alert condition
    "limit" : { Range } // The boundaries beyond which a value was detected to cause the alert condition
  }],
  "label" : "<string>", // Text to be displayed for the alert condition
  "signal" : [{ // Annunciation or notification of the alert condition
    "activationState" : { CodeableConcept }, // R!  on | off | paused
    "presence" : { CodeableConcept }, // 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 annunciated
  }]
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:DeviceAlert;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: fhir:id, fhir:meta, fhir:implicitRules, and fhir:language
  # from DomainResource: fhir:text, fhir:contained, fhir:extension, and fhir:modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Business identifier for this device alert
  fhir:procedure  ( [ Reference(Procedure) ] ... ) ; # 0..* Procedure during which the alert occurred
  fhir:status [ code ] ; # 1..1 in-progress | completed | entered-in-error | unknown
  fhir:category  ( [ CodeableConcept ] ... ) ; # 0..* High level categorization of device alert
  fhir:type [ CodeableConcept ] ; # 0..1 physiological | technical
  fhir:priority [ CodeableConcept ] ; # 0..1 high | medium | low | info
  fhir:code [ CodeableConcept ] ; # 1..1 The meaning of the alert
  fhir:subject [ Reference(BiologicallyDerivedProduct|Device|Group|Location|Medication|NutritionProduct|
  Patient|Specimen) ] ; # 1..1 Who or what the alert is about
  fhir:encounter [ Reference(Encounter) ] ; # 0..1 Encounter during which the alert condition occurred
  fhir:presence [ boolean ] ; # 1..1 Whether the alert condition is currently active
  # occurrence[x] : 0..1 When the alert condition occurred/is occurring. One of these 2
    fhir:occurrence [  a fhir:DateTime ; dateTime ]
    fhir:occurrence [  a fhir:Period ; Period ]
  fhir:device [ Reference(Device|DeviceMetric) ] ; # 0..1 The Device (or DeviceMetric) that detected the alert condition
  fhir:acknowledged [ boolean ] ; # 0..1 Whether the alert condition has been acknowledged
  fhir:acknowledgedBy [ Reference(Device|Patient|Practitioner|PractitionerRole|RelatedPerson) ] ; # 0..1 Who acknowledged the alert condition
  fhir:location [ Reference(Location) ] ; # 0..1 Location of the subject when the alert was raised
  fhir:derivedFrom ( [ # 0..* The value causing the alert condition
    fhir:observation [ Reference(Observation) ] ; # 1..1 The Observation having a value causing the alert condition
    fhir:component [ Coding ] ; # 0..1 The Observation.component having a value causing the alert condition
    fhir:limit [ Range ] ; # 0..1 The boundaries beyond which a value was detected to cause the alert condition
  ] ... ) ;
  fhir:label [ string ] ; # 0..1 Text to be displayed for the alert condition
  fhir:signal ( [ # 0..* Annunciation or notification of the alert condition
    fhir:activationState [ CodeableConcept ] ; # 1..1 on | off | paused
    fhir:presence [ CodeableConcept ] ; # 0..1 on | latched | off | ack
    fhir:annunciator [ CodeableReference(Device) ] ; # 0..1 Where the signal is being annunciated
    fhir:manifestation [ CodeableConcept ] ; # 0..1 How the signal is being annunciated
    fhir:type  ( [ CodeableConcept ] ... ) ; # 0..* Characteristics of the signal manifestation
    fhir:indication [ Period ] ; # 0..1 When the signal was being annunciated
  ] ... ) ;
]

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

8.16.3.1 Terminology Bindings

Path ValueSet Type Documentation
DeviceAlert.status DeviceAlertStatusCodes (a valid code from Device Alert Status) Required

DeviceAlert Status Codes
DeviceAlert.category DeviceAlertCategoryCodes (a valid code from Device Alert Category) Example

DeviceAlert Category Codes
DeviceAlert.type DeviceAlertTypeCodes (a valid code from Device Alert Type) Extensible

DeviceAlert Type Codes
DeviceAlert.priority DeviceAlertPriorityCodes (a valid code from Device Alert Priority) Extensible

DeviceAlert Priority Codes
DeviceAlert.code DeviceAlertConditionCodes Preferred

DeviceAlert Condition Codes
DeviceAlert.derivedFrom.component LOINCCodes (a valid code from LOINC icon) Example

This value set includes all LOINC codes
DeviceAlert.signal.activationState DeviceAlertActivationStateCodes (a valid code from Device Alert Activation State) Extensible

DeviceAlert Activation State Codes
DeviceAlert.signal.presence DeviceAlertPresenceCodes (a valid code from Device Alert Presence) Extensible

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
DeviceAlert.signal.type DeviceAlertSignalTypeCodes (a valid code from Device Alert Signal Type) Example

DeviceAlert Signal Type Codes

8.16.4 Search Parameters

Search parameters for this resource. See also the full list of search parameters for 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
acknowledged token Whether the alert condition has been acknowledged DeviceAlert.acknowledged
acknowledged-by reference Who acknowledged the alert DeviceAlert.acknowledgedBy
(Practitioner, Device, Patient, PractitionerRole, RelatedPerson)
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
(Device)
category token Alert category DeviceAlert.category
code token Alert condition code DeviceAlert.code
derived-from reference Whether the alert is currently occurring DeviceAlert.derivedFrom.observation
(Observation)
device reference The device detecting the condition DeviceAlert.device
(Device, DeviceMetric)
encounter reference Encounter during which the alert occurred DeviceAlert.encounter
(Encounter)
identifier token The identifier of the alert DeviceAlert.identifier
indication date When the signal was being annunciated DeviceAlert.signal.indication
location reference Location of the subject at time of alert DeviceAlert.location
(Location)
manifestation token How the alert signal is manifested DeviceAlert.signal.manifestation
occurrence date When the alert condition occurred DeviceAlert.occurrence.ofType(Period) | occurrence.ofType(dateTime)
patient reference The patient subject of the alert DeviceAlert.subject.where(resolve() is Patient)
(Patient)
presence token Whether the alert condition is currently occurring DeviceAlert.presence
priority token Priority of the alert condition DeviceAlert.priority
procedure reference Procedure during which the alert occurred DeviceAlert.procedure
(Procedure)
signal-presence token Whether the alert is currently occurring DeviceAlert.signal.presence
status token Status of the alert DeviceAlert.status
subject reference Subject of the alert DeviceAlert.subject
(Group, Specimen, BiologicallyDerivedProduct, NutritionProduct, Device, Medication, Patient, Location)
type token Whether the alert is physiological or technical DeviceAlert.type