FHIR CI-Build
This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions 
| Responsible Owner: Work Group Orders and Observations | Standards Status: Informative |
Note to Implementers: This module page describes the context and usage of the Devices and related resources. HL7 seeks specific feedback on the usefulness of this module page and the implementability of the referenced resources.
The future location and navigation links to this module are outstanding items to be revisited in a future FHIR version.
This module is concerned with "devices" and how to use the various device-related FHIR resources to address common use cases. Within FHIR a "device" can represent a wide range of equipment including such diverse things as MRIs, beds, tongue depressors, bandages, stents and implants, blood pressure monitors, weight scales, infusions pumps, clinical decision support software, continuous glucose monitor, and bed-side monitors. Because of the range of possible devices and the range of uses, systems may choose to implement a subset of device-related resources.
Device-related resources include:
When considering the use of FHIR for the integration of device information and services, many resources may be involved in even the simplest application. Additionally, given the robust nature of FHIR resources, a single basic capability will have many potential solutions all using valid FHIR resource configurations. The following diagram captures some of the key device-related FHIR resources and representative relationships. It is recommended that readers review the respective resources for all valid relationships.
Looking in to the details of each of the resources on this diagram, though, will reveal a significant amount of detail that can often lead to confusion as to the high-level purposes they are intended to address. Only the most comprehensive applications will require integration of all the model components. Most will require only a subset. To sort this out, the following examples are provided to help understand the key concepts and rationale for their implementation.
Device Instance vs. Device Type
Resources:Device, Device Definition
When working with a specific INSTANCE of a device (that can be uniquely identified for example: Company Z Super Ventilator, model SV, serial #123xyz456), a Device resource is used. A Device may reference a single DeviceDefinition when additional definitional information about the device is necessary to exchange.
A - Tracking device usage: Patients using the Device during a period of time
Nurse Lisa notices that a blood pressure device is defective and produces incorrect measurement values. The blood pressure device has probably been used to make spot measurements on several patients in the ward. After discussing this with her colleagues, the biomed team gets involved to find out on which patients the defective device has been used since the device's last technical inspection. Then, the measurements on those patients by that device are labelled as suspicious or erroneous in the patients' records.
Key FHIR resources: DeviceAssociation and / or DeviceUsage, Device, Patient
B - Tracking device settings: Device's Settings during Measurement
Narrative
Patient Josh lies in the ICU sedated and ventilated. While reviewing his case, doctor Sarah notices that Josh's respiration rate was too low for a few minutes of the last shift. Sarah decides to review the ventilator's data to investigate if the ventilator settings were the cause of the unexpected respiration rate readings. She looks for the device settings effective in the period of time starting one hour before and ending one hour after the awkward readings. Based on that information she discovers that someone changed the ventilation mode and then reverted the change a few minutes later.
Key FHIR resources: Observation, DeviceMetric, Device
C - Tracking alarm settings during a device alarm: Hear Rate thresholds that trigger an alarm
Narrative
Helen is recovering from a heart failure in the cardiology ward. She wears a portable telemetry monitor 24/7 that continuously measures her EKG. During the night shift, nurse Frank sees a tachycardia alarm coming from Helen's monitor. Helen's heart rate is 97 bpm, which Frank does not generally regard as concerning. Yet, he checks on Helen to make sure she is doing well. After that, Frank consults which were the tachycardia alarm limits when the alarm came up. He finds out that the limit was set to 90 bpm - way below the usual 120-140 bpm limit.
Key FHIR resources: DeviceAlert, Patient, Device
D - Tracking device management: Device allocation, dispense, and return
Narrative
Maria works for the outpatient service contractor of her town's hospital. She is doing administrative work to manage the stock of home ventilators, and notices a device on the list with unknown status. She looks into the historical data to learn more about the device's real status. Searching in the data base, Maria sees that the ventilator was assigned and dispensed to a patient last year and returned two weeks ago. However, for some reason, the device is not yet unassigned from the patient. After double-checking that the device really is in the storage room and is operative, Maria concludes that it can now be used for the next outpatient.
Key FHIR resources: Device, Patient, DeviceAssociation, DeviceDispense
E - Controlling device management: Continuous monitoring of Patient for Basic Vitals for 72 hours
Narrative
Lizzy is the doctor in charge in the general ward. She has an elderly patient with pulmonary edema who recently suffered a related acute cardiorespiratory event. Given the deterioration risk, Lizzy wants her patient to be continuously monitored by a bedside monitor. She submits an order through the EHR for the patient to receive continuous monitoring of EKG and SPO2 and periodic monitoring of blood pressure for the next 72 hours.
Key FHIR Resources: Patient, ServiceRequest (and optionally: DeviceRequest + DeviceDefinition or Device + DeviceAssociation and / or DeviceDispense)
F - Controlling device settings: Change to device's settings via remote control{}
Narrative
F1 (PHD scenario) - Deborah works for an outpatient cardiac monitoring service. Her managed patients continuously wear Holter monitors and take daily weight and blood pressure measurements. Due to some recent incidents of fast deterioration, Deborah's employer has decided to have weight scale and blood pressure devices report their recorded measurements more frequently than just three times a week. Hence, Deborah configures all of those devices types out on the field to report any stored readings daily.
F2 (PoCD scenario) - Rob works at a central monitoring unit and is remotely watching over dozens of patients across two hospital wards. He notices that post-surgery patient Jingze has all vitals within normal range but seems restless in the video feed. Since Jingze's sedation medication dosage has been low in the last 12 hours, Rob remotely configures the benzodiazepine infusion pump to administer Jingze a bolus.
Key FHIR Resources: Device, ServiceRequest (and optionally: DeviceMetric + Observation)
The following are the core device-related resources:
| Name | Description/Relationship |
|---|---|
| Device |
A type of a manufactured item that is used in the provision of healthcare without being substantially changed through that activity. The device may be a medical or non-medical device, and might or might not be capable of communicating. A device may be a physical object or virtual, such as software. An instrument, apparatus, implement, machine, appliance, implant, reagent for in vitro use, software, material or other similar or related article, intended by the manufacturer (3.33) to be used, alone or in combination, for human beings, for one of more of the specific medical purpose(s) of .... |
| Device Alert | |
| Device Association |
|
| Device Definition | The DeviceDefinition provides a description of all instances of a particular model of device.Description/Relationship. |
|
Device Dispense
|
|
| Device Metric | |
| Device Request | |
|
Device Usage
|
|
The following are the secondary resources that are used in many device related activities:
| Name | Module(s) | Description/Relationship |
|---|---|---|
| Patient | Administration | |
| Location | Administration | |
| Service Request | Clinical, Workflow | |
| Procedure | Clinical |
|
| Observation | Diagnostics | |
| Endpoint | Administration | |
| Bundle | Foundation |
The Device-related resources typically represent patient-specific data, and as such are susceptible to data breaching. Necessary privacy and security provisions must be in place when searching and fetching this information. For more general considerations, see the the Security and Privacy module.
Device data must be treated securely across all three aspects that include confidentiality, integrity, and availability. Furthermore, proper confidentiality, integrity and availability protections must be applied across the entire ecosystem that delivers the data from the device to personal health or point of care services. Device data privacy must also be considered to ensure that patient identifiable data is not compromised and made public. The ecosystem delivering the device data must not publicly associate device data with the patient or user to which that data belongs. In addition, access to device data must be restricted to those who need to know in clinical and consumer settings and to those who are allowed access by the user or patient.
It is highly recommended that a proper methodology is used to assess the security vulnerabilities and associated threats of any such architecture and to apply proper mitigation techniques based on the risks exposed by such threats. To that end, it is recommended that security methods are constructed based on the IEEE 11073-40101 and IEEE 11073-40102 standards that provide the framework for device cybersecurity vulnerability analysis and risk mitigation. Such analysis will enable application of transport-specific mitigation techniques such as the Bluetooth Authorization Control Service and Profile specifications.
| Name | Matutity Level | Known changes | |
|---|---|---|---|
| Device | The Device resource has undergone substantial change since R5, to include removing core elements. The Device.owner has been moved to DeviceAssociation.relationship to indicate the .subject of the association is an owner. The following core elements: mode, cycle, duration, gateway and endpoint have been moved to extensions (note: the extensions will not be available in R6 Comment Only #3 ballot). | ||
| Device Alert | |||
| Device Association | |||
| Device Definition | |||
|
Device Dispense
|
|||
| Device Metric | |||
| Device Request | |||
|
Device usage
|
O&O welcomes feedback to show if the resource designs have made a solution that works, and is implementable, for users across a range of domains.
FHIR ®© HL7.org 2011+. FHIR R6 hl7.fhir.core#6.0.0-ballot3 generated on Sun, Nov 9, 2025 02:09+0000.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R4 |
Compare to R5 |
Compare to Last Ballot |
|
Propose a change