USCDI Draft-V6 Feedback
- riki.merrick
- Anonymous
United States Core Data for Interoperability (USCDI)
Feedback is due by April 14, 2025, at 11:59 PM ET and targeting release of the final USCDI v6 in July 2025
Other Resources
HL7 OO:
Feedback collection: https://confluence.hl7.org/spaces/OO/pages/320995622/USCDI+v6+Draft+-+OO+Feedback
CLIA element mapping to USCDI: https://confluence.hl7.org/spaces/OO/pages/256515226/US+-+CLIA+Elements+mapping+to+HL7+data+elements
Specific asks per https://www.healthit.gov/isp/sites/isp/files/2025-01/Draft-USCDI-Version-6-January-2025-Final.pdf and ASTP Standards Bulletin 2025-1 | HealthIT.gov :
Suggestions for improvement in the data classes or elements in Draft USCDI v6, including:
Data class and element definitions, usage notes, and examples; and
Examples of code systems used by health IT developers and implementers to communicate data element scope.
Should other existing Level 2 data elements be added to USCDI v6 instead of, or in addition to, those in Draft USCDI v6? If so, why?
Which additional data elements from USCDI+ domains should be added to USCDI v6?
Are there significant barriers to development, implementation, or use of any of these data elements that warrant a change in the final version of USCDI v6?
New or modified data elements of interest to SHIELD:
CHANGE: Used to only apply to implantable medical devices, now broadened to apply to ALL devices used in medical care
Specific ask: Feedback on whether Unique Device Identifier (UDI) should be one or two data elements (Unique Device Identifier—Implantable and Unique Device Identifier—Non-implantable). Is there an impact on standards development or information exchange to use one data element, Unique Device Identifier, to include both implantable and non-implantable devices?
Notes:
previously rejected additional data element for test kit and instrument identifiers can now be covered by this
Unclear scope as to how many UDIs are needed for which items. Many healthcare disposables are devices from collection tubes, needles, gauze, quality controls, calibrators, instrument disposables like cuvettes,microscopes, slides, reagents, instruments, etc.
For example for a laboratory result, would the specimen collection container, additives, different bore needles used to collect, QC, calibrators, reagents, disposable reagent dispense tips, reagent cartridges, etc.
For a surgery, would the scope include all gauze, lab tests, instruments whether electronic or manual like knives, tubing, IV bags, etc.
For pathology, would this include each container, additive, fixative, slide, coverslip, oil for oil immersion, parrafin for blocks, microtome, instrument used in fixing tissue, staining slides, microscope, digital pathology slide scanner, reagent in each type of stain, each antibody in FISH, each reagent in PCR, etc.?
If broader scope, it would be a huge burden on all, especially laboratory professionals. HIT vendors need to ingest UDI info and associate/map with data elements, store, exchange/report, use, have functionality to search, sort, etc
Discussion that Health IT needs to capture and support UDI. No requirement information about what types of devices. That is up to each user.
Discussion about utilitiy of more specificity of UDI in clinical interoperability
may not have enough information about devices for clinical interoperability and important in a safety and clinical context. (Julia)
UDI is lynchpin for laboratory tests in the future. Cannot compare two systems. In clinical trials. Information is different. Non starter for RWE.
During COVID, weren’t able to use clinical results since they didn’t have information about devices.
Also reference ranges needed.
UDI pushing to claims level (steve) would be useful.
Natalee: necessary during reconcilliation for effective data artificates deduplication. HIT vendors are receiving results from others/ingestion If we don’thave enough information cannot ingest data. If different reference ranges cannot mix with existing EHR data, display on same line, etc. Results may impact patient outcomes. Patient results may be plotted on same curve, creating issues. Reconcillation is huge. Laboratory data occupies 90% of clinical records. Most volume of artifacts. Very important laboratory results support 80% of diagnosis.
Questions:
Is this all calsses of devices
Is our recommendation on how medical devices apply to a procedure or observation in USCDI. Dr. Luu: USCDI is different construct. Meant to be you draw from data elements what you need. Report date is not part of lab grouping. On it’s own. Expectation can use others. Want single use and not duplication in each class/hierarchy. Would draw from UDI to support your model.
Julia: using a single construct across clsses is opportunity to improve data across healthcare, not just implementation. For claims would be pervasive. Would be helpful for context.
Dr. Luu: How is this represented by the NHS? Karim: post coordinated code. from the devie hierarcy in SNOMED CT in FHIR. Trying to update/replace. Old system doesn’t carry standardized devices. Old Read codes. Some ambiguity and not clear. want to flow SNOMED CT. Device type in FHIR profile. Question on specificity. Haven’t investigated throughly, the device types. Looking at comparability of testing such as POCT, patient reported, and in lab testing. Working on observation content currently. Not as standardized in the lab space.
CHANGE: identifies LOINC as the standard to use - version 2.78
Notes:
Clarification needed if the operational definition is the laboratory order (test name) or laboratory order (entire requisition/CLIA Test Request which includes the test order name, ordering provider, Ask at Order Entry questions, specimen, etc.)
Recommend clarifying this includes all orders including reflexive orders, such as susceptibility testing orders, organism identification.
Performance Time (under Procedure):
CHANGE: UNCL
EAR WHAT CHANGED.
Notes:
lab still does not have an equivalent for this data element to cover
CHANGE: Definition is now: Unit of measurement to report quantitative laboratory test results
Was called out as having updated definition, but definition remained unchanged, but UCUM updated from 2.1 to 2.2
Unclear if Units and UCUM need to be supported for non quantitative result values. May wish to request updated definition of when Units are reported by a laboratory, they are retained and UCUM is used as the standard
Discussion
Quantitative and Semiquantiative Result types
micro, immunology.
organisms usually mapped to the organism hierarchy
qualifier value hierarchy mapped to qualitative and semiqualitative values like detected, not detected, 1+, 2+
Reviewed USCDI versions
request to use appropriate SCT hierarchies
ASTP: USCDI more data model based, vs data elements. so it may not be cohesive for interoperaiblity so folks can implement once. Folks are implementing different flavors that may not fit together .
Why we need control structures too.
Updated versions of referenced code systems for these elements in the Laboratory Class:
Tests → LOINC version 2.78
Notes:
Values/Results → SNOMED US Edition September 2024
Notes:
Specimen Type → SNOMED US Edition September 2024
Notes:
Specimen source site → SNOMED US Edition September 2024
Notes:
Result Unit of Measure → UCUM 2.2
Notes:
Reference Range → UCUM 2.2
Notes:
Specimen Condition Acceptability → SNOMED US Edition September 2024
Notes:
This item should be split into two separate items to allign with CLIA requirements.
Specimen Reject Reason
Specimen Condition
Specification is not given as to where in the LIS or EHR this is reported/used. Currently in the LIS/APLIS, this is reported different ways in different areas for different test results.
Specimen Condition for a result reported as a panel usually involves a chartable comment field associated with a result value whether a number or * or other comment.
Said comment fields do not typically have capability to map to SNOMED CT codes. This functionality would need to be built across ALL HIT to support both sending and receiving.
The second way Specimen Condition is reported is as a laboratory result and value. The HIL Index is a common example. See Development of an Integrated Reporting System for Verifying Hemolysis, Icterus, and Lipemia in Clinical Chemistry Results
A Basic Metabolic Panel may have a number of test results and the HIL Index reported, whether with a qualitative result value or a numeric value. The HIL Index is a laboratory result, which would be mapped to a LOINC code in accord to USCDI. The value of the HIL Index if numeric would not be mapped to a codesystem. However, if qualitative or semi-quantitative, it could be mapped to a SNOMED CT code (from the qualifier value hierarchy).
It’s unclear with USCDI, how the different modeling of this element would be handled in HIT, but also exchanges, whre USCDI is cited.