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.

Allows institutions to track their devices.

Unique instance identifiers assigned to a device by manufacturers other organizations or owners.

Certain attributes, like serial number and UDI Carrier (the HRF or AIDC barcode string) are not device instance identifiers as they are not consistently able to uniquely identify the instance of a device, thus are not appropriate to be used to value Device.identifier. The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used. The identifier is typically valued if the serialNumber or lotNumber is not valued and represents a different type of identifier. However, it is permissible to still include those identifiers in DeviceDefinition.identifier with the appropriate identifier.type.

The name used to display by default when the device is referenced. Based on intent of use by the resource creator, this may reflect one of the names in Device.deviceName, or may be another simple name.

The reference to the definition for the device.

Unique device identifier (UDI) assigned to device label or package. Note that the Device may include multiple udiCarriers as it either may include just the udiCarrier for the jurisdiction it is sold, or for multiple jurisdictions it could have been sold.

UDI may identify an unique instance of a device, or it may only identify the type of the device. See UDI mappings for a complete mapping of UDI parts to Device.

The device identifier (DI) is a mandatory, fixed portion of a UDI that identifies the labeler and the specific version or model of a device.

Organization that is charged with issuing UDIs for devices. For example, the US FDA issuers include:

1. GS1: http://hl7.org/fhir/NamingSystem/gs1-di,
2. HIBCC: http://hl7.org/fhir/NamingSystem/hibcc-diI,
3. ICCBBA for blood containers: http://hl7.org/fhir/NamingSystem/iccbba-blood-di,
4. ICCBA for other devices: http://hl7.org/fhir/NamingSystem/iccbba-other-di # Informationsstelle für Arzneispezialitäten (IFA GmbH) (EU only): http://hl7.org/fhir/NamingSystem/ifa-gmbh-di.

The identity of the authoritative source for UDI generation within a jurisdiction. All UDIs are globally unique within a single namespace with the appropriate repository uri as the system. For example, UDIs of devices managed in the U.S. by the FDA, the value is http://hl7.org/fhir/NamingSystem/us-fda-udi or in the European Union by the European Commission http://hl7.org/fhir/NamingSystem/eu-ec-udi.

Allows a recipient of a UDI to know which database will contain the UDI-associated metadata.

The full UDI carrier of the Automatic Identification and Data Capture (AIDC) technology representation of the barcode string as printed on the packaging of the device - e.g., a barcode or RFID. Because of limitations on character sets in XML and the need to round-trip JSON data through XML, AIDC Formats SHALL be base64 encoded.

The AIDC form of UDIs should be scanned or otherwise used for the identification of the device whenever possible to minimize errors in records resulting from manual transcriptions. If separate barcodes for DI and PI are present, concatenate the string with DI first and in order of human readable expression on label.

The full UDI carrier as the human readable form (HRF) representation of the barcode string as printed on the packaging of the device.

If separate barcodes for DI and PI are present, concatenate the string with DI first and in order of human readable expression on label.

A coded entry to indicate how the data was entered.

Supports a way to distinguish hand entered from machine read data.

The Device record status. This is not the status of the device like availability.

This element is labeled as a modifier because the status contains the codes inactive and entered-in-error that mark the device (record)as not currently valid.

The availability of the device.

An identifier that supports traceability to the event during which material in this product from one or more biological entities was obtained or pooled.

Necessary to support mandatory requirements for traceability from donor/source to recipient and vice versa, while also satisfying donor anonymity requirements. The element is defined consistently across BiologicallyDerivedProduct, NutritionProduct, and Device. The identifier references an event that links to a single biological entity such as a blood donor, or to multiple biological entities (e.g. when the product is an embryo or a pooled platelet product). A single biologicalSourceEvent identifier may appear on multiple products of many types derived from a single donation event or source extraction. As an example, a single donation event may provide 2 kidneys and a liver for organ transplantation, 2 corneas for eye surgery, heart valves and arterial tissue for cardiovascular surgery, multiple skin grafts, tendons, multiple shaped bone grafts and a large number of bone putty/paste products; and each of them may be assigned to the same biological source event identifier.

A name of the manufacturer or entity legally responsible for the device.

The date and time when the device was manufactured.

The date and time beyond which this device is no longer valid or should not be used (if applicable).

Lot number assigned by the manufacturer.

The serial number assigned by the organization when the device was manufactured.

Alphanumeric Maximum 20. While a serial number is a type of identifier, in the context of devices for which a UDI is required, thus a serial number may be part of the production identifier, it is more informative to have the serial number as a dedicated attribute together with the other UDI production identifier. When the device is not subject to including the UDI (e.g., its presence and exchange is not mandated by local regulatory requirements or specific use case at hand), thus the concept of production identifiers is not relevant as a set, it remains helpful for consistency to still use Device.serialNumber rather than using Device.identifier with an appropriate type. Systems that do not realize an identifier is a serial number may place it in Device.identifier or if the identifier.system is known for the serial number, it may also be populated in the Device.identifier as a globally unique id_.

This represents the manufacturer's name of the device as provided by the device, from a UDI label, or by a person describing the Device. This typically would be used when a person provides the name(s) or when the device represents one of the names available from DeviceDefinition.

The name that identifies the device.

The type of deviceName. Note that ManufactureDeviceName means that the name is the name as given by the manufacturer, not the name of the manufacturer. RegisteredName | UserFriendlyName | PatientReportedName.

The manufacturer's model number for the device.

The part number or catalog number of the device.

Alphanumeric Maximum 20.

Devices may be associated with one or more categories.

The kind or type of device. A device instance may have more than one type - in which case those are the types that apply to the specific instance of the device.

Multiple device types are use when a device is categorized in more than one context – for example, hybrid devices in which the device is both of type gateway and sensor.

The actual design of the device or software version running on the device.

The type of the device version, e.g. manufacturer, approved, internal.

The hardware or software module of the device to which the version applies.

Note that the module of the device would not need to be tracked as a separate device, e.g., using different UDI, thus would typically involve one or more software modules. For example, a device may involve two software modules each on a different version.

The date the version was installed on the device.

The version text.

The standards to which the device adheres and may be certified to in support of its capabilities, e.g., communication, performance, process, or measurement standards.

Code that specifies the system that identifies the specific standard that the device adheres to.

The version of the standard that is used to operate and communicate.

Kind of standards that the device adheres to, e.g., communication, performance or communication.

Characteristics or features of the device that are otherwise not captured in available attributes, e.g., actual configuration settings, time or timing attributes, resolution, accuracy, and physical attributes. The focus is on properties of the device actually in use while DeviceDefinition focuses on properties that are available to be used.

Code that specifies the property being represented. No codes are specified but the MDC codes are an example: https://terminology.hl7.org/MDC.html.

Property value - can be a code, quantity, boolean, string or attachment.

The string is used for properties that are intrinsically text, such as warning text, or assemlby instructions. CodeableConcept.text also supports unencoded text but should be used where the characteristic is a concept that might be coded but there is no assigned code for the present value. For example, a security class can be a code like 'Class 1' but in some cases may contain a string like 'Depending on the settings' - in this case the property is normally coded but this is an exception

The status of the device itself - whether it is switched on, or activated, etc.

The state or condition of the device's operation.

The reasons given for the current operational status - i.e. why is the device switched on etc.

The individual performing the action enabled by the device.

The designated condition for performing a task with the device.

The series of occurrences that repeats during the operation of the device.

A measurement of time during the device's operation (e.g., days, hours, mins, etc).

The details about the device when it is affixed or inside of a patient.

The state of the usage or application of the device.

The reasons given for the current association status - i.e. why is the device explanted, or attached to the patient, etc.

The individual to whom the device is affixed or inserted in their body.

The current anatomical location of the device in/on the humanSubject where it is attached or placed.

An organization that is responsible for the provision and ongoing maintenance of the device.

Contact details for an organization or a particular human that is responsible for the device.

used for troubleshooting etc.

The place where the device can be found.

Device.location can be used to track device location.

A network address on which the device may be contacted directly.

If the device is running a FHIR server, the network address should be the Base URL from which a conformance statement may be retrieved.

Technical endpoints providing access to services provided by the device defined at this resource.

The linked device acting as a communication/data collector, translator or controller for the current device (e.g., mobile phone application that relays a blood pressure device's data).

Descriptive information, usage information or implantation information that is not captured in an existing element.

Provides additional safety characteristics about a medical device. For example devices containing latex.

The higher level or encompassing device that this device is a logical part of.

For example a vital signs monitor (parent) where three separate modules can be plugged into such as interchangeable blood pressure, oximeter, temperature modules. These modules are represented as devices with the .parent valued to the vital signs monitor when plugged in.