Test Kit Unique Device Identifier
OVERALL:
Current definitions
in USCDI: Numeric or alphanumeric code representing a collection of materials necessary to perform diagnostic tests with Applicable Vocabulary Standard(s) = FDA Unique Device Identification System (UDI System)
in USCDI+: Uniquely identifies the type of test (at minimum by using test name and manufacturer (similar to the make and model of a car)) that was used to obtain the Test Result Value. It is a device identifier and should be referenced using Device Identifiers (DI), when available. The DI is contained within the unique device identifier (UDI), created by manufacturer (Manufacturer requests UDI issuance, then provides DI, or can be pulled from GUDID database (https://accessgudid.nlm.nih.gov/).
Applicable Vocabulary for test kits that have no UDI - for those that are not FDA approved for example
COMMENT:
#1 - Definitions between USCDI and USCDI+ MUST be the same for this data element for the same use case
#2 - Update definition - proposal for review: Uniquely identifies the test reagent configuration (at minimum by using test name and manufacturer (similar to the make and model of a car)) that was used to obtain the Test Result Value. For FDA cleared/approved tests, refers to the a unique device identifier (UDI) , created by the manufacturer and available as a barcode and human readable text on the package.
should be available. At a minimum test name and manufacturer can be used to identify this element. Also acceptable is the Device Identifier (DI), which is contained within the unique device identifier (UDI) and can be retrieved from GUDID database (https://accessgudid.nlm.nih.gov/). Optimally the full UDI should be used, when available (can be formated as a barcode and/or human readable text).
Specific Feedback requested In the ONC Standards Bulletin (https://www.healthit.gov/sites/default/files/page/2024-01/Standards_Bulletin_2024-1.pdf) = ONC seeks feedback on the new Test Kit Unique Device Identifier data element that would be added to the Laboratory data class, including in what scenarios this data element would be useful and what experience health IT developers have exchanging this element.":
would need to also define requirements for storage in the LIS
when the test kit identifier is added to the results - options are:
provided it via IVD instrument interface as described in IHE LAW = CLSI AUTO-16
scan a barcode on the test kit package (data labels that are standardized and systemized reduce the burden of entering and risk of introducing transcription errors when doing this manually) - this is agnostic to where the scanning happens (can be at LIS or middleware or IVD instrument)
assigned to the test in the LIS set up (this would only be at the level of DI) and has a risk of becoming outdated, if not properly maintained
use cases based on what type of testing is performed - may be hard to request for manual tests, that are not IVD generated (some cultures, microscopy, anatomic pathology would fall into that category)
DI can be published in LIVD, looked up in the GUDID database (https://accessgudid.nlm.nih.gov/) or read on the package insert
LDTs are out of scope for SHIELD
APHL comment on USCDI+
Data Rationale portant to PHA and where currently available): For the clinical use case it is important to support result trending when obtained from different laboratories. For PH this is important to understand test performance, especially for EUA or new methods. For regulatory use case this can suport post-market surveillance and enhance migration of EUA to 510K applications as well as provide support for real world data use for research in general.
This data element will require some implementation planning in order to get to the expected full FDA defined UDI and its elements. While each laboratory tracks the tests they perform, documenting the UDI is not currently done in the LIS and creating a way to make that easiest for laboratories must be part of the plan.
Element specific Mapping, rather than just naming the resource:
V2: OBX-17 or OBX-18 or PRT-10 or PRT-22
FHIR: observation.device
CDA:
Suggest to elevate this element into V5 as it supports the use of Test Kit Identifier
Using the same applicable vocabulary as for Test Kit Identifier
Need to create a better model of relationships between the USCDI data element to help implementers understand the dependencies and cntext each of them provide for the use case they are implementing:
examples
Need for LOINC for patient generated wearables (continuous glucose monitor) that represent produce result values and need to be identified using the instrument identifier
units of measrue with result values for quant result
specimen type and source site
, so we didn’t explicitly consider it, but overall that area needs to be examined for impacts
Suggest to elevate this element into V5 as it supports the use of Test Kit Identifier
Using the same applicable vocabulary as for Test Kit Identifier, i.e. at minimum instrument name and manufacturer, DI of UDI, full UDI
Consider overall comment - WAS NOT DISCUSSED, so not included
Need to create a better model of relationships between the USCDI data element to help implementers understand the dependencies and cntext each of them provide for the use case they are implementing:
examples
Need for LOINC for patient generated wearables (continuous glucose monitor) that represent produce result values and need to be identified using the instrument identifier
units of measrue with result values for quant result
specimen type and source site
BACKGROUND INFO
APHL comment on USCDI+ for Test Kit Unique Identifier:
Data Rationale portant to PHA and where currently available): For the clinical use case it is important to support result trending when obtained from different laboratories. For PH this is important to understand test performance, especially for EUA or new methods. For regulatory use case this can suport post-market surveillance and enhance migration of EUA to 510K applications as well as provide support for real world data use for research in general.
This data element will require some implementation planning in order to get to the expected full FDA defined UDI and its elements. While each laboratory tracks the tests they perform, documenting the UDI is not currently done in the LIS and creating a way to make that easiest for laboratories must be part of the plan.Element specific Mapping, rather than just naming the resource:
V2: OBX-17 or OBX-18 or PRT-10 or PRT-22
FHIR: observation.device
CDA:
Other thoughts - not for submission:
...