FHIR CI-Build

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

Work Group Orders and Observations icon Standards Status: Informative

18 Device Module

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.

18.1 Introduction

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:

  • Resources providing the definition and documenting the capabilities of the device include: Device, DeviceDefinition, DeviceMetric
  • Resources documenting the supply or clinical workflow (e.g., order, fulfillment, and use) of devices include: DeviceAssociation, DeviceRequest, DeviceDispense, DeviceUsage
  • Resources related to the actual clinical use and/or behavior of the device include: Observation, DeviceAlert, Procedure.

18.2 Index

18.2.1 Device-related FHIR Resources: The Big picture

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 the core device-related FHIR resources and representative relationships.

Image showing the Device-related FHIR Resources: The Big picture

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.

What about device settings vs. "observations"?

Resources:Device, Device Metric, Observation

Examples: Distinguish cases with and (as in PHD) DeviceMetric available and used

Under development for R6 Comment Only Ballot #3

18.3 Device-related Resources

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
  • record of association or dissociation of the device with patient or other device, or a practitioner, group, location;
  • This is a more precise record of association with a patient
Device Definition The DeviceDefinition provides a description of all instances of a particular model of device.Description/Relationship.
Device Dispense
  • Record of allocation of the device to a patient
Device Metric
Device Request
Device Usage
  • Record of use by patient, whereas DeviceAssociation is more record of association or dissociation of the device with patient;
  • DeviceUsage has details about how it was used; DeviceAssociation doesn't

18.4 Related Resources

The following are the secondary resources that are used in many device related activities:

Name Module(s) Description/Relationship
Patient Administration
Service Request Clinical, Workflow
Procedure Clinical
  • The actual procedure in which the device is used, consumed, implanted or explanted. The device may be the focus of the procedure or just used in the procedure.
  • Procedure is intended to capture the details of the procedure
Observation Diagnostics
Location Administration
Endpoint Administration
Bundle Foundation

18.5 Security and Privacy

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 Security and Privacy module.

18.6 Developmental Roadmap

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

Name Matutity Level Known changes
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.