Design Considerations

We began developing this guide with a user-centered design process to better understand the needs of participating practices and the registry. Along the way we developed the following guiding principles.

Better, not perfect

The present state of practice-to-registry exchange of laboratory data has many unstandardized aspects. For example, not only is the exchange syntax idiosyncratic by practice, but most laboratory tests are not reported with codes at all. Just test names. Our goal is to move as far towards semantic interoperability as possible, but the effort to standardize every last detail is extensive. And there are diminishing returns.

In moving from essentially no standards-based exchange to using FHIR, we therefore prioritized a limited set of laboratory tests for focus. And we focused on the highest priority aspects within the Observation structure for communicating those test results. For our use case, standard codes for identifying the laboratory test and its units of measure are the most important.

Everything else is just a bonus.


This guide currently serves as the technical basis for two pilot tests of standardized laboratory data exchange. Our long range goal is for this guide to mature into a balloted standard. We appreciate the value of incrementally improving it based on the findings of real-world pilot testing. For that reason, we are focused on approaches that speed us to pilot experience with our committed sites.

We will accept trade-offs of "better" solutions for "implementable" solutions in our current context. We will continue to make refinements as we learn from real-world exchange, testing, and evaluation.

Terminology bindings for key semantics


We are relying on the widely adopted, no-cost LOINC standard as the vocabulary for identifying laboratory tests. For each type of laboratory test in our core subset, there are several possible LOINC terms that vary by certain attributes.

For example, measures of the same analyte can distinguish different kinds of quantities (e.g. mass concentration versus substance concentration), which is represented in LOINC by terms with different Properties. Likewise, LOINC has different terms to represent measures on different kinds of specimens (e.g. blood, serum, CSF).

Because the appropriate LOINC term for each test type varies by how the test is performed at a particular laboratory, we have constructed FHIR ValueSets that define relevant collections of LOINC terms for each test type. Laboratories should use the LOINC term most appropriate for their testing and reporting methodology.

There is a growing interest by in vitro diagnostic (IVD) testing companies to identify the LOINC terms that are appropriate for their device's measures. The emerging LIVD specification is the consensus format for publishing such mappings. Typically, vendors publish these mappings on their customer website, and at present, they are available for only a small subset of IVD tests. However, through a collaboration of many stakeholders known as the SHIELD initiative, all of the mappings for SARS-CoV-2 tests that have been granted emergency use authorization by the FDA have been published by the CDC. Because this resource is updated frequently, we have not incorporated it into our guide and users are encouraged to reference the latest version from CDC.

LIVD was originally published as a specification that could be represented in spreadsheet format (which is what most vendors and the CDC have been working with). Ongoing development of the LIVD specification has transitioned to FHIR and is now being managed through HL7 as the LOINC – IVD Test Code (LIVD) Mapping specification.


We are also relying on the widely adopted, no-cost UCUM standard as the vocabulary for units of measure. UCUM does not enumerate every possible unit of measure, but rather defines a system of base units and a syntax for expressing computable, semantically precise, valid units. You can consider UCUM more of a grammar than a code list.

LOINC does not create different terms for every different unit of measure. Rather, it distinguishes terms by Kind of Property that correspond to certain types of appropriate units. For example, terms with a Property of Mass Concentration could be represented by any unit corresponding to a mass per volume, such as mg/dL or g/L.

Therefore, we cannot explicitly say which UCUM expression must be used for a particular LOINC term. Our approach (following from our pragmatic principle) is to assemble FHIR ValueSets of example UCUM units for each type of laboratory test in our core subset.


We cast a broad net to review and build on existing work. Yet for practical reasons, our intent is to keep explicit dependencies to a minimum so as to maximize reusability.

Because of the regulatory context and target deployment for the pilot using commercial EHR software, we chose to make our sole dependency on the HL7 FHIR® US Core Implementation Guide specification.

Profile parsimony

Our goal in this effort is to boost the semantic interoperability of laboratory data exchange. We had originally thought we might create specific FHIR profiles with constraints specific to each LOINC term (or perhaps per test type). This would give a high fidelity of semantic specification. However, this pattern sets the stage for a huge explosion of profiles.

In our pilot context, we did not see a path to getting vendor support for a large new library of profiles.

Instead, we are relying on a single primary base profile: US Core Laboratory Result Observation Profile and adding the minimum necessary constraints to it.

We are publishing the collection of FHIR ValueSets to gather and organize appropriate standard terminologies. These ValueSets can be used together with the profile on Observation to achieve greater semantic interoperability.

Even if you are not using FHIR, these ValueSets may be of use in identifying appropriate LOINC terms.

Bulk data availability

The FHIR Bulk Data Access Implementation Guide represents a significant advance in support of exchanging health data about populations (or cohorts) of individuals. We are encouraged by the provisions in the ONC 21st Century Cures Act Final Rule and the Reducing Provider and Patient Burden and Promoting Patients' Electronic Access to Health Information NPRM from CMS that require support for the FHIR Bulk Data Access specification.

The FHIR Bulk Data Access specification would be a good fit for our practice to registry workflow. Typically, registries query for (or are pushed) regular updates for all eligible patients.

However, vendor support for Bulk Data Access will not be available in time for our pilot implementation, and therefore we must come up with an alternative approach. In the long run, we anticipate updating this guide to incorporate its use.

Alternatives to bulk data

Absent support for Bulk Data Access, our approach relies on the Requestor actor (registry) to receive list of patients for whom new data is available. The Requestor actor then iterates through each patient to request and receive their data one at a time.

The process by which the Requestor receives the list of relevant patients is under development

Given that we are approximating the bulk data approach via multiple per-patient calls, there are two important corollaries.

First, the Requestor and Responder systems will need adjustments to align on performance expectations.

Second, the Requestor will likely need to accommodate paged results from the responder. Returning paged results helps minimize load across clients, servers, and the network. In a RESTful search, the page links are contained in the returned FHIR Bundle as links.

Testing with synthetic data via Synthea

We are using a two-part pilot testing approach using both real-world clinical (production) and publicly available tools to produce synthetic data for validation. Conducting one pilot exchange test in a simulated EHR environment using open-source tools is not only cost-effective, but also enhances the reproducibility and scalability of the developed solution.

To populate our simulated EHR, we are leverage the open-source Synthea software that simulates the lifespans of synthetic patients. Synthea generates fake, but realistic patient data that can be exported into FHIR resources (with configurable conformance to the U.S. Core FHIR profiles). Because of its unique approach and licensing, the synthetic data produced by Synthea are free of legal, privacy, security, and intellectual property restrictions. No actual patient data or protected health information will be stored on the Simulated EHR.

Synthea generates its synthetic patient records using models of disease progression and corresponding standards of care. The disease and treatment modules are also open source and modifiable. For this project, we are using and extending Synthea’s core modules for colorectal, lung, breast, and prostate cancer as well as COVID-19. We have modified these modules to include the set of laboratory tests included in our core set, which will be represented with pre-harmonized LOINC codes and test results in accordance with our IG.

This Implemention Guide contains an example of a conformant Observation for each Lab Test Type. See Synthetic Data for Testing.

The example Observation resources included in this guide were extracted from the large set of synthetic data used in testing and development.