8.16 Resource DeviceAlert - Content

8.16.1 Scope and Usage

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:

• Physiological (e.g., Patient Lucy has a low SpO2)
• Technical (e.g., Infusion Pump #2 has a fluid line occlusion).

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:

• 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 (primary recommended alerting code system)
• 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)

8.16.1.1 Usage Scenarios

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

• A vital Signs Monitor detects a low heart rate condition and signals a high priority alarm that gets communicated to a FHIR-enabled system for information documentation purposes.
• 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:

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

8.16.1.2 Boundaries and Relationships

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

8.16.1.2.2 Resource Boundaries:

• Flag:

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:

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.

• 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 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:

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

• Subscription:

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:

• Devices can potentially detect and signal several hundreds of different alert conditions (plus there could be hundreds of devices in a care setting and each device could have subordinate devices / DeviceMetrics).
• Typically, those conditions have a much broader spectrum than what an EMR record captures.
• Additionally, those conditions may trigger on device alarm limits that change over time (e.g., tachycardia when heart rate measurement >150 bpm), or not trigger on alarm limits at all (e.g., lead off detected).

Moreover, alerting documentation and logging are key use cases for DeviceAlert that do not fit well with the run-time nature of subscriptions.

• AuditEvent:

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.

8.16.1.3 Background and Context

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.

• Structure
• UML
• XML
• JSON
• Turtle
• R4 Diff
• All

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

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

{
  "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
  }]
}

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


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

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Instance identifier
  fhir:status [ code ] ; # 1..1 in-progress | completed | entered-in-error
  fhir:condition [ # 1..1 The condition, event, or state being reported
    fhir:code [ CodeableConcept ] ; # 1..1 The meaning of the alert
    fhir:presence [ boolean ] ; # 1..1 The alert condition is currently occuring
    fhir:timing [ Period ] ; # 0..1 The period during which the condition was active
    fhir:limit [ Range ] ; # 0..1 The boundaries outside of which a value was detected to cause the alert condition
  ] ;
  fhir:priority [ code ] ; # 0..1 high | medium | low | info
  fhir:type [ code ] ; # 0..1 physiological | technical
  fhir:subject [ Reference(Device|Patient) ] ; # 1..1 The who or what the alert is about
  fhir:source [ Reference(Device|DeviceMetric) ] ; # 0..1 The device (or DeviceMetric) that detected the alert condition
  fhir:derivedFrom  ( [ Reference(Observation) ] ... ) ; # 0..* The value causing 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 [ code ] ; # 1..1 on | off | paused
    fhir:presence [ code ] ; # 0..1 on | latched | off | ack
    fhir:annunciator [ CodeableReference(Device) ] ; # 0..1 Where the signal is being annunciated
    fhir:manifestation  ( [ CodeableConcept ] ... ) ; # 0..* 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 annuciated
  ] ... ) ;
]

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


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

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Instance identifier
  fhir:status [ code ] ; # 1..1 in-progress | completed | entered-in-error
  fhir:condition [ # 1..1 The condition, event, or state being reported
    fhir:code [ CodeableConcept ] ; # 1..1 The meaning of the alert
    fhir:presence [ boolean ] ; # 1..1 The alert condition is currently occuring
    fhir:timing [ Period ] ; # 0..1 The period during which the condition was active
    fhir:limit [ Range ] ; # 0..1 The boundaries outside of which a value was detected to cause the alert condition
  ] ;
  fhir:priority [ code ] ; # 0..1 high | medium | low | info
  fhir:type [ code ] ; # 0..1 physiological | technical
  fhir:subject [ Reference(Device|Patient) ] ; # 1..1 The who or what the alert is about
  fhir:source [ Reference(Device|DeviceMetric) ] ; # 0..1 The device (or DeviceMetric) that detected the alert condition
  fhir:derivedFrom  ( [ Reference(Observation) ] ... ) ; # 0..* The value causing 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 [ code ] ; # 1..1 on | off | paused
    fhir:presence [ code ] ; # 0..1 on | latched | off | ack
    fhir:annunciator [ CodeableReference(Device) ] ; # 0..1 Where the signal is being annunciated
    fhir:manifestation  ( [ CodeableConcept ] ... ) ; # 0..* 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 annuciated
  ] ... ) ;
]

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.