Medical Devices

SHIELD Community Proposal for Updates in V7

SHIELD requests clarification on the scope of what is covered by the medical device element at the class level; For laboratory data, SHIELD suggests to focus on medical devices that directly produce diagnostic results, such as instruments and test kits / reagents, but not include calibrators, controls, containers, disposable supplies (plates, pipette tips, etc) and microscopes

Comment

Recommend adding the Medical Device Name and Medical Device Use as data elements.

Recommend adding Durable Medical Equipment (DME), Medical Supplies (e.g., Blood Glucose Test Strips, Lancets, Pen Needles), and Medical Devices (e.g., CPAP, Oxygen-air delivery) as part of this data class definition.

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.

Medical Device Identification and Device-related Information

There are many use cases that would benefit from the inclusion of medical devices or equipment being included in the USCDI.  In support of the Devices Used (CMS) and Device Settings (CDC) submissions under the Medical Device or Equipment class -- the data elements included in their submissions would help identify and describe the use of medical devices to include, but not limited to: unique device identifier (UDI), device type, associated device manufacturing information (manufacturer and device name), pertinent device usage information (e.g. location, route, settings, etc.).  We would like to see the data elements mentioned in the proposals identified as individual data classes and merged with other device related data classes and elements (e.g., unique device identifier(s) for a patient's implantable device). 

Also see our previous comments from FDA/CDRH related to the device-related information.

Alignment of data classes and elements for devices

The CMS Data Element Library (DEL) Health IT Workgroup supports the recommendations made by CMS-CCSQ and FDA/CDRH on advancing the inclusion of device-related information in USCDI, including unification of the current device-related USCDI Data Classes based on common data structures. We note that within the assessments used post acute care, information about assistive device types (not detailed device-instance information) used is captured and exchanged. In its implementation guides, the PACIO project has developed FHIR profiles based on the DeviceUseStatement resource.

CMS-CCSQ Support for Devices Used data element for USCDI v3

CMS-CCSQ recommends inclusion of Devices Used (applied) data element in USCDI V3, defined as discrete codes for types or categories of devices used by patients (non-implantable devices: mobility devices and wearable devices; and implantable devices).
 

Rationale: Information related to devices used by patients – specifically mobility, wearable and implantable devices – is critical information that must travel with a patient to ensure safe, effective care. Additionally, this information is widely used for quality measurement use cases; for example, it supports identification of disability (i.e., walking or hearing assistive devices) and/or frailty to ensure patients receive necessary support during the continuum of care. Device use information is also critical information for prior authorization activities, as many DMEPOS require prior authorization. Types of devices used by patients are a type of observation, with a discrete code for the device used, that is documented and can be exchanged to support patient care in the same model structure as other clinical observations. Therefore, ONC may consider operationalizing this data in the USCDI like other observation data as discussed above.

Maturity:

• Current standards:
  • Extensive guidance exists in FHIR US Core and QI Core IGs for how to exchange device information (as observations, procedures)
  • SNOMED, LOINC, HCPCS terminologies are standardly used to code devices
    • i.e., Frailty Device, value set OID: 2.16.840.1.113883.3.464.1003.118.12.1300
    • i.e., https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/DMEPOS/Downloads/FINAL-RULE-MASTER-LIST-of-DMEPOS-Subject-to-Frequent-Unnecessary-Utilization-2018-03-30.pdf
• Current uses, exchange, and use cases: This information continues to be widely captured and exchanged for nationwide CMS quality measurement. For example, it supports identification of disability (i.e., walking or hearing assistive devices) and/or frailty to ensure patients receive the support they need during the continuum of care. Device use information is used for prior authorization activities, as many DMEPOS require prior authorization.

Data Element: "Airway Device Route" for Mechanical Ventilation

Invasive mechanical ventilation is an important clinical intervention for clinicians, clinical researchers and public health entities to track.  Invasive mechanical ventilation can signify acute respiratory failure, which is an important clinical outcome.  During a pandemic, understanding the burden on health systems and severity of illness of affected patients requires knowledge of the use of invasive mechanical ventilation in a facility for surveillance. 

Documentation of an artificial airway and use of a ventilator is part of standard clinical practice.  Every patient on a ventilator will have the airway type documented (in addition to ventilator modes) in their clinical record of care.  In most cases, patients being invasively ventilated will have an endotracheal tube documented as the route of oxygen delivery (as opposed to a face mask or nasal cannula) and this alone will be sufficient to find the patients who are on a ventilator.  In a few scenarios (use of a tracheostomy), additional information will be necessary to find these patients.   

We propose that a new data element: airway device route/oxygen delivery route is sufficient to determine which patients are receiving invasive ventilation (vs oxygen alone vs non-invasive ventilation).  This is the least burdensome method of finding patients who are invasively ventilated and does not require details about ventilator modes. 

We have spoken with multiple clinicians including the following clinical leaders of major medical organizations and have support for using airway device route as a means to determine which patients are on a mechanical ventilator, and the importance of making this a standard USCDI data element.  This data element is already in extensive use in Electronic Health Record systems and is captured as a regular part of clinical care. 

• Greg Martin, MD, MSc, FCCM, Professor of Medicine, Division of Pulmonary, Allergy, Critical Care, and Sleep Medicine, Department of Medicine, Emory University School of Medicine, President of the Society of Critical Care Medicine (SCCM) 

• Craig Coopersmith, MD, MCCM, FACS, Professor of Surgery and Director, Emory Critical Care Center Emory University School of Medicine, Past President, Society of Critical Care Medicine (SCCM) 

• David Murphy MD, PhD, FCCM, Associate Professor in the Division of Pulmonary, Allergy, Critical Care and Sleep Medicine, Emory University School of Medicine, Patient Safety Officer, Emory Healthcare 

• Sheri Chernetsky Tejedor, MD, SFHM, Associate Professor of Biomedical Informatics and Medicine, Division of Hospital Medicine, Emory University School of Medicine, Past Chief Research Information Officer and Medical Director of Analytics, Emory University School of Medicine and Emory Healthcare, Medical Informatics Advisor to the Centers for Disease Control 

Device-related Data Classes and Elements

The FDA/CDRH would like to work with the broader interoperability community to ensure that the device-related concepts are validated and correctly modeled within USCDI.  We agree with the current maturity of the device-related concepts.  We would like to work with ONC to further advance the maturity of the proposed device-related data classes and elements currently specified in the Level 2 and in the Comments sections. 

USCDI_CDRH_DeviceComments.docx