/
USCDI Draft-V6 Feedback

USCDI Draft-V6 Feedback

Owned by riki.merrick
Last updated: Apr 02, 2025 by Anonymous
8 min read

Proposed wording to approve:

  • Overarching Comment:

    • 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 lab interoperability and many of the SHIELD participants have noted that without a complete set of lab data, they are unable to validate and therefore integrate the lab data that is currently flowing into care processes and analytics, resulting in low-yield data exchanges.

    • 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 lab 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 lab data model with other laboratory interoperability stakeholders.

  • Unique Device Identifier:

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

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

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

    • IVDs and LIS are closests to having device identifier information, they also need to support its captureLIS not part of HIT certification

  • Laboratory Order:

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

      • 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 Lab Compendium (CLIA requirement).

  • Performance Time (under Procedure):

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

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

      • important to track understand when results were available outside the lab as well as to understand any updates to lab results over time: reporting date/time (Definition: when the results are verified and released for reporting.; the requested lab reporting equivalent to PH / Case Reporting / Date of the Report)

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

      • If ASTP/ONC decides against inclusion in V6 we suggest that they at least be elevated to Level 2 given their wide adoption and availability and the fact that they are required under CMS CLIA regulations.

  • Result Unit of Measure:

    • SHIELD suggests ???

  • Updated vocabulary:

    • (or we can include this under Laboratory Order above): SHIELD supports the use of LOINC when an appropriate code is available for Laboratory Orders whenever they are being communicated externally and should cover the initial order and any "spin-off-s" such as individual occurrences of a multi-occurrence order, individual tests from a larger panel ordered to a reference lab, reflex, etc.

    • SHIELD suggests to update to the latest available version at time of publicaiton of V6 for all called out coding systems.

 

BELOW is BACKGROUND - not part of the vote!

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:

 

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 :

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

 

 

 

Add label

Related content