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:

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. 


Log in or register to post comments