Unique identifier(s) for a patient's implantable device(s).

Data Element

Applicable Vocabulary Standard(s)

Unique Device Identifier(s) for a patient’s implantable device(s)

  • FDA Unique Device Identification System (UDI System)

Data Element

Applicable Vocabulary Standard(s)

Unique Device Identifier(s) for a patient’s implantable device(s)

Unique numeric or alphanumeric codes that consist of a device identifier and a production identifier.

  • FDA Unique Device Identification System (UDI System)

Comment

Expand UDI to Life-Supporting/Life-Sustaining Devices

Currently in version 3 of the USCDI (and since version 1), unique device identifiers are only required for a patient's implantable medical devices.  However, devices categorized as "life supporting or life sustaining" are likely to be more critical to patient health than many implantable devices. These devices are not elective and many times there are no other medical interventions available to the patient.  According to 21 CFR 860.3, a life-supporting or life-sustaining device means a device that is essential to, or that yields information that is essential to, the restoration or continuation of a bodily function important to the continuation of human life.  Examples include ventilators, dialysis machines, cardiopulmonary bypass machines, and defibrillators.  These devices are identified by product code and they make up a smaller group (only about 4% of product codes -- 1/3 the number of implantable product codes).  About 9% of implantable devices are also already considered life supporting/life sustaining.  The essential nature of these devices to patient health makes them a high priority to collect device identification information.  Device information on 160 additional medical device product codes (associated with close to 20,000 additional device submissions) could be collected and made available for analysis as well as many other uses. With the increasing use of real-world data (which may originate in health information systems – specifically electronic health records, and associated health records and transactions) as real-world world evidence for regulatory decision making, it is imperative that the data collected about devices is standardized across the healthcare ecosystem so that it may be used for interoperability.  If these life supporting/life sustaining devices can be reliably identified from the point of use, insertion or implantation – we may be able to rely on some of the additional features of those devices e.g., use of standardized device settings and metrics in the future.  We therefore recommend that unique device identifiers be required for life supporting/life sustaining devices in addition to the existing requirement for implantable devices.  This may also advance the adoption of UDI across the healthcare ecosystem and improve the ability of various stakeholders to incorporate it into their primary and secondary business processes.  For example, device identification information is important to effectively assess patient safety events (e.g., active surveillance, adverse events and/or recalls).

Data Class: Unique Device Identifier(s) for a Patient’s Implanta

Data Class: Unique Device Identifier(s) for a Patient’s Implantable Device(s)

Level 2 Data Element: UDI-Production Identifier-Serial or UDI-PI-Serial

Level 2 Data Element: UDI-Device Identifier or UDI-DI

Level 2 Data Element: UDI-Production Identifier-Lot or UDI-PI-Lot

Level 2 Data Element: UDI-Production Identifier-Manufacturing Date or UDI-PI-Manufacturing Date

Level 2 Data Element: UDI-Production Identifier Expiration Data or UDI-PI-Expiration Date

Level 2 Data Element: UDI-Production Identifier-Distinct Identification Code or UDI-PI-DIC

IMO does not support the additional Level 2 Data Elements in the data class for Unique Device Identifier(s) for a Patient’s Implantable Device(s).  The currently specified data element in Draft USCDI V3, Unique Device Identifier(s) for a patient’s implantable device(s) combines all of the proposed level 2 data elements in one value. Breaking this value up into separate entries adds no additional value and creates extra burden for HIT developers.

 

Log in or register to post comments