UDI Background
What is UDI?
Official FDA: https://www.fda.gov/media/99084/download
Image example:
There are different schema to put these into a single string - shown here is GS1. FDA has accredited three organizations as UDI issuing agencies: GS1, Health Industry Business Communications Council (HIBCC), and International Council for Commonality in Blood Banking Automation (ICCBBA).
UDI components:
the device identifier = identifies the kind of device similar to make and model of a car
a production identifier = identifies the instance of the device similar to the serial number of a specific car:
Serial number (for instruments and larger devices)
lot number (group produced together - for smaller devices like tubes etc)
expiration date (could apply to anything that could expire (maybe due to reagents included etc)
related to UDI, but not encoded in it:
Manufacturer name
Model name
Other codes FDA assigns, can be traced back via the DI - example: https://accessgudid.nlm.nih.gov/devices/30014613339755
Pro Code = type of device. In the screen shot below, QVF is the Procode. It is named as the Product Code in the screen shot.
Look up for UDIs: 
AccessGUDID - Identify Your Medical Device
UDI in HL7: HL7 Cross Paradigm Implementation Guide: UDI Pattern, Release 2
Current Representation of devices in IHE LAW
Specification: https://www.ihe.net/uploadedFiles/Documents/PaLM/IHE_PaLM_TF_Vol2b.pdf
Slide screenshots from:
Instruments:
Reagents and test kits:
See slides for proposed options of updates to the IHE LAW profile
Current Representation of devices in IICC LIVD
Specification: 
LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results - IVD Industry Connectivity Consortium NFP
Manufacturer Name
Model Name
Vendor Analyte Name (may be used for test kit parts or reagents)
Test Kit Name ID (and ID-type)
Equipment UID (and ID-type)
Use Cases for device tracking
Inside the lab:
CAP Accreditaiton Requirements (is happening today, but is not exchanged outside the lab, so often not in LIS/LIMS - at least not where easily accessible for sharing)
GEN.43920 lists CAP General Checklist accreditation requirements where multiple identical analyzers are in use by a laboratory. Note this is from a 2022 Checklist. Current Checklists should be utilized.
New York State and Washington State are the 2 jurisdictions exempt from CLIA. Each of these jurisdictions has their own requirements, often more specific than CLIA.
Nonetheless, Kathleen Figetakis confirmed on the 16Dec25 call that Washington state Public Health Lab is CAP accredited. Thus it would need to meet these requirements, as would any laboratory in these jurisdictions that is CAP accredited.
How is this met currently in laboratories?
Cerner PathNet LIS: There is LIS functionality for indicating a workcenter and test site, where the workcenter is usually a unique ID for each laboratory within the system. The Test Site is usually used to indicate each laboratory “bench” which may leverage multiple point of care or bench instruments. Where the same model of instrument is used, often these are created as separate unique identifiers for each test site to meet the CAP accreditation requirement above.
Further, when an instrument is down, say at a clinic and they do not have a back up, the patient tests can be transferred to another laboratory within the health system (e.g. hospital, another clinic), and the specimen(s) sent via courier to that location so testing can be performed at the location for patient care. Transferring to the different workcenter/test site shows the actualy instrument(s) upon which the testing was actually performed.
LIMS
Epic Beaker LIS: @hung can you provide?
Additional CAP Accreditation requirements from the General Checklist (2022 version. check current version for any updates.) See below where there are additional requirements in other checklists.
GEN.20377
See screen shot below. “For data directly transmitted from instruments to the laboratory computer system via an interface (online system),…” there needs to be a …“readabable electronic record of the data for at least two years.”
Interfaced data from instruments need to be retained (typically in the LIS) for at least 2 years. If UDI or other IVD device information is transmitted in the future, it looks to be applicable to that data as well.
Where instruments are not interfaced, the 2 year requirement applies
Requirements on identifying all those entering and updating patient data/results, incuding sequential corrections. Also identifying all involved in performing and entering testing uniquely.
There's a section on Autoverification requirements including:
CLIA/CAP result traceback requirements - get confirmation that the full UDI of the instrument, which includes the device ID and the serial number (PI), would fullfill that requirement
Providers for patient care
understand if results are comparable to others in their system (particularly for results from labs outside the same organization/reference labs)
Clinical Research
Understand if results are comparable between patients in a cohort / population
Understand test behavior over time
Public Health
during COVID:
better understand which specimen type is reliable for which detection method
better understand test performance when virus mutates
Understanding diagnostic protocols used for more comparable surveillance results
Screening vs confirmatory
assess reportability
data quality / de-duplication / understanding result variability across different laboratories
Assess unusual positivity patterns / identify potential testing issues
Feedback from PHAs:
Epi:
current use (from COVID): brand name, generic description, manufacturer name
future use: in addition Lot/batch, expiration dates, model number, version number
[NOTE: manufacturer name, model number, generic description, brand name are all covered by the DI part of the UDI; lot number, expiration date, serial number and version number are all PI of the UDI]
additional data of interest: meta data about the device like limitations of use, required testing envrionment, generation of structured data for automated data extraction [NOTE: all these would be available for look up in LIDR based on DI in UDI]
Adding one or more fields to capture this in surveillance system is not a big lift for PHA
Lab:
feasible to report: things that don't change with every test and things that are used in inventory tracking, SOP development (different system currently, but already tracked):
Easier: Manufacturer name > Model number > Brand name > Generic name/description > Serial number > Version number
Harder: Lot or batch number > Expiration date > date of manufacturer / catalog number
while out of scope for SHIELD, for public health it is important to consider non-clinical samples and their reporting requirements - also for incorporating the SDOH:
veterinary
envrionmental (sewer, water, soil, air)
food
Adverse Event reporting
Form 3419 requirements (hospital labs): https://www.fda.gov/media/87974/download
Form 3500 requirements (patients, consumers, non hospital labs, etc.): https://www.fda.gov/safety/medwatch-forms-fda-safety-reporting/instructions-completing-form-fda-3500
IVD and Manufacturer reporting: https://www.fda.gov/medical-devices/postmarket-requirements-devices/mandatory-reporting-requirements-manufacturers-importers-and-device-user-facilities
CAP Accredidation requirements on facility adverse reporting requirements:
Post-market research for IVD vendors
Questions
Are the above mentioned use cases accurate?
verified the PH use case and the clinical use case
need more input on Adverse event reporting and post-market research
How are traceback requirements currently met?
if in electronic form, can we come up with best practice to store?
if not yet electronic, what functionality is needed to support across ALL domains of lab results?
What are the kind of devices that need to be tracked between organization?
Conclusions
Need to support the use case that needs the most granular device information, so need full UDI to be exchanged
For instruments:
in V2 use OBX-18 - works in IHE LAW (instrument → LIS), LRI (LIS → EHR-s / PH-s)
adjustments needed for IHE/LAW = AUTO-16:
First repeat of OBX-18.3 and OBX-18.4 make RE so that the DI can come over
Optionally could send the full UDI in first repeat (but would still send second repeat for the serial number)
in V2 could also use PRT to transmit UDI for instruments (optional profile in LRI)
For test kits / reagents:
in V2 use INV-1 for the DI and use INV-12 for Expiration Date and INV-16 for Lot Number
adjustments needed for IHE/LAW = AUTO-16:
add description of using the DI as the code in INV-1, where the text is the analyte name and the code system is the producer of the DI (GS1 for example) (INV-1 is a CWE datatype) - need to define the codes to use to represent the UDI assigning authorities (probably use “99GS1” for example, since unlikely that HL7 would add to HL70396 code system)
ORU^R01 message structure is does not support INV segment, but does support PRT (as an optional profile in LRI)
What other systems should get data out of the EHR-s?
current data comes out of EHR-s in C-CDA most often, not sure there is space for that
Add guidance
to manufacturers for dealing wih calculated tests (that come from the instrument, or use additional algorithms) to ensure there are UDIs available for those
to LIS to support UDI for LIS calculations
to LIS to ensure the correct UDI can be transmitted (also might be different when changing CBC with Auto-Diff to CBC with manual Diff)
LIDR will only have the device ID, but that is always part of the full UDI, so linkage can happen
Non-device specific clinical context (e.g. screening vs confirmatory) is NOT encoded in UDI - this still needs more guidance - suggestion is to create panels, where any additional information is sent as OBX as part of the panel