2026-06-23 Vocab WG Meeting Notes

Attendees:

Julia Skapik

Andrea Pitkus

Daniel Rutz

Hafeza, Eza

Pamela Banning

Stan Huff

Zha Li

Xavier Gansel

Agenda:

• Find time for recurring call

• Review topics to discuss

Notes:

• LEAP grant includes a lap interoperability gaps area

  • Area 3: Assess laboratory interoperability gaps to improve the adoption and use of standard terminology among small, independent laboratories.

  • Could work to create a team of independent laboratories to apply for the grant with or through SHIELD

• What is an order?

  • LIS teams point out that the definition of orders is not standard – could be 10 different ways on the LIS side to think about “orders”

  • CMS/HHS has a concept of “orders” on the clinical side as well

    • Metadata doesn’t really group into this definition

    • Such as patient, provider, diagnosis etc

    • The way USCDI has it is to just specify “use LOINC for the LOINC orders”

      • See https://isp.healthit.gov/taxonomy/term/7912/draft-uscdi-v7 Also comments on different order definitions (full order with HHS requirements versus just the lab test order name and associated LOINC mapping). Andrea also describes 4 types of order patterns (structurally) from single orderable resultable, panel, reflex, and exploding panel/1 click convenience orders.

    • HL7 FHIR requires use of a codeable concept

      • When codeable concept is used, it supports a code and its name from a code system (.e.g LOINC code and LOINC Long Common Name)

    • Labcorp noted that some labs use only the code system name-- but this is not sufficient even for the regulatory minimum

    • CLIA order requirements

      • Note CLIA uses “test request” for the order requisition (full order), and “The test(s) to be performed” in 4) for the test order name.

      • The latter item is where we asked CLIA if it can be represented by a code alone and the response was no. The name of the test to be performed (or performed for the result) is required.

      • Riki and Andrea submitted ballot comments for US Core FHIR v8 to make the test name (separate from the code system name for the code) as a must support item. It passed for both orders and results after much push back. Dr. Rob McClure was on the call advocating for it too as he recognized it is also needed to know if a mapping to a code system if accurate or not.

  • LOINC Lab Committee is working on definitions of “orders” and “panels”

    • Using the lab test name is often what’s required as well but this may not be enough detail-- the lab will know what name is what test but others may not

    • EHRs have been built to provider requests and naming provisions of providers

      • EHR or LIS will provide a starter set but people will change the view locally and map it

      • It does not match the lab name necessarily

      • Then lab will translate that to one of their tests

      • The HL7 message renaming gets lost

      • SHIELD paper shows some of this disconnect

    • The very first standard about local names says to send local code and structured one

  • Standardization is clearly of value here but there is too much local control

    • Advanced test groupings like “DMARD or Accutane surveillance”, “Immunodeficiency Panel”, “Code 99 Panel” make this even more complicated

    • What we need is a mapping decision tree

    • Sometimes it's physician request too to have a certain test (also business decisions).  Why did COVID tests get added in 2020? (I think we know the answer).   I agree for many of the national tests routinely ordered, we should try to have standardization and reduce the variability.  One of our goals with the SHIELD top tests is to propose a single standardized name and ask LIS/EHR builds where used to use the same naming convention nationally.  That would help.  We need clinicians to want to adopt though.  That is a hard nut to crack.

  • Labcorp and Epic Expand Collaboration to Advance Diagnostic Integration across Hospitals and Health …

    • For the Epic/LabCorp initiative, curious if a single name will be used nationally for the same test, thus changing from each site determined naming conventions/builds.  If so, this would be a good approach in reducing variability in naming.  

• There's also a recent bill introduced called the Enhancing CLIA Act of 2026 (to address other items, not what we are discussing):  https://www.congress.gov/bill/119th-congress/house-bill/8890/text

   

  The issue is recent FHIR ballots/R6 is using order names in FHIR Diagnostic Report whereby the CBC order name would be in FHIR Observation in FHIR Diagnostic Report.  So order names are used in observations.  Some FHIR leaders like Lloyd believe that lab panel order names are not orders only too

• Sentinel Journal articles with examples

  • Variation in Laboratory Test Naming Conventions in EHRs Within and Between Hospitals: A Nationwide Longitudinal Study

    • Abstract
      Background: Electronic health records provide clinically rich data for research and quality improvement work. However, the data are often unstructured text, may be inconsistently recorded and extracted into centralized databases, making them difficult to use for research.

      Objectives: We sought to quantify the variation in how key laboratory measures are recorded in the Department of Veterans Affairs (VA) Corporate Data Warehouse (CDW) across hospitals and over time. We included 6 laboratory tests commonly drawn within the first 24 hours of hospital admission (albumin, bilirubin, creatinine, hemoglobin, sodium, white blood cell count) from fiscal years 2005-2015.

      Results: We assessed laboratory test capture for 5,454,411 acute hospital admissions at 121 sites across the VA. The mapping of standardized laboratory nomenclature (Logical Observation Identifiers Names and Codes, LOINCs) to test results in CDW varied within hospital by laboratory test. The relationship between LOINCs and laboratory test names improved over time; by FY2015, 109 (95.6%) hospitals had >90% of the 6 laboratory tests mapped to an appropriate LOINC. All fields used to classify test results are provided in an Appendix (Supplemental Digital Content 1, http://links.lww.com/MLR/B635).

      Conclusions: The use of electronic health record data for research requires assessing data consistency and quality. Using laboratory test results requires the use of both unstructured text fields and the identification of appropriate LOINCs. When using data from multiple facilities, the results should be carefully examined by facility and over time to maximize the capture of data fields.

    • Supplement Data shows naming conventions for the each test across the VA. It appears they don’t have the same naming convention across their sites. http://links.lww.com/MLR/B635

    • Also note that the VA historically had CLIC accreditation requirements, which paralleled CLIA, but developed for these government facilities. More recently facilities can meet CLIA and accreditation requirements used across non VA laboratories.

  • Decoding laboratory test names: a major challenge to appropriate patient care

    • Abstract
      Clinical laboratory tests have no value if clinicians cannot quickly order and obtain the results they need. We found that efforts to obtain even the most commonly ordered tests are often derailed by excessively complex nomenclature. Ordering the right laboratory tests is critical to diagnosis and treatment, but existing mechanisms for entering lab orders actively interfere with physicians' efforts to provide good clinical care. Rather than simplifying lab orders, the advent of computerized physician order entry (CPOE) systems-generally programmed by non-clinicians-has introduced new and vexing practical problems. Medical laboratories have filled their test menus, whether paper or electronic, with bewildering nomenclature and abbreviations, and have failed to appreciate the dangers of assigning perilously similar names to different tests. The efficient and efficacious patient care demanded by the quality care initiative requires progress beyond traditional solutions, such as convening naming conventions, to the development of innovative software with intelligent, real-time, clinically driven search functions that will allow these programs to help rather than hinder physicians.

    • See image below of different naming conventions for A1C.

    • 

• Next Steps

  • Work on the list of common lab names from the Steering Committee?

    • Need short names for performing lab tests?

    • Would want to map LOINC codes to them

    • 
      

LEAP Proposal Scope

Area 3: Assess laboratory interoperability gaps to improve the adoption and use of standard terminology among small, independent laboratories
Goal
The goals of this area of interest are to assess laboratory data quality and implement existing solutions aimed at improving the adoption and use of standard codes such as Logical Observation Identifiers Names and Codes (LOINC), SNOMED Clinical Terms (SNOMED CT), and Unified Codes for Units of Measure (UCUM) among small, independent laboratories. Projects should assess laboratory data quality and use that information to identify and pilot test different solutions (such as mapping tools) to facilitate the use of correct codes in laboratory data and to transition small, independent laboratories from using local laboratory codes to using standardized terminologies. Projects should focus on solutions that support conformance with national laboratory standards and can be widely implemented by small, independent laboratories.
Background
Quality of laboratory data
Laboratory data are a critical piece of information that informs clinical decisions, public health surveillance, research, and population health, among other activities. As noted in the Congressional Report on Standards for Electronic Ordering and Reporting of Laboratory Test Results, robust use of
Page 11 of 60
laboratory standards is necessary to enable a common meaning or interpretation of laboratory tests and results between laboratories, providers, public health entities, and other users of these data.
4
Despite the importance of using standard terminologies to ensure a common understanding, available assessment data suggest that the use of these standards for laboratory data varies widely – both by standard type and across entities – with smaller laboratories and providers less likely to use standard terminologies. Laboratories’ persistent use of locally defined names, terms, and codes instead of standardized vocabularies hinders data exchange. Due to limited resources, many laboratories and health systems continue to rely on internal codes developed to meet local workflow requirements, legacy system constraints, and historical reporting needs. These locally defined codes lack consistent meaning when shared outside of their originating systems, requiring receiving systems to manually map or interpret data. This increases the risk of fragmented patient data, delays, and misinterpretation of results, and adds operational burden—factors that can negatively impact patient safety, clinical decision-making, public health, and other secondary uses of data. Laboratories may select LOINC codes that do not align with the tests performed, resulting in data quality issues that can also impact patient safety. Additionally, laboratories may incorrectly map their test catalog.
Newly developed data quality tools are available to help smaller laboratories assess whether they are over-relying on local codes or using incorrect LOINC codes when reporting data to providers and health information organizations. Existing mapping tools are available to help laboratories align their test catalog with nationally recognized laboratory coding standards, such as LOINC, SNOMED CT, and UCUM, to support and enable accurate and efficient data exchange.
Tools to Assess and Improve Data Quality
Assessing electronic health record (EHR) data quality involves consideration across several dimensions, including conformance to standards.567 ONC has been unable to specifically measure the quality of laboratory data in terms of conformance to nationally recognized standards. Surveys have not proven to be a reliable measurement approach due to low response rates and lack of awareness of terminologies among respondents.
Data quality assessment tools that leverage real-world data offer promising new approaches to assess conformance to national laboratory standards. Recent analysis of laboratory data from laboratories and health care providers demonstrated it was possible to use real-world data to generate insights on the use of laboratory standards; however, that analysis involved using a customized tool and data from a small number of organizations.8 Researchers can now analyze real-world data using open-source tools that do not require customization and can be used by a broad array of organizations. Tools such as CumulusQ, which received LEAP funding in 2023 and 2020, operationalize data quality measurement by evaluating
4 Report to Congress: Standards for Electronic Ordering and Reporting of Laboratory Test Results. December,19, 2024. https://www.govinfo.gov/content/pkg/CMR-HE1-00196380/pdf/CMR-HE1-00196380.pdf
5Lewis AE, Weiskopf N, Abrams ZB, Foraker R, Lai AM, Payne PRO, Gupta A. Electronic health record data quality assessment and tools: a systematic review. J Am Med Inform Assoc. 2023 Sep 25;30(10):1730-1740. doi: 10.1093/jamia/ocad120. PMID: 37390812; PMCID: PMC10531113.
6 Weiskopf NG, Weng C. Methods and dimensions of electronic health record data quality assessment: enabling reuse for clinical research. J Am Med Inform Assoc. 2013;20(1):144-51.
7 Kahn MG, Callahan TJ, Barnard J, Bauck AE, Brown J, et.al. A Harmonized Data Quality Assessment Terminology and Framework for the Secondary Use of Electronic Health Record Data. EGEMS (Wash DC). 2016 Sep 11;4(1):1244.
8 Report to Congress: Standards for Electronic Ordering and Reporting of Laboratory Test Results. December 19, 2024. https://www.govinfo.gov/content/pkg/CMR-HE1-00196380/pdf/CMR-HE1-00196380.pdf
Page 12 of 60
how EHR data align with interoperability standards encoded in the United States Core Data for Interoperability (USCDI). USCDI serves as a baseline set of data elements for health information exchange and interoperable health IT implementation. USCDI includes laboratory data, with specifications for the use of code systems such as LOINC, to encode these data. These standards-driven approaches, meaning approaches that assess or analyze data against established interoperability standards such as USCDI and LOINC, enable identification of structural and semantic errors, as well as potential approaches to resolve and correct errors.
Data quality tools can evaluate laboratory data to identify instances where data do not conform to nationally recognized standards or rely on using local codes. Determining the types of laboratory tests in laboratory data that are most frequently identified by local codes rather than by national standards is a critical first step towards improving the quality of laboratory data. Identifying commonly performed laboratory tests for which providers select the incorrect LOINC codes in their EHR system is also important to improving the quality of laboratory data. LOINC Regenstrief has a list of the LOINC codes most commonly used in laboratory data exchange.
Tools to Shift away from the Use of Local Codes
Once small, independent laboratories identify laboratory tests using local codes, they can take additional steps to ensure that the correct codes from those national standards are used instead. Those steps include focusing directly on reducing the use of local codes by laboratories. Resources are available from LOINC Regenstrief to enable laboratory staff to map local codes to LOINC codes. Examples of these resources include the Regenstrief LOINC Mapping Assistant (RELMA), a mapping utility to search the LOINC database and map local codes to LOINC codes, and SearchLOINC, a web-based tool to search the LOINC database. LOINC Mapping Guides, summaries of best practices for mapping to LOINC across six laboratory domains, are also available. Laboratory information systems may also have their own mapping tools.
Other solutions to shift away from the use of local codes focus on addressing these issues further upstream. One such solution is embedding LOINC codes in the in-vitro-diagnostic (IVD) devices used to test samples outside the body for diagnosing diseases, monitoring health, or guiding treatment. LOINC to In-Vitro-Diagnostic (LIVD) mapping specifications for IVD devices harmonize how IVD test information is represented using laboratory data standards. LIVD describes the same laboratory test across vendors and laboratories. The LIVD specification has been advanced through the efforts of Systemic Harmonization and Interoperability Enhancement for Laboratory Data (SHIELD), a public-private multi-stakeholder driven endeavor sponsored by the FDA that seeks to build solutions that address interoperability of IVD devices. The SHIELD initiative has developed a small number of LIVD files that provide a definitive source for LOINC to IVD test mapping and has published a white paper on Laboratory Interoperability Data Repository (LIDR), a potential solution for a repository of LIVD files. Other open-source tools such as Komet also support this goal.
Paired with data quality assessment tools that identify data that does not conform to national standards or that does not accurately use standardized code systems (e.g., LOINC), these mapping tools for laboratories and IVD manufacturers have the potential to improve the quality of laboratory data so that it aligns with national standards.
Key Objectives
There are eight objectives in this area of interest for the two-year period of performance:
Page 13 of 60

1. Identify at least three small, independent laboratories to participate in pilot activities that will improve the adoption and use of standard terminologies and support conformance with LOINC for laboratory test identifiers; SNOMED CT for results, organisms, methods and conditions; and UCUM for units of measurement; and align with applicable USCDI data elements.

2. Conduct a readiness assessment for each participating laboratory to:
   a. Understand if the laboratory’s staff are prepared to change their laboratory coding processes,
   b. Understand if the laboratory’s IT system is capable of adopting new laboratory coding processes,
   c. Identify risks and challenges the laboratory will face in adopting new laboratory coding processes,
   d. Identify laboratory coding processes needing improvement,
   e. Identify how changes and success will be measured,
   f. Identify the most appropriate tools for data quality assessment and mapping, and
   g. Identify any other topics the applicant determines to be necessary.

3. After the readiness assessment, pilot test at each participating small independent laboratory at least one open-source data quality tool to identify laboratory tests that the laboratory staff has frequently incorrectly coded or coded using local codes rather than standardized terminologies. Once laboratory tests that are incorrectly coded or coded with local codes are identified, determine the root causes of incorrect and local code use.

4. Once the tests that are most frequently incorrectly coded or coded using local codes rather than standardized terminologies are identified, pilot test at each participating laboratory, two or more tools to improve the use of standardized terminology. Existing tools are available through LOINC Regenstrief and from the SHIELD community (such as RELMA, SearchLOINC, LOINC Hierarchy Browser, LOINC Mapping Guides, laboratory information system mapping tools, and existing LIVD specifications). The applicant may use these tools or other open-source tools to transform the incorrect or local codes into standard codes to increase the usage of standard codes at each participating laboratory.

5. Describe in a report the results of the readiness assessments and root cause analyses, and lessons learned from the pilot testing of tools that measure the quality of laboratory data and tools that support the use of standard terminologies on a broad scale. Also describe in the report how the tools used can improve consistent adoption and use of nationally recognized laboratory standard codes. Based upon the lessons learned, the report should include specific recommendations to update and improve existing tools to better support use by small, independent laboratories.
   Lessons learned should include at a minimum:
   o Identification of instances where existing tools or approaches were not effective in addressing laboratory interoperability or standardized code adoption challenges.
   o Analysis of the underlying reasons why laboratories continue to rely on local codes or use incorrect standardized codes including technical, operational, workflow, cost, or resource-related factors.
   o Assessment of whether and how the solutions address (or fail to address) these underlying drivers, and the implications for adoption and sustained use by small, independent laboratories.
   o Identification of gaps or unmet needs that limit the effectiveness or uptake of existing tools and solutions.
   Page 14 of 60
   o Recommendations for new or enhanced tools, approaches, or capabilities that could better address identified gaps, reduce reliance on local codes, improve the selection of accurate standardized codes, and support broad adoption of standardized laboratory codes.

6. Develop a dissemination plan that includes a public-facing version of the report described in Objective 5 and at least one educational workshop or webinar to share results from the readiness assessments and root cause analyses, lessons learned, and to explain how laboratories can adopt standardized laboratory codes with data quality and laboratory stakeholders.

7. All tools used and any developed processes or suggestions for adopting standardized laboratory codes should be interoperable with third-party client applications developed by unaffiliated organizations to support mapping, validation, and assessment of laboratory standard code usage. All tools should also be use-case agnostic and support laboratory interoperability by enabling consistent use, validation, and assessment of standardized laboratory codes. Applicants should rely on non-proprietary approaches and propose solutions that are independently implementable and applicable across multiple laboratory data elements, using a technical approach to support diverse laboratory and data quality use cases.

8. Applicants shall include a technical expert panel of key laboratory and health IT stakeholders who will be directly involved in the project, such as laboratory information system (LIS) vendors, leadership from small and independent laboratories, developers of third-party laboratory data quality or terminology tools, public health partners, and members of the laboratory and health IT standards communities. Applicants should include letters of commitment from proposed members of the coalition of key laboratory and health IT stakeholders.
   Applicants for an award in this area of interest shall include the following in their application:
   • Describe in detail the technical barriers that impede laboratory interoperability, including challenges related to the adoption and use of standardized laboratory codes, data quality, conformance to national laboratory standards, and integration with third-party applications.
   • Describe in detail technical solutions to the barriers, including:
   o Sufficient technical details to demonstrate that the proposed solution is based on non-proprietary technologies and leverages open-source tools.
   o A detailed plan on how the applicant plans to conduct the readiness assessment for using data quality and mapping tools (Objective 2).
   o A detailed plan on how the applicant intends to complete the pilot tests described in Objective 3 and Objective 4.
   o How the proposed project will inform future improvements to technical infrastructure supporting laboratory interoperability and standards-based laboratory data exchange.
   • Identify an approach to improve the exchange and use of standardized laboratory data while adhering to applicable data security and privacy requirements, including compliance with the HIPAA Privacy Rule9 and other relevant regulations.
   Performance Goals and Objectives
   A performance goal is a target level of performance expressed as a tangible, measurable objective, against which actual achievement can be compared.
   9 Standards for Privacy of Individually Identifiable Health Information, 45 C.F.R. pts. 160 & 164 (2000)
   Page 15 of 60
   ONC will utilize the following objectives to assess project performance and progress:
   • The quality of the two-year project plan and the description of how performance goals and key objectives will be met.
   • The identification and securement of subject matter experts (SMEs), as appropriate, to provide guidance and review strategies, research methods, and results.
   • Scheduling, conducting, and participating in status, strategy and/or SME meetings with ONC and the panel of key stakeholders.
   • Communicating findings and providing quarterly programmatic progress reports, including a risk mitigation plan to ensure timely deliverables.