This
page
is
part
of
the
FHIR
Specification
v6.0.0-ballot3:
Release
6
Ballot
(3rd
Draft)
(see
Ballot
Notes
).
The
current
version
is
5.0.0
.
For
a
full
list
Continuous
Integration
Build
of
available
versions,
see
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
core
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
What
about
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
vs.
"observations"?
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
Resources:
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
Metric
,
Observation
allocation,
dispense,
and
return
Description:
The
DeviceMetric
models
Narrative
Maria
works
for
the
properties
outpatient
service
contractor
of
her
town's
hospital.
She
is
doing
administrative
work
to
manage
the
Observations
generated
by
stock
of
home
ventilators,
and
notices
a
device
on
the
device,
whereas
list
with
unknown
status.
She
looks
into
the
Observation
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
recording
not
yet
unassigned
from
the
measurement
taken
by
patient.
After
double-checking
that
the
device.
device
really
is
in
the
storage
room
and
is
operative,
Maria
concludes
that
it
can
now
be
used
for
the
next
outpatient.
Examples
:
TBD
Key
FHIR
resources:
Device,
Patient,
DeviceAssociation,
DeviceDispense
E
-
Personal
Health
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
examples
+
DeviceAssociation
and
/
or
DeviceDispense)
F - Controlling device settings: Change to device's settings via remote control{}
Narrative
F1
(PHD
scenario)
-
Deborah
works
for
R6
Comment
Only
Ballot
#3
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
Tue,
Apr
1,
Fri,
Nov
14,
2025
12:26+1100.
21:00+0000.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change