/
USCDI Draft-V6 Feedback

USCDI Draft-V6 Feedback

Owned by riki.merrick
Last updated: May 12, 2025
9 min read

Proposed wording to approve:

  1. Overarching Comment:

    1. SHIELD appreciates the role that USCDI plays in standardizing health data for interoperability in the laboratory space. However, the high level of the USCDI guidance leads to inconsistencies across the industry when individual health and laboratory entities need to determine individually how to fill in the gaps. The lack of a coherent data model is still a barrier to end to end laboratory interoperability and many of the SHIELD participants have noted that without a complete set of laboratory data, they are unable to validate and therefore integrate the laboratory data that is currently flowing into care processes and analytics, resulting in low-yield, low quality data exchanges.

    2. SHIELD strongly encourages ASTP/ONC to consider expanding USCDI’s laboratory data class to more formally define a data model for the current collection of data elements, including more formal vocabulary bindings. This would add great value by improving laboratory data interoperability and could be an opportunity to onboard Laboratory Information Systems into FHIR data exchange with standardized source data. SHIELD would be excited to offer its industry, informatics and healthcare expertise to any effort to build out a shared laboratory data model with other laboratory interoperability stakeholders.

  2. Unique Device Identifier:

    1. In principle SHIELD supports the creation of single construct across classes in USCDI because it is an opportunity to improve data across healthcare.

    2. SHIELD suggests to focus on the device model part of the UDI, as that may be sufficient and easier to ingest into the documentation flow to start.

    3. In the laboratory domain being able to include the device identifier (we previously had requested inclusion of USCDI Data Element Test Kit Unique Identifier and USCDI Data Element Instrument Unique Indentifier) which is critical for reconcilliation for effective data artifacts deduplication, for example as part of clinical trials, in patient charts for laboratory results from different institutions and for creation of Real World Evidence (RWE). Without sufficient details about the performed test, EHR-systems cannot safely ingest data, utilize in chart views, which may impact patient outcomes. Laboratory data occupies 90% of clinical records and laboratory results support 80% of diagnosis. Here we reiterate the requests to include USCDI Data Element Test Kit Unique Identifier and USCDI Data Element Instrument Unique Identifier in USCDIv6.

    4. IVDs and LIS are closest to having device identifier information, they also need to support its capture, noting that LIS not part of HIT certification

    5. In support of seamless UDI exchange, it would be important to facilitate the definition and exchange of this data within/between In Vitro Diagnostic (IVD) devices and Laboratory Information Systems (LIS). It should also be noted that in most cases there are no incentives for the developers or users of these systems to adopt certified HIT.

    6. HIT should support the addition of UDIs to laboratory results, the updating of UDIs (if entered in error), the association of one or more UDIs to a laboratory result, exchange of the UDI with laboratory results, receipt of all UDIs associated to laboratory results and search for UDIs and/or laboratory results reflecting both.

  3. Laboratory Order:

    1. SHIELD suggests ASTP/ONC clarify the scope of this data element as the current definition is not clear enough:

      1. Given that ASTP/ONC associates LOINC as the required vocabulary for Laboratory Orders, most likely the data element targeted here is “Ordered Test” which should cover both the code (drawn from LOINC and available as USCDI+ Public Health Lab Use Case Laboratory Test/Panel Code as well as the display name for that test in the Laboratory Compendium (CLIA requirement) compared to the CLIA defintion of what the test request needs to include (42 CFR 493.1241 -- Standard: Test request. ).

      2. SHIELD supports the use of LOINC when an appropriate code is available for Laboratory Orders whenever they are being communicated externally and should cover all orders; the initial order, individual occurrences of a multi-occurrence order, individual tests from a larger panel ordered to a reference laboratory, reflex, etc.

  4. Performance Time (under Procedure):

    1. Since laboratory tests are not medical procedures performed on a patient, SHIELD suggests ASTP/ONC consider adding the following widely implemented (through HL7 v2 laboratory result messaging in support of CMS CLIA regulations) laboratory test related date/time stamps to V6:

      1. as equivalent to procedure performance time: test result date/time (Definition: when the analysis is performed on the specimen(s) creating the observation, or when the result is calculated on existing observations.) We would argue that this is a Level 2 element already because of its widespread capture and use in healthcare.

      2. to track and understand when results were available outside the laboratory as well as to understand any updates to laboratory results over time: reporting date/time (Definition: when the results are verified and released for reporting.; the requested laboratory reporting equivalent to PH / Case Reporting / Date of the Report). We would argue that this is a Level 2 element already because of its widespread capture and use in healthcare.

      3. clinically important for interpretation of results: Laboratory / Specimen collection date/time / Level 0: (Definition: Date/time when clinical specimen was collected from subject patient. This is the clinically relevant date time of an observation when a specimen is collected for a test.) We would argue that this is a Level 2 element already because of its widespread capture and use in healthcare.

      4. The proposed elements should not be considered Level 0 or 1; they must at least be elevated to Level 2 given their wide adoption and availability and the fact that they are required under CMS CLIA regulations.

  5. Result Unit of Measure:

    1. SHIELD suggests use of UCUM for unit in measure unless the test has an element that is not captured through a standardized set of units (such as a clinical set of criteria specific to an individual laboratory test).

  6. Updated vocabulary:

    1. SHIELD supports the use of LOINC when an appropriate code is available for Laboratory Orders whenever they are being communicated externally and should should cover all orders; the initial order, individual occurrences of a multi-occurrence order, individual tests from a larger panel ordered to a reference laboratory, reflex, etc.

    2. SHIELD suggests to update to the latest available version at time of publication of V6 for all called out coding systems/terminologies.

 

BELOW is BACKGROUND - not part of the vote!

https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#draft-uscdi-v6

Feedback is due by April 14, 2025, at 11:59 PM ET - was extended to May 12, at 11:59 PM ET and targeting release of the final USCDI v6 in July 2025

Other Resources

HL7 OO:

 

Specific asks per https://www.healthit.gov/isp/sites/isp/files/2025-01/Draft-USCDI-Version-6-January-2025-Final.pdf and https://www.healthit.gov/topic/standardsbulletin_25-1 :

  1. Suggestions for improvement in the data classes or elements in Draft USCDI v6, including:

    1. Data class and element definitions, usage notes, and examples; and

    2. Examples of code systems used by health IT developers and implementers to communicate data element scope.

    3. 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?

    4. Which additional data elements from USCDI+ domains should be added to USCDI v6?

    5. 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:

  • Unique Device Identifier:

    • 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 classes 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 classes 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 device hierarchy 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.

            •  

  • Laboratory Order:

    • 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: UNCLEAR WHAT CHANGED.

    • Notes:

      • lab still does not have an equivalent for this data element to cover

  • Result Unit of Measure:

    • 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 https://pmc.ncbi.nlm.nih.gov/articles/PMC4071188/

            • 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.

 

 

 

Add label

Related content