CMS RFI Feedback
Request for Information; Health Technology Ecosystem due Jun 16, 2025
Other background:
HL7 Health Technology Ecosystem RFI - May 2025 - Patient Empowerment - Confluence
Josh Mandel’s page:
https://joshuamandel.com/cms-rfi-collab/?singlePane=true#req_self_service_ehi_request
Some thoughts collected:
Support use of LOI and LRI and reated vocabulary IG for lab data exchange
FINAL SUBMISSION LETTER:
Proposed question(s) to respond to:
NOTE: New text (not copied from the USCDI Draft-V6 Feedback) is italizied:
3. Technical Standards and Certification
TD-7. To what degree has USCDI improved interoperability and exchange and what are its limitations?
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 with 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. In addition the HIT certification program must support all partners of the targeted data exchange in order to promote interoperability (in the case of lab data many laboratories are not covered by HIT certification requirements, which means the data producer’s system does not provide interoperable data the receiver cannot be compliant either).
a. Does it contain the full extent of data elements you need?
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.
Specifically:
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 it is essential being able to include the device identifier - specifically, we previously had requested inclusion of USCDI Data Element Test Kit Unique Identifier and USCDI Data Element Instrument Unique Indentifier). These identifiers are which is critical for reconcilliation for effective data reconciliation and artifacts deduplication, particularly for example as part in the context of clinical trials, in patient charts for laboratory results from different institutions, and for the creation of Real World Evidence (RWE). Without sufficient adequate details about the test(s) performed test, EHR-systems cannot may struggle to safely ingest and display data, utilize in chart views, which may impact could adversly affect patient outcomes. Given that laboratory data occupies comprise 90% of clinical records and laboratory results support 80% of diagnosis we strongly. Here we reiterate the our requests for the inclusion of the to include USCDI Data Element Test Kit Unique Identifier and the USCDI Data Element Instrument Unique Identifier in USCDIv6.
In support of seamless UDI exchange, it is 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.
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.
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 Laboratory Compendium (CLIA requirement) compared to the CLIA defintion of what the test request needs to include (https://www.ecfr.gov/current/title-42/section-493.1241 ).
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.
Performance Time (under Procedure):
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:
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.
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.
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.
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.
SHIELD suggests use of UCUM for unit in of 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).
b. If not, is it because of limitations in the definition of the USCDI format or the way it is utilized?
SHIELD requests more detailed definitions of the USCDI elements, specifically a link to desired data model representation, applicable datatype(s) and where applicable a more constrained terminology binding, as the more undefined elements leave too much room for interpretation, resulting in different implementations by vendors and standards developers (for example in different HL7 products), reducing the usefulness for interoperability.
In the laboratory class, the best example is Values/Results, which is currently defined as: “Documented findings of a tested specimen including structured and unstructured components.” with the Applicable Vocabulary Standard(s) identified as SNOMED Clinical Terms (SNOMED CT®) U.S. Edition, September 2024 Release.
Values/Results can have different scales and depending on the scale use of other data elements called out separately in USCDI are needed, like Result Unit of Measure for quantitative results; use of SNOMED CT is only applicable to coded qualitative results, but depending on the scale, different hierarchies should be used (ordinal from the qualifier hierarchy and nominal from the organism and potentially also the clinical finding hierarchy). Comments with suggested updates to the definition have been submitted previously on this data element.
SHIELD acknowledges, that that might require more maintenance to keep the data element updated when models change, more appropriate datatypes become available or valueset content needs to change. SHIELD acknowledges that maintaining data elements may require additional effort to keep them updated when models change, when more suitable data types become available, or when value set content needs to be revised.
SHIELD would welcome a better explanation about the relationship between USCDI and USCDI+ content, if the intent of USCDI+ is to further clarify data element defintions for specific use cases, then potentially the more detailed definitions could be applied there to allow for a more granular titration of HIT certification criteria.
c. If so, would adding more data elements to USCDI add value or create scoping challenges? How could such challenges be addressed?
As mentioned under TD7.a SHIELD believes that several core elements are still missing from the Laboratory data class and others are not linked from that class, making it potentially hard to find for some implementers. Grouping of data elements into classes appropriate for specific use cases might alleviate scope challenges for HIT certification by providing “HIT cetification swimlanes” for specific use cases, where certifying HIT could declare which use cases they support, avoiding scoping challenges.
4. Data Exchange
TD-12. Should CMS endorse non-CMS data sources and networks, and if so, what criteria or metrics should CMS consider?
b. What are the primary tradeoffs between USCDI and full EHI, especially given more flexible data processing capabilities today?