Instrument, machine, appliance, implant, software, or similar device intended to be used for a medical purpose.

Data Element

Device Type
Description (*Please confirm or update this field for the new USCDI version*)

Kind of instrument, machine, appliance, implant, software, and similar medical device.

Applicable Vocabulary Standard(s)

Applicable Standards (*Please confirm or update this field for the new USCDI version*)
  • SNOMED Clinical Terms (SNOMED CT®) U.S. Edition

View guidance on Applicable Vocabulary Standards and versioning.

Comment

Emory Healthcare comments on Device Type

EHC appreciates the need to and utility of specifying device types, but we have concerns about the ambiguity of certain devices. For example, an intrauterine device is considered both a medical device and a medication. We seek clarity from ONC on how devices like those might be best documented.

ACLA Comments: Device Type

The American Clinical Laboratory Association (ACLA) appreciates the opportunity to comment on Device Type. 

 

This would be very burdensome and there could be different types for the same test across the collection and testing processing. We recommend further research on the usage of this information and what value it would provide. Additionally, it can impact the size of the result message.

 

ACLA supports improvements to interoperability infrastructure that will increase patient safety.  However, there will be some major challenges with ensuring high quality UDI data is broadly available. The first is the limited use of UDI data in most clinical encounters and settings. Providers do not currently factor UDI information into the clinical decision-making process as it is not a critical piece of information for treatment decisions.  The required inclusion of non-pertinent information to a test result can slow down the decision process and adds costs to interoperability support and implementations.  Furthermore, existing LIS platforms may not broadly support the inclusion of UDI information with a test result.  Updating these LIS systems can be expensive and time consuming while having limited impact on patient treatment decisions.  ACLA is concerned that the inclusion of UDI in USCDI version 8 will not lead to broad adoption with high-quality data. 

 

This is not currently supported by most laboratories and would have an impact on the technology and operational aspects.  We suggest that ASTP work with FDA, CMS/CLIA, public health agencies, laboratories, and instrument manufacturers to establish a practical roadmap.

 

SHIELD USCDI V7 Draft Device Type element comment

SHIELD supports the inclusion of this data element, but we would welcome clarification how this is intended to be used in conjunction with the Unique Device Identifier element. This also would benefit from a more crisp scope around which devices are expected to be tracked for laboratory result values and suggest to initially focus on instruments and test kits/reagents, not controls, calibrators or other consumables.

We suggest narrowing the scope of SNOMED CT to descendenants of 272181003 |Clinical equipment and/or device (physical object) and add the follwoing Usage Note: “This element supports categorization of medical devices, while the UDI element identifies the specific medical device used for that patient, procedure, performed lab tests.”

Does not cover calibrators, controls, or consumables

APHL suggests that ONC clarify that this element does not cover calibrators, controls, or consumables. We recommend that ONC update the usage notes as such: "This element supports categorization of medical devices, while the UDI element identifies the specific medical device used for that patient, procedure, performed lab tests."

Support for vocabulary standard designation

SNOMED International supports the designation of SNOMED CT as an applicable vocabulary standard for Device Type and recommends its elevation to required status. SNOMED CT physical object hierarchy provides a clinically validated, regularly updated taxonomy of medical devices spanning implantable, non-implantable, therapeutic, and diagnostic categories. 

Critically, the NLM's AccessGUDID database maps FDA UDI to device characteristics and includes SNOMED CT mappings. Establishing SNOMED CT as the terminology bridge between FDA regulatory device identifiers and clinical documentation systems. This linkage directly supports the interoperability goals of the 21st Century Cures Act's information blocking provisions.

SNOMED International notes that HCPCS Level II codes, while appropriate for billing and reimbursement contexts, lack the hierarchical structure necessary for computable clinical queries and decision support. SNOMED CT supports semantic subsumption, enabling queries such as 'identify all patients with an implanted cardiovascular device'. This directly serves the population health and safety surveillance objectives of CMS value-based care programs. 

Designating SNOMED CT as required for Device Type, consistent with its adjacent Medical Device Order designation, would prevent parallel incompatible coding systems from emerging as Device Type data are exchanged across TEFCA. NCQA's concurrent adoption of SNOMED CT for device-related quality measures further validates its readiness.

NCQA recommendation: device type terminology

Recommendation: Add HCPCS terminology to applicable vocabulary standard.

 

Rationale: In addition to SNOMED, HCPCS represents an appropriate terminology to capture device types. NCQA HEDIS® measures use SNOMED and HCPCS in value sets to define specific device types, such as wheelchairs or continuous glucose monitors.

CMS-CCSQ Supports Device used for USCDI v7

Recommendation:  CMS CCSQ recommends the Device Used element be added to final USCDI v7.

Rationale:  CMS CCSQ advocates for the inclusion of the Device Used data element into the final USCDI v7, as it is a critical piece of information that is necessary in all care settings and includes devices such as hearing aids, communication devices, glasses, mobility aids (e.g. wheelchairs, walkers, canes), prosthetics, adaptive utensils, oxygen concentrators, ventricular assistive devices, and many more. While the current Medical Devices data class includes the Unique Device Identifier (UDI), it does not capture the actual use of devices which is essential information in the post-acute care (PAC) setting. Device Used data supports completion of required patient assessments at admission and discharge, during long-term care, rehabilitation, and home health care and can help reduce adverse events during these transmissions by identifying device dependencies and support. With established ontologies for medical devices in Systematized Nomenclature of Medicine (SNOMED) and LOINC, this data element is well-supported and ready for inclusion, ensuring that healthcare providers can effectively track and manage the diverse range of devices used by patients. CMS assessment tools leverage LOINC codes addressing use of devices such as a wheelchair or scooter, including:

  1. Does the patient use a wheelchair/scooter during assessment period (95738-1),
  2. Wheel 50 feet with two turns usual functional ability during assessment period (94992-5),
  3. Indicate the type of wheelchair/scooter used during assessment period (95739-9),
  4. Wheel 150 feet – usual functional ability during assessment period (94991-7),
  5. Wheel 150 feet – functional goal (89377-6), Prior device use (83234-5),
  6. Mobility devices normally used during assessment period (86602-0), Stairs (85072-7),
  7. Hearing aid present & used (45499-1, Hearing aid present and not used regularly (45500-6),
  8. Need for and availability of a hearing aid (94900-8),
  9. Need for and availability of a communication device (94901-6)
  10. Number of days of training and skill practice in amputation or prosthesis care (45867-9).

Additionally, Device Used data are captured in a published FHIR IG titled Personal Functioning and Engagement (PFE) Implementation Guide v 2.0.0, compliant with United States (US) Core 6.1.0.

Including this data element in final USCDI v7 will facilitate efficient healthcare delivery by assisting providers in identifying critical healthcare interventions.

PACIO Recommends Advancing Device Used to USCDI V7

  • Recommendation: Advance Device Used from Level 2 to USCDI V7.
  • Rationale: The PACIO Project Community* recommends advancing Device Used (Level 2) to USCDI V7. This recommendation aligns with the recommendation provided by (1) CMS-CCSQ, which “advocates for the inclusion of the Device Used data element into the final USCDI v6”, and (2) the Academy of Nutrition and Dietetics that Device Used which states that it represents a critical piece of information that spans every setting of care. Devices used in care can include both implantable or external devices used for a broad range of applications including hearing aids, cochlear implants, augmentative and alternative communication (AAC) devices, glasses, wheelchairs, walkers, canes, oxygen concentrators, adaptive utensils, adaptive drinking vessels, Ventricular Assist Devices (VADs), pacemakers, and many others. Device information is important to document and share across care settings, as many patients use devices to support not only their health but also everyday living, fall prevention, and rehabilitation.
  • Data Standard: Device data is already being captured in various assessments used across care settings, like the FASI, which is used by many Medicaid programs, and the AM-PAC mobility assessment
  • The Unique Device Identifier is captured for devices, the clinical notion of what that device is, is not captured. Device Used would capture the “what” in a comprehensive and discreet way across all settings and be inclusive of both implantable and external devices. The codeable concepts are well established in both the SNOMED and LOINC ontologies and device used information is essential for supporting patients across care settings, including post-acute care, through better capture and sharing of this information.
  • These Device Used data are captured in a published Personal and Functional Engagement (PFE) FHIR IG STU-2, compliant with US Core 6.1.0 and based on the FHIR R4 DeviceUseStatement resource. One specific example of data capture is Epic Systems captures the FHIR R4 Device and DeviceUseStatement resources as seen on Open Epic.
  • * The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, that aims to advance interoperable health information exchange between post-acute care (PAC) providers, patients, and other key stakeholders across health care.

Log in or register to post comments

Add a New Comment

Review comment and Submit

Edit
Comment #1
PDF, Doc, Docx
Max Size : 10 MB