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.15 Resource Device - Content

Orders and Observations icon Work GroupMaturity Level: 2 Trial UseSecurity Category: Business Compartments: No defined compartments

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.

Note to Implementers: For an overview of this resource and others in the Device domain, also see the module page.

Note to Implementers: The owner has been removed from Device and is now included in DeviceAssociation as .relationship of the subject. Please comment on the revision if there are issues with removing the identification of individuals in the Device resource.

Note to Implementers: The following extensions will be added to a future Extension Pack release to cover removed Device elements including: mode, cycle, duration, gateway and endpoint. In addition, the following new extensions will be added: 1. For device alerts called device-alertDetection, which describes the alert detection activation states for the overall device. 2. For the source of the specification, device-conformsTo-source.

8.15.1 Scope and Usage

This is a base resource that tracks individual instances of a device and their location. It is referenced by other resources for recording which device performed an action such as a procedure or an observation, which device was implanted in or explanted from a patient, dispensing a device to a patient for their use, managing inventory, or when requesting a specific device for a patient's use. Medical devices include durable (reusable) medical equipment, implantable devices, as well as disposable equipment used for diagnostic, treatment, and research for healthcare and public health. Medical devices may also include some types of software.

Non-medical devices may include items such as a machine, cellphone, computer, software application or algorithm, etc. In short, a Device can range from a tongue depressor to an MRI. The fields in the Device resource must be flexible enough to cover this range.

The resource may be used to document the Unique Device Identifier (UDI) and information about a device where appropriate or necessary according to local jurisdictions over time. Additional information about UDI is provided in the Unique Device Identifier (UDI) section.

Devices may be categorized and may be associated with one or more categories. Device category examples include, but are not limited to: active, communicating, durable medical equipment, home use, implantable, InVitro diagnostics, personal health, point-of-care, single use, re-usable, and software. See DeviceDefinition for detailed descriptions of devce categories.

When referring to a specific instance, even without specific instance details, Device is to be used, not a DeviceDefinition. The context of a data exchange indicates whether the data is representing a physical instance or a "kind", not the presence of instance data such as lot and serial numbers.

Some examples:

  1. In a Procedure, reporting the use of a pump for which we have no instance data - the pump is a physical instance. Whether the lot number (for example) is known or not, depends on the circumstance - in another Procedure or in an update of the Procedure, the lot number could be added. Hence the use of Device.
  2. When a device gets replaced by another device of the same type. In this case, a procedure indicates that one instance of the device is removed/explanted/discarded, and another instance is used. These are physical instances for which instance data might exist and be known, or not.

8.15.1.1 Boundaries and Relationships

Note to Implementers: The module pages under development by Orders and Observations will further describe the variations of device use cases across the device resources, e.g., Device, DeviceDefinition, DeviceAssociation, DeviceDispense, DeviceMetric, DeviceRequest, and Device Usage.

There are several resources that can be used to represent device related events, requests or definitions. The following Resources should be used in the following manner:

  • Device (this resource)
  • DeviceDefinition - Describes a "kind" of device - not a specific instance of the device. A kind of device is frequently defined and documented by the manufacturer, reseller, or regulatory. Documentation would include any information that applies to all instances of a device, and may be published through a catalog. For example, the characteristics of a test analyzer, x-ray machine, or wheelchair.
  • DeviceMetric - Describes a measurement, calculation or setting capability of a device instance. A Device may include multiple device metrics, each yielding a different observation. The DeviceMetric models the properties of the Observations generated by and/or about the device such as whether or not the Observation is a setting. A DeviceMetric describes aspects of the device that may change over time. In contrast, the Device.property is used to capture inherent, essentially fixed, characteristics of the device, such as a "large" blood pressure cuff, the bore size of an MRI, the color of a lead. (Such static characteristics may also be recorded in DeviceDefinition.). The DeviceMetric models the properties of the Observations generated by the device, such as whether or not the Observation is a setting.
  • DeviceAssociation - Records the association of a device with a subject and/or operator (e.g. a Patient by ownership, or a Practitioner by usage during a procedure). DeviceAssociation should be used for ownenship/custiodianship.
  • 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.
  • DeviceRequest/ - The workflow step to request/order the use of a device in a specific context.
  • DeviceDispense - The workflow step to manage the distribution of the device.
  • SupplyRequest - The workflow step to request/order supplies that would be needed beyond the devices in the DeviceRequest.
  • SupplyDelivery - The workflow step to manage the distribution of supplies that are ordered beyone the devices in the DeviceDispense.
  • DeviceUsage - To record the use of a device that is not covered by a procedure - i.e., patient reported use of a device.
  • NutritionOrder - An order for nutrition can request to a specific device to administer enteral feeding.
  • Observation - A measurement can be generated by many types of devices. It may be linked to and supplemented by data about the current structure and status of the device itself in one or more Device or DeviceMetric resources.
  • Procedure - A procedure can be performed using a variety of devices, or a device can be implanted or otherwise associated with a patient.
  • MedicationAdministration - A medication administration can be performed using a variety of devices.

In FHIR, the Device represents either the device in total, or a component of an encapsulating device when there is a need for individual tracking of a component. A Device as a component then points to the parent device it is part of. The top-level Device captures the actual data about the instance of the device and the instances of all its children that either provides identifying characteristics of the Device (including applicable UDI – unique device identification) and data that can vary dynamically by device, e.g., specific settings at a particular point in time.

Devices differ from medications because they are not "used up" - they remain active in or for a patient for a longer duration. They also may be re-used, particularly non-implanted devices and those used for diagnostics and procedures. Frequently, when a device is packaged with a medication, the ordering, dispense, and administration processes typically focus on the medication aspects and reference the device.

In the case of an infusion pump, while some actions are focused on the device (e.g., ordering to a room or maintaining the pump), the focus is as well on the medication while the device is used for administration. However, that separation is not always as clear and may be impacted by specific implementations. Regardless, the Medication resource should not be used to represent (implanted) devices, rather reference the relationship where an actual device needs to be tracked in addition to the medication. In some sense the Medication is analogous to the Observation generated by a Blood Pressure personal health device. The Observation resource contains the blood pressure values, units and the time stamp while the Device resource contains the manufacturer name, model number, serial number, firmware and hardware versions, exchange protocol information, any clock capabilities, etc.

8.15.2 References to this Resource

8.15.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device TU DomainResource Item used in healthcare
+ Rule: only one Device.name.display SHALL be true when there is more than one Device.name

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier 0..* Identifier Instance identifier

... definition 0..1 Reference(DeviceDefinition) The reference to the definition for the device
... udiCarrier Σ 0..* BackboneElement Unique Device Identifier (UDI) value

.... deviceIdentifier Σ 1..1 string Mandatory fixed portion of UDI
.... deviceIdentifierSystem 0..1 uri The namespace for the device identifier value
.... issuer Σ 1..1 uri UDI Issuing Organization
.... jurisdiction 0..1 uri Regional UDI authority
.... carrierAIDC Σ 0..1 base64Binary UDI Machine Readable value
.... carrierHRF Σ 0..1 string UDI Human Readable Barcode String
.... entryType 0..1 code barcode | rfid | manual | card | self-reported | electronic-transmission | unknown
Binding: UDI Entry Type (Required)
... availabilityStatus 0..1 CodeableConcept lost | damaged | destroyed | available
Binding: FHIR Device Availability Status (Extensible)
... biologicalSourceEvent 0..1 Identifier A production identifier of the donation, collection, or pooling event from which biological material in this device was derived
... manufacturer 0..1 string Name of device manufacturer
... manufactureDate 0..1 dateTime Date when the device was made
... expirationDate 0..1 dateTime Date and time of expiry of this device (if applicable)
... lotNumber 0..1 string Lot number of manufacture
... serialNumber 0..1 string Serial number assigned by the manufacturer
... name C 0..* BackboneElement The name or names of the device as known to the manufacturer and/or patient

.... value Σ 1..1 string The term that names the device
.... type Σ 1..1 CodeableConcept registered-name | user-friendly-name | patient-reported-name
Binding: Device Name Type (Extensible)
.... display ?!ΣC 0..1 boolean The preferred device name
... modelNumber 0..1 string The manufacturer's model number for the device
... partNumber 0..1 string The part number or catalog number of the device
... category 0..* CodeableConcept Indicates a high-level grouping of the device
Binding: FHIR Device Category (Example)

... type 0..* CodeableConcept The kind or type of device
Binding: Device Type (Example)

... deviceVersion 0..* BackboneElement The actual design of the device or software version running on the device

.... type 0..1 CodeableConcept The type of the device version, e.g. manufacturer, approved, internal
Binding: Device Version Type (Example)
.... component 0..1 Identifier The hardware or software module of the device to which the version applies
.... installDate 0..1 dateTime The date the version was installed on the device
.... value 1..1 string The version text
... conformsTo 0..* BackboneElement Identifies the standards, specifications, or formal guidances for the capabilities supported by the device

.... category 0..1 CodeableConcept Describes the common type of the standard, specification, or formal guidance. communication | performance | measurement
Binding: Device Specification Category (Example)
.... specification 1..1 CodeableConcept Identifies the standard, specification, or formal guidance that the device adheres to
Binding: Device Specification Type (Example)
.... version 0..1 string Specific form or variant of the standard
... property 0..* BackboneElement Inherent, essentially fixed, characteristics of the device. e.g., time properties, size, material, etc.

.... type 1..1 CodeableConcept Code that specifies the property being represented
Binding: Device Property Type (Example)
.... value[x] 1..1 Value of the property
..... valueQuantity Quantity
..... valueCodeableConcept CodeableConcept
..... valueString string
..... valueBoolean boolean
..... valueInteger integer
..... valueRange Range
..... valueAttachment Attachment
... additive 0..* BackboneElement Material added to a container device

.... type 1..1 CodeableReference(Substance) The additive substance
Binding: Substance Code (Example)
.... quantity 0..1 SimpleQuantity Quantity of additive substance within container
.... performer 0..1 Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson) Entity adding substance to the container
.... performed 0..1 dateTime When the additive substance was added to the container
... contact 0..* ContactPoint Details for human/organization for support

... location 0..1 Reference(Location) Where the device is found
... note 0..* Annotation Device notes and comments

... safety Σ 0..* CodeableConcept Safety Characteristics of Device
Binding: Device Safety (Example)

... parent 0..1 Reference(Device) The higher level or encompassing device that this device is a logical part of

doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

8.15.3.1 Terminology Bindings

Path ValueSet Type Documentation
Device.udiCarrier.entryType UDIEntryType Required

Codes to identify how UDI data was entered.
Device.status FHIRDeviceStatus Required

The status of the Device record.
Device.availabilityStatus FHIRDeviceAvailabilityStatus Extensible

The availability status of the device.
Device.name.type DeviceNameType Extensible

The type of name the device is referred by.
Device.category FHIRDeviceCategory Example

The association state of the device.
Device.type DeviceType Example

Codes used to identify medical devices. Includes concepts from SNOMED CT (http://www.snomed.org/) where concept is-a 49062001 (Device) and is provided as a suggestive example.
Device.deviceVersion.type DeviceVersionType Example

Describes the type of version
Device.conformsTo.category DeviceSpecificationCategory (a valid code from FHIR Device Specialization Category) Example

The kind of standards used by the device.
Device.conformsTo.specification DeviceSpecificationType Example

The type or specification of a standard that devices can adhere to
Device.property.type DeviceType Example

Codes used to identify medical devices. Includes concepts from SNOMED CT (http://www.snomed.org/) where concept is-a 49062001 (Device) and is provided as a suggestive example.
Device.additive.type SubstanceCode Example

This value set contains concept codes for specific substances. It includes codes from SNOMED icon where concept is-a 105590001 (Substance (substance))
Device.safety DeviceSafety Example

Codes used to identify medical devices safety characteristics. These codes are taken from the NCI Thesaurus icon and are provided here as a suggestive example.

8.15.3.2 Constraints

UniqueKeyLevelLocationDescriptionExpression
img dev-1Rule (base)only one Device.name.display SHALL be true when there is more than one Device.namename.where(display=true).count() <= 1

8.15.3.3 Notes

8.15.3.3.1 Device Identifier and Device Type

Nearly all devices are assigned a string of characters to represent one or more identifiers or codes, which are usually printed or affixed to the device using either barcodes or RFIDs. The identifier or code can come from the manufacturer (for example, a 'serial number', 'reference number', or 'catalog number'), various institution and registries. Any of these identifiers or codes assigned to the device can and should be recorded in the device resource. However, there can there can be confusion where to represent them in the resource because codes and identifiers are represented in FHIR as semantically distinct elements and because organizations may conflate the term 'code' for an identifier or 'identifier' for a code in their names.

The identifier element is only intended for use when it's an actual identifier for a specific instance of a device. That would mean that each device would have a separate serial number and would be represented using this element - devices without serial numbers (for example, a box of syringes) would not. Concepts such as a reference number or catalog number or GTIN describe a code which represents a kind of device and are conveyed using the type element. Some sources of standard codes for devices and translations within type are listed below:

For systems that do have a system URI for device types (indicating the model number or part number), they can and should appear as codings in Device.type.

Device.type relates DeviceDefinition.classification.type using the same binding enabling referencing. Please see the Search Parameters for details on how to search for devices by type.

8.15.3.3.2 Unique Device Identifier (UDI)

The International Medical Device Regulators Forum IMDRF UDI Working Group published UDI System for Medical Devices (Version 2.0) icon, the base specification for Unique Device Identifiers (UDI). The United States Food and Drug Administration has produced an implementation guide icon for Unique Device Identifiers (UDI) which implements the IMDRF specification and other jurisdictions may produce similar IMDRF implementation guides as well. The full UDI string that represents the barcode as printed on the packaging of the device or Automatic Identification and Data Capture (AIDC) representation is called the "UDI carrier". The UDI has 2 components*:

  • Device identifier (DI)**, which is the actual identification component
  • Production identifier(s)(PI) which provide the means to track a device through its manufacture, distribution and use.

*non-UDI elements may also appear within the UDI carrier. **a "GTIN" (sometimes also called an EAN number) is a code developed by GS1 icon for the kind of device not an identifier for the device. A GTIN may appear on its own or it may appear in a UDI string as the DI component.

The DI of the UDI may be stored in a jurisdictional repository and used as the primary key to access other device information. For example, in the United States, the DI of the UDI is submitted in a device record to the Global Unique Device Identification Database (GUDID) icon. The UDI may identify an instance of a device uniquely (when the PI includes a serial number), or it may just identify the type of the device. The UDI is parsed into its constituent parts (DI, PI and other elements) by parsing rules developed by each Issuing Agency standard. Where the device has an assigned UDI, the other details carried in the resource (e.g., lot, expiration date, etc.) SHALL be consistent with the information encoded in the UDI string or registered in the local repository.

Best practice guidelines for transmitting UDI data using the Device resource dictate transmitting both the UDI Carrier and all components found within the UDI as described in Device UDI Mapping. Several examples are provided for further guidance.

8.15.3.3.3 Status Elements

Device.status is about the record, while .availabilityStatus is about the device itself.

8.15.4 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to 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
biological-source-event token The biological source for the device Device.biologicalSourceEvent
code token The definition / type of the device (code) Device.type | Device.definition.resolve().classification.type
code-value-concept composite Code and value parameter pair On Device:
  specification: specification.ofType(CodeableConcept)
  version: version.ofType(string)
definition reference The definition / type of the device Device.definition
(DeviceDefinition)
device-name string A server defined search that may match any of the string fields in Device.name or Device.type. Device.name.value | Device.type.coding.display | Device.type.text
expiration-date date The expiration date of the device Device.expirationDate
identifier token Instance id from manufacturer, owner, and others Device.identifier
location reference A location, where the resource is found Device.location
(Location)
lot-number string The lot number of the device Device.lotNumber
manufacture-date date The manufacture date of the device Device.manufactureDate
manufacturer string The manufacturer of the device Device.manufacturer
model string The model of the device Device.modelNumber
parent reference The parent device Device.parent
(Device)
serial-number string The serial number of the device Device.serialNumber | Device.identifier.where(type='SNO')
specification token The standards, specifications, or formal guidances. Device.conformsTo.specification
specification-version composite A composite of both specification and version On Device.conformsTo:
  specification: specification
  version: version
status token active | inactive | entered-in-error | unknown Device.status
type token The type of the device Device.type | Device.definition.resolve().classification.type
udi-carrier-hrf string

UDI Barcode (RFID or other technology) string in HRF format.

 Device.udiCarrier.carrierHRF
udi-di string The udi Device Identifier (DI) Device.udiCarrier.deviceIdentifier
version string The specific version of the device Device.deviceVersion.value
version-type composite Value and type of version On Device.deviceVersion:
  type: type
  value: value