LOINC Terms and SNOMED CT Observable Entities

LOINC Terms are primarily represented within the Observable Entity hierarchy of SNOMED CT for several reasons. Firstly, LOINC terms predominantly capture observable clinical phenomena, such as laboratory test results, measurements, observations, and assessments, which align closely with the scope of observable entities in SNOMED CT. This conceptual alignment ensures that many LOINC terms fit naturally within SNOMED CT’s structure, facilitating their integration into the broader clinical terminology framework. Additionally, LOINC terms often require a detailed representation of properties, scales, units, methods, and other attributes associated with clinical observations.

However, it is important to note that certain areas of LOINC, such as document-related terms or results of observations, may be more appropriately represented in other SNOMED CT hierarchies.

SNOMED CT’s structured framework supports this flexible approach, enabling precise representation of LOINC concepts and ensuring that all relevant attributes are accurately documented.

LOINC Parts as SNOMED CT Attribute Values

LOINC Parts are represented as SNOMED CT attribute values to enable the definition of LOINC Terms using SNOMED CT's logical foundation while retaining the meaning represented in LOINC. This approach ensures a granular representation of defining attributes like properties, scales, methods, components, and systems, facilitating precise documentation of clinical concepts. Additionally, leveraging SNOMED CT's semantic framework maintains consistency, accurately associating each component with the appropriate context and contributing to standardized clinical information representation.

To express LOINC terms as SNOMED CT concepts, a structured process was established. This ensures efficient development efforts resulting in content with a high level of consistency and accuracy throughout.

Here's a breakdown of the process and its objectives:

1. Utilizing latest LOINC Parts: The process begins by utilizing the latest list of LOINC Parts.

2. Mapping LOINC Parts: LOINC Terms are modeled based on various LOINC Parts, with specific instructions provided for each property type.

3. Assigning Attributes: Attributes necessary for modeling LOINC Terms are determined based on the LOINC Property type. Templates are provided for different scenarios, such as observable with component, observable with component and relative to, observable with inheres in, and susceptibility observable. These templates and their criteria for selection are described in the sub-pages listed below.

The following pages describe the applied templates and provide examples.

The driving philosophy of the SNOMED LOINC Extension is to faithfully translate LOINC content into a SNOMED CT representation without adding, removing or modifying any term, and without the need for additional manual intervention. However, there are a small number of additional SNOMED CT concepts that were required in order to make the transition from a LOINC structure to a SNOMED one:

LOINC groupers are included in the LOINC Ontology to allow more general test ordering, and also to support navigation and querying by enabling identification of related tests that share the same property, system, and component.

Grouper concepts are modeled using a subset of defining attributes, typically Property, System, and Component. Attributes such as time and scale are intentionally not included. This approach ensures that more specific observables, which differ by time (for example, point in time or 24 hours) or scale (for example, quantitative or ordinal), are subsumed under a common parent concept.

Example

The concept 711861010000108 | Measurement of calcium in urine (observable entity) |

is defined using the following three attribute-value pairs:

• 370130000 |Property (attribute)| = 685451010000100 |Measurement property (qualifier value)|

• 704327008 |Direct site (attribute)| = 122575003 |Urine specimen (specimen)|

• 246093002 |Component (attribute)| = 5540006 |Calcium (substance)|

The concept does not contain the time or scale attribute. As a result, all observables representing measurements of calcium in urine are classified under this concept, regardless of differences in timing or scale.

As shown in the image above, this modeling allows all the specific tests of urine calcium levels to be subsumed by this concept.

This template is employed when the LOINC term involves an observation that is specified with a system, but not a component

This template is documented in Confluence here: Quality observable with Inheres in (System, no Component) for LOINC (observable entity) - v1.0

The java implementation of this template can be found here.

Attributes

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

• LOINC Scale: Describes the scale type, like quantitative or qualitative.

• LOINC Time: Indicates the time aspect of the observation, e.g., single point in time.

• LOINC System: Specifies the direct site of the observation.

• LOINC Method: Describes the technique used for the observation.

Template slots are filled by taking the preferred term of the relevant value from the model and making the initial character lower case, if allowed by the case significance setting of the preferred term.

[PROPERTY] of [SYSTEM] at [TIME] by [METHOD] using [DEVICE] [CHALLENGE]

Some slots are optional, and are then tidied up along with any linking words (eg 'using')

The LOINC Long Common Name is specified as the Preferred Term and the LOINC Short Common Name is also included unchanged as an acceptable synonym. Finally a terse form of the LOINC Parts is added, with all part names specified, separated by colons.

In the case of the example below, this results in the following terms:

This chapter defines the model meaning binding and value set binding between data elements in the Logical Model and their corresponding SNOMED CT concepts and value sets. These bindings ensure precise alignment between the Logical Model and SNOMED CT, supporting consistent and interoperable representation of laboratory orders, specimens, and results.

Laboratory Order

The laboratory orders represent the request that starts the laboratory process. In the context of this implementation guide for the LOINC Ontology, the recommendation is to use Observable entities for this purpose, selected from a subset that is marked as "Orderable" entities by LOINC.

SNOMED CT includes a hierarchy of specimens and is used to define observable entities in the LOINC Ontology. The specimens used in the LOINC Ontology can be extracted using the SNOMED CT Expression Constraint Language by selecting concepts used as values for the 704327008 |Direct site (attribute)| or 704319004 |Inheres in (attribute)| attribute within the LOINC Ontology.

In the results, the codes for tests can be different from those ordered. In cases like "panels", the order concepts are transformed into a set of observable concepts that can be reported as results. The LOINC Ontology identifies a subset of observable concepts that are valid to report as "observed" results.

This chapter explores clinical use cases that demonstrate how the LOINC Ontology, as an extension to SNOMED CT, supports standardized data exchange and interoperability. It outlines clinical workflows where the integration of LOINC and SNOMED CT enhances laboratory reporting, diagnostics, and clinical documentation. The use case scenarios illustrate how this combined terminology framework improves data consistency, decision support, and system integration in healthcare.

This chapter provides practical guidance on implementing and utilizing the LOINC Ontology in various technical environments. It covers key considerations for deployment, access methods, and integration approaches, ensuring seamless adoption within healthcare and clinical information systems.

This chapter serves as a comprehensive resource for developers, system architects, and implementers looking to leverage the LOINC Ontology effectively.

This template is utilized for LOINC terms representing susceptibility observations, such as microbial susceptibility tests.

This template is documented here: Susceptibility observable for LOINC (observable entity) - v1.0

The java implementation of this template can be found here.

Attributes

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

• LOINC Scale: Describes the scale type, like quantitative or qualitative.

• LOINC Time: Indicates the time aspect of the observation, e.g., single point in time.

• LOINC System: Specifies the direct site of the observation.

• LOINC Method: Describes the technique used for the observation.

• LOINC Component: Specifies the target organism or substance towards which the susceptibility is observed

Note the three angle brackets at the start of this concept expression, indicating that the concept is primitive.

This will be because no attribute mapping was available for the "system" part.

This is also reflected in the terms below, where the LOINC system "Isolate.meningitis" has been used directly.

Template slots are filled by taking the preferred term of the relevant value from the model and making the initial character lower case, if allowed by the case significance setting of the preferred term.

Some slots are optional, and are then tidied up along with any linking words (eg 'using')

The LOINC Long Common Name is specified as the Preferred Term and the LOINC Short Common Name is also included unchanged as an acceptable synonym. Finally a terse form of the LOINC Parts is added, with all part names specified, separated by colons.

In the case of the example below, this results in the following terms:

LOINC Term

More than an Equivalent Map

When a concept in one system can be considered equivalent to some other concept in another code system, we can express that in a mapping between those two code systems. However, in the case of the SNOMED LOINC Extension we are not saying that two separate concepts can be considered equivalent; we are instead stating that the SNOMED CT concept is exactly the same entity as the LOINC concept that it is expressing. The SNOMED CT concept is an alternative representation of the LOINC concept, and can be considered to have two identifiers - a SNOMED CT SCTID and a LOINC code - which could theoretically be used interchangeably; software challenges notwithstanding.

The LOINC identifier in this case is called an Alternate Identifier in the SNOMED CT LOINC Extension. This is an RF2 file that specifies the LOINC identifier for each LOINC Term that has been expressed in a SNOMED CT format, along with the SCTID which has been assigned. The two identifiers are considered to be of equal standing and are displayed, for example, with equal prominence in the SNOMED CT Browser.

Note that the link between the entity expressed as LOINC and expressed in a SNOMED CT format remains true even if a LOINC Term should be deprecated.

Representation in RF2

The Alternate Identifier is populated in the LOINC Extension and will be named something like Snapshot/Terminology/sct2_Identifier_Snapshot_INT_20250321.txt

The layout of the file is described in the RF2 Specification in the Identifier File Specification.

SNOMED CT identifiers are not random numbers, they follow a number of rules in their format and a well trained eye can determine a lot of information about them.

If we consider the identifier for the LOINC Extension module - 11010000107, we can split that up into 4 parts: 1 | 1010000 | 10 | 7 which take the following meanings reading from right to left:

• The number 7 here is the Verhoeff checksum digit, which will alert systems to any simple mistakes in manual entry or spreadsheet mangling of SCTIDs

• The partition identifier identifier 10 tells us firstly that the next 7 numbers will indicate a namespace identifier and secondly that this SCTID was created to be applied to a concept, rather than a description or relationship

• 1010000 is the Namespace given to the LOINC Extension. Every SNOMED component created for the LOINC project which is assigned an SCTID will contain this namespace sequence. That is bound to that component for its lifetime, so even if a concept should subsequently be promoted up to the International Edition (through some agreement between Regenstrief and SNOMED International), that identifier would remain unchanged, and its origin in the LOINC Extension would remain clear.

The LOINC Ontology is represented as an Extension to SNOMED CT, which provides a way to integrate LOINC (Logical Observation Identifiers Names and Codes) codes into SNOMED CT, enhancing interoperability between these two major terminologies in clinical and laboratory domains. The extension ensures that LOINC codes can be used as identifiers for relevant SNOMED CT concepts, allowing consistent and standardized data exchange across different healthcare systems

Overview

The diagram below how the LOINC Ontology extends the SNOMED CT International Edition, enabling the representation of LOINC-coded laboratory observations within SNOMED CT’s logical framework.

The SNOMED CT International Edition consists of core international components, structured under:

• 900000000000207008 | SNOMED CT core module (core metadata concept)|

• 900000000000012004 | SNOMED CT model component module (core metadata concept)|

The LOINC Ontology builds on SNOMED CT by incorporating Alternate Identifiers, aligning LOINC codes with SNOMED CT concepts. Its content resides within the 11010000107 | LOINC Extension module (core metadata concept) |.

Each version of the LOINC Ontology depends on a specific version of the SNOMED CT International Edition, and the LOINC Ontology cannot function independently. Any implementation of the LOINC Ontology requires the SNOMED CT International Edition for proper use.

1. SNOMED CT Extension Format:

   • The extension is published as a standard SNOMED CT extension and adheres to the format specifications outlined by SNOMED International (at and ).

   • This ensures that the extension maintains consistency with the core SNOMED CT release format and other compatible extensions.

Purpose and Scope

LOINC (Logical Observation Identifiers Names and Codes) is the international terminology standard for identifying health observations, measurements, and document types in healthcare information systems, such as electronic health records (EHRs)

LOINC provides a set of universal codes and names for laboratory and clinical observations, including measurements like blood pressure and cholesterol levels, and clinical assessments like standardized questionnaires and surveys that collect comprehensive information from patients to diagnose their health and are used to determine their appropriate treatment plan. These codes allow for interoperability between different healthcare systems, enabling seamless exchange and aggregation of health data.

LOINC Basics

• A LOINC concept is represented by a code and a corresponding name, e.g. 8480-6 Systolic blood pressure.

• LOINC codes are unique and permanent, though codes can be deprecated or discouraged and replaced by an alternate concept.

• There are over 100,000 concepts represented in LOINC, each distinguishing the given observable.

• There are two releases of LOINC each year in February and August. It is strongly recommended that the most current version of LOINC is used, and that it is implemented within 90 days of release.

• LOINC use is bound by the LOINC License. In general, LOINC codes are licensed free-for-use for all purposes except the creation of a competing code system.

The SNOMED CT Implementation Guide for the LOINC Ontology offers comprehensive guidance for implementing and using the LOINC Ontology; an extension to SNOMED CT that bridges structured clinical terminology with laboratory and observation data.

Developed collaboratively by SNOMED International and the Regenstrief Institute, the guide supports terminology implementers, system developers, and clinical informaticians in achieving interoperable, computable healthcare data. It explains the structure, purpose, and integration of LOINC into SNOMED CT, detailing how LOINC-coded observations are modeled using SNOMED CT’s concept model, attributes, and classification system.

The guide introduces the LOINC Extension and its benefits for clinical applications, such as standardized lab results, structured documentation, and improved decision support. Practical implementation strategies cover data integration, terminology binding, HL7 FHIR approaches, and system compatibility across EHRs and lab systems. It also outlines methods for accessing and maintaining the LOINC Ontology, managing version control, and aligning with SNOMED CT updates.

By adopting the LOINC Ontology within SNOMED CT-enabled systems, organizations can enhance data consistency, analytics, and clinical decision-making, creating a more standardized and interoperable healthcare ecosystem.

When working with the LOINC Ontology, it’s essential to have efficient access to the content through various systems, regardless of the technology used.

This chapter provides practical guidance on how the LOINC Ontology can be used effectively in clinical applications to support the use cases outlined in the Clinical Use Case section.

Provide Feedback

LOINC Concepts feature a number of logical properties - beyond their text descriptions and parts - that required some creative way to surface in a SNOMED CT format.

Two examples of these are the ORD/OBS flag (which indicates if a LOINC Term should be used in the context of an Order, and Observation, or Both), and a status of "Discouraged" which indicates that a LOINC Term is still active, but its use should be avoided.

Both of these flags exist as columns in the published LOINC distribution csv file and the method for exposing them in a SNOMED CT format is described in the following pages.

Represent Laboratory Results with FHIR

In the context of managing lab result data, FHIR (Fast Healthcare Interoperability Resources) offers two key resources: the Observation resource and the DiagnosticReport resource. Each plays a distinct role in representing and conveying lab results, and together they provide a comprehensive view of the lab data.

FHIR Observation

The Observation resource is used to represent the actual result of a laboratory test. It includes details such as:

• Test Results: The specific findings or measurements from the test (e.g., blood glucose levels, cholesterol levels).

• Units of Measurement: How the results are quantified (e.g., mg/dL).

• Reference Ranges: Normal value ranges for comparison.

• Observation Date and Time: When the result was recorded.

• Use: This resource focuses on the raw data from the test, providing a granular view of each result.

The DiagnosticReport resource adds additional context and information to the results presented by the Observation resource. It includes:

• Summary of Results: An aggregated view of all related observations and their interpretations.

• Clinical Interpretation: Comments or interpretations provided by the laboratory or a medical professional, which may help in understanding the results in a clinical context.

• Report Status: Indicates whether the report is final, preliminary, or in draft form.

This FHIR DiagnosticReport example below demonstrates how multiple Observation resources can be referenced within a single diagnostic report, specifically for a blood glucose test panel. It provides a structured approach to representing laboratory results using both LOINC and SNOMED CT codes.

In this example, the primary focus is on a blood glucose measurement (Observation/Obs001 exemplified above), but the report also includes other relevant tests commonly performed in diabetes assessment and metabolic health monitoring. These additional observations help provide a comprehensive clinical picture and are essential in diagnosing and managing conditions such as diabetes mellitus, insulin resistance, and cardiovascular risk factors.

Key Features of the Example

• References multiple Observation resources related to metabolic and cardiovascular health.

• Uses both LOINC and SNOMED CT codes in the code field to enhance compatibility.

• Includes SNOMED CT codes for interpretation and conclusion, making the report machine-readable and clinically relevant.

When ordering laboratory tests, FHIR provides specific resources to support this process. This page outlines the key FHIR resources involved in ordering laboratory tests, focusing on how SNOMED CT and/or LOINC can be bound to these resources to ensure standardized and accurate documentation within electronic health records (EHRs) and other clinical systems. These resources help ensure that lab test orders are transmitted, processed, and documented consistently across different healthcare systems.

The diagram below illustrates how the integration of SNOMED CT and LOINC can be utilized in laboratory test ordering and processing, using FHIR ServiceRequest to support interoperability between SNOMED CT-enabled Electronic Health Records (EHRs) and LOINC-enabled Laboratory Information Systems (LIS).

In this process, a laboratory test request is encoded using SNOMED CT within the EHR system. If needed, the corresponding LOINC code is derived using the LOINC Ontology. The request is then transmitted via FHIR ServiceRequest, containing either the SNOMED CT concept alone or both the SNOMED CT concept and its corresponding LOINC code.

On the receiving end, if only the SNOMED CT concept is provided, the LIS derives the appropriate LOINC code using the LOINC Ontology. The laboratory system then identifies and processes the request based on LOINC.

FHIR Service Request Resource

The FHIR ServiceRequest resource is used to represent a request for a service to be performed, such as laboratory tests, imaging studies, or procedures. It facilitates standardized communication between healthcare systems, ensuring that test orders and service requests are accurately transmitted and processed.

In the context of laboratory test ordering, the ServiceRequest.code element is used to specify the requested test. This field can contain either a SNOMED CT code, a LOINC code, or both, depending on how the ordering system captures and transmits test requests.

• When SNOMED CT is used, the code element holds the SNOMED CT concept representing the requested test.

• When LOINC is used, the code element contains the appropriate LOINC code that corresponds to the requested laboratory test.

• In cases where both SNOMED CT and LOINC are included, SNOMED CT provides a structured clinical representation, while LOINC ensures compatibility with laboratory systems that primarily use LOINC for test identification.

By supporting both SNOMED CT and LOINC within the ServiceRequest.code element, FHIR enables flexible and interoperable test ordering workflows, ensuring accurate and efficient exchange of laboratory test requests across healthcare systems.

More information on the FHIR Service Request Resource can be found here:

Below is an example of a FHIR ServiceRequest resource that uses both the SNOMED CT concept and the associated LOINC code 51459-6 for a request to measure the arbitrary concentration of antibodies to hepatitis E virus in serum:

• status: Set to “active,” indicating that the request is currently in progress.

• intent: “order” reflects that this is a formal request.

• code:

By leveraging the LOINC Ontology, it is possible to automatically derive the corresponding LOINC code for the SNOMED CT concept 72641010000107 |Arbitrary concentration of antibody to hepatitis E virus in serum at point in time (observable entity)|, see image below. The corresponding LOINC code is 51459-6, which represents the same clinical concept in the LOINC terminology system.

If the LOINC Ontology has been loaded in a relational database using a model that complies with the RF2 specification for tables and column names, the content can be accessed using SQL queries in line with the examples below. To Set up SNOMED CT in a relational database, please follow the guidance and instructions provided in the SQL Practical Guide.

SQL Examples

In the LOINC distribution csv file, the column "status" can indicate a number of concept states:

• ACTIVE

• TRIAL

• DISCOURAGED

• DEPRECATED

For example, has a status of 'DISCOURAGED'.

The equivalent property in SNOMED CT concepts, is the "active" flag, but this can only take a 1 or 0 value, which maps to the ACTIVE and DEPRECATED LOINC statuses respectively.

TRAIL concepts are considered available for use, and so this status is not expressed in the SNOMED CT transformation of LOINC concepts.

DISCOURAGED, however, is represented using an Annotation (starting from Release 2.0 Effective Time 20250921). These are expressed in the ComponentAnnotation file eg der2_scsRefset_ComponentAnnotationStringValueSnapshot_LO1010000_20250921.txt with the column for referencedComponentId set to the SCTID of the relevant concept, and the annotation text "Discouraged" in the value column.

In the LOINC SNOMED Browser, this annotation is represented on the "details" tab:

When working with the LOINC Ontology, leveraging a FHIR terminology server can simplify access and management. The server allows you to handle the content as a specific CodeSystem version, providing access to all FHIR Terminology operations.

The SNOMED International URI standard specifies that identify unversioned editions (i.e. editions) and versioned editions (i.e. versions) take the following respective forms:

• http://snomed.info/sct/{sctid}

LOINC Terms are expressed as SNOMED CT concepts by following a . This has been implemented as a number of Java classes, freely available in .

The processing algorithm follows these high level steps

1. The Java class loads the Loinc.csv and Part.csv file from the LOINC release

2. A part detail file is also supplied, which specifies part identifiers ("LP") for each part used in each LOINC Term

The LOINC ontology is represented as a SNOMED CT extension and is distributed as an independent package.

Each version of a SNOMED CT extension depends on a specific version of the International Edition (refer to section for more details). Therefore, deploying the LOINC ontology requires access to both the LOINC ontology release package and the corresponding International Edition release package, upon which the specific version of the LOINC ontology is dependent.

To access and use the LOINC ontology, users must have a valid Affiliate License for SNOMED CT. SNOMED CT is a globally recognized clinical terminology standard, and its usage is governed by strict licensing agreements to ensure compliance and proper utilization. Licensing ensures that users are authorized to access and implement SNOMED CT in their systems.

Individuals or organizations interested in using SNOMED CT must obtain an Affiliate License through their National Release Center (NRC) or SNOMED International.

More information can be found here:

This page outlines the key clinical scenario/workflow where SNOMED CT and the LOINC Ontology are essential for standardizing and structuring healthcare data. The workflows described are examples, and may not apply in all countries.

The integration of laboratory test data between Electronic Health Records (EHR) and Laboratory Information Systems (LIS) is crucial for ensuring efficient, accurate, and consistent patient care. To achieve this, healthcare systems leverage standardized coding systems such as SNOMED CT and LOINC. SNOMED CT provides a comprehensive clinical terminology for describing patient data, while LOINC offers a universal standard for identifying lab tests and their results.

1. Ordering Lab Tests

The LOINC Ontology developed through a collaborative initiative between the Regenstrief Institute and SNOMED International was established under a cooperative agreement signed in October 2022 which built upon previous agreements between the two organizations. This partnership aims to reduce duplication between the two terminologies and enhance their interoperability, enabling stakeholders to use LOINC and SNOMED CT together more effectively. This initiative builds on the strengths of both terminologies, aiming to streamline clinical data exchange and enhance the utility of standardized healthcare information.

A key deliverable of this collaboration is an extension that integrates LOINC’s granular laboratory observables into SNOMED CT’s framework, increasing LOINC’s computability in a SNOMED-compatible structure. By aligning these terminologies, the extension supports data harmonization, advanced analytics, and improved patient care.

More information about this project can be found at along with downloadable content and the LOINC Ontology Browser.

The overall clinical and practical objective of the LOINC Ontology and the harmonization of LOINC and SNOMED CT is to support a more interoperable, standardized, and semantically precise healthcare data ecosystem. This harmonization effort aims to bridge the gap between structured clinical terminologies and laboratory/observation data to enhance patient care, research, and data exchange across healthcare system

Determine the Appropriate Approach

The workflow below outlines key considerations for adopting the SNOMED CT Ontology for laboratory test orders and results. A thorough understanding of how lab tests are currently ordered and recorded, along with the specific benefits sought, is essential before making this decision.

The process begins by evaluating the organization’s use of LOINC or SNOMED CT and determining whether transitioning to the LOINC Ontology would improve standardization and interoperability. It then provides a structured implementation approach, including deploying terminology servers, updating terminology bindings, and managing legacy data.

By adopting the SNOMED CT Ontology, organizations can streamline terminology management, enhance data accuracy, improve analytics, and facilitate seamless data exchange. This structured approach supports informed decision-making and ensures alignment with organizational goals.

Implementation Approaches

Deploy the LOINC Ontology (including required SNOMED CT releases) in a terminology server

The first step in setting up the LOINC Ontology is to install it in a SNOMED CT-enabled terminology server. The deployment process includes loading the latest release of the LOINC Ontology including required versions of the international and/or national edition, as described in 6.3 Deploying the LOINC Ontology. Using standardized APIs like FHIR Terminology Services ensures smooth data exchange between different systems, making lab test orders and results more standardized and interoperable.

Migrate terminology bindings to LOINC Ontology with ECL vs. maintaining direct LOINC bindings

Most healthcare systems currently use direct LOINC codes for lab tests. However, moving to the LOINC Ontology with SNOMED CT improves flexibility and automation. The SNOMED CT Expression Constraint Language (ECL) allows dynamic queries to fetch relevant codes instead of manually mapping them one by one. To migrate, organizations should first identify where LOINC codes are used and create ECL rules that match appropriate SNOMED CT concepts included in the LOINC Ontology. This approach reduces manual work, improves consistency, and makes terminology updates easier to manage in the future. Chapter 5.2 Terminology Bindings suggests bindings that may be relevant for such migration.

To ensure a smooth transition to the LOINC Ontology, it is crucial to first analyze how your system currently represents laboratory test orders and results. This involves identifying all locations in the data model where SNOMED CT, LOINC, or other code systems are applied and understanding how they interact with existing workflows and data exchange processes. By mapping out these connections, organizations can determine whether the current implementation is consistent, accurate, and aligned with best practices.

The goal of this analysis is to identify whether these codes should be updated to use concepts from the LOINC Ontology. This step helps optimize terminology bindings, improve interoperability, and ensure a more structured approach to laboratory data management. Using terminology auditing tools and automated reports can assist in detecting inconsistencies, redundant mappings, or areas where refinements are needed.

Once the LOINC Ontology is deployed, the next step is to evaluate the benefits of replacing direct LOINC terminology bindings with updated LOINC Ontology / SNOMED CT bindings that can take advantage of techniques like ECL Expressions. This is an optional step that can facilitate the maintenance and precision of the bindings.

Older lab test records still contain historical LOINC codes or SNOMED CT identifiers, so ensuring they remain usable after the transition is important. This means mapping old codes to their closest equivalent in the LOINC Ontology while keeping track of changes for future reference. Automated conversion tools can help in bulk updating records while maintaining historical integrity. A phased approach, starting with testing in a controlled environment before full deployment, ensures a smooth transition while avoiding data loss or inconsistencies.

This template is employed when the LOINC term represents an impression observable, capturing a high-level clinical interpretation or summary derived from one or more observations, rather than a direct measurement or finding.

Impression observables concepts all have a primitive definition, following the template described below and documented here: Impression observable for LOINC (observable entity) - v1.0.

Attributes

• LOINC Property: indicates that the quality being observered is some impression or interpretation.

Template

This template is utilized when the LOINC term represents an impression observable.

Model

<<< 363787002 |Observable entity (observable entity)| : 
{ 370130000 |Property (attribute)| -> 118580000 |Impression AND/OR interpretation of study (property) (qualifier value)| }

Terming

In the case of impression concept, the LOINC Long Common Name is used as both the FSN (with a semantic tag of "(observable entity)" added), and the Preferred Term. The LOINC Short Common Name is also included unchanged as an acceptable synonym.

In the case of the example below, this results in the following terms:

There are no LOINC parts represented in the SNOMED model for these impression concepts. The SNOMED concepts are defined as primitive, with only the single property attribute present, always taking a value of 118580000 |Impression AND/OR interpretation of study (property).

This part represents the key entities and relationships within a laboratory order entry system specifically designed to support the integration of the LOINC Extension with SNOMED CT. The model focuses on standardizing and structuring laboratory data for test ordering, specimen management, and result reporting. While not exhaustive or fully detailed for implementation, it highlights critical components necessary to ensure interoperability and consistency in healthcare systems.

By focusing on test identification, specimen management, and result reporting, the model helps support the use of LOINC for laboratory test coding and SNOMED CT for representing clinical concepts such as specimens and test outcomes. This approach promotes efficient data exchange and interoperability in healthcare settings.

The diagram illustrates the relationships between the three main entities in the model: Laboratory Order, Specimen, and Result. Each entity is represented as a rectangular block, with its attributes listed inside. Arrows and cardinalities between the entities indicate how they relate to one another, providing a clear visual of the logical structure of the system.

Key relationships include:

This template is utilized when the LOINC term represents a quality observable with a component. It's suitable for measurements or observations that involve a specific component.

This template is documented here: Quality observable with Component for LOINC (observable entity) - v1.0

The java implementation of this template can be found here.

Attributes

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

• LOINC Scale: Describes the scale type, like quantitative or qualitative.

• LOINC Time: Indicates the time aspect of the observation, e.g., single point in time.

• LOINC System: Specifies the direct site of the observation.

• LOINC Method: Describes the technique used for the observation.

• LOINC Component: Represents the specific component being measured or observed.

Template slots are filled by taking the preferred term of the relevant value from the model and making the initial character lower case, if allowed by the case significance setting of the preferred term.

[PROPERTY] of [COMPONENT] in [SYSTEM] at [TIME] by [METHOD] using [DEVICE] [CHALLENGE]481191010000118

Some slots are optional, and are then tidied up along with any linking words (eg 'using')

The LOINC Long Common Name is specified as the Preferred Term and the LOINC Short Common Name is also included unchanged as an acceptable synonym. Finally a terse form of the LOINC Parts is added, with all part names specified, separated by colons.

In the case of the example below, this results in the following terms:

Loinc Parts

This template is used for LOINC Concepts that do not have all their parts specified and which, as such, act as groupers for all child concepts which also have the same parts. These grouper concepts are all expected to be orderable.

This template is documented here: Quality observable with Component for LOINC Grouper (observable entity) - v1.0

The java implementation of this template can be found here.

Attributes

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

• LOINC System: Specifies the direct site of the observation.

• LOINC Component: Represents the specific component being measured or observed.

Template slots are filled by taking the preferred term of the relevant value from the model and making the initial character lower case, if allowed by the case significance setting of the preferred term.

The LOINC Long Common Name is specified as the Preferred Term and the LOINC Short Common Name is also included unchanged as an acceptable synonym. Finally a terse form of the LOINC Parts is added, with all part names specified, separated by colons.

In the case of the example below, this results in the following terms:

LOINC Term 108011-8

What is FHIR?

HL7 FHIR is a modern standard designed to facilitate the exchange of healthcare information electronically.

• Consistency: With standardized resources and robust semantics, FHIR ensures uniformity in healthcare data representation. This consistency supports accurate data exchange and enables healthcare providers to make informed decisions based on reliable information, ultimately enhancing patient care quality.

• Modularity: FHIR’s flexible architecture allows its resources to be used independently or in combination to meet specific healthcare needs. This modular approach supports adaptability across diverse healthcare contexts, enabling tailored solutions without overhauling entire systems.

• Interoperability: FHIR facilitates seamless data exchange between different healthcare systems and applications, enhancing communication and collaboration among healthcare providers. By standardizing data formats and protocols such as RESTful APIs and JSON/XML, FHIR promotes interoperability, improving patient care coordination and information sharing.

• Standardization: FHIR leverages contemporary web standards to ensure compatibility with existing IT infrastructures. By defining well-structured resources like Patient, Observation, and Medication with clear semantics, FHIR fosters consistency in how healthcare data is represented and interpreted across various systems.

• Scalability: Designed to accommodate evolving healthcare requirements and technological advancements, FHIR is scalable for both current and future healthcare needs. Its flexible architecture and support for extensibility allow healthcare systems to grow and adapt without compromising interoperability or data integrity.

HL7 FHIR plays a crucial role in linking healthcare data with standard terminologies, including SNOMED CT. By integrating FHIR with terminologies like SNOMED CT, more precise and standardized documentation and communication of clinical information can be achieved. This linkage enhances interoperability by enabling seamless exchange of structured clinical data, supporting accurate clinical decision-making, and promoting continuity of care for patients across various healthcare settings.

For the purpose of representing the laboratory data workflow, we can use the following FHIR resources:

• ServiceRequest: Represents laboratory orders or requests for specific diagnostic tests or procedures.

• DiagnosticReport: Captures the overall results or findings of the laboratory tests as a summarized report.

• Observation: Provides detailed data points or specific results associated with the laboratory tests.

Examples:

The image below illustrates how FHIR resources can be used to represent the generalized logical model for laboratory data. It outlines the relationships between key FHIR resources (highlighted in red) and logical model entities (depicted in gray), offering a structured approach to representing laboratory orders, individual results, and specimen information.

• Laboratory Order: Mapped to the FHIR ServiceRequest resource, representing the clinical request for laboratory testing. It includes details such as test code, priority, status, and the specimen to be tested.

• Result: Mapped to the FHIR DiagnosticReport resource, summarizing the findings of the laboratory tests based on the order. The DiagnosticReport serves as a container for individual results.

• Individual Results: Represented by the FHIR Observation resource, where each Observation provides specific result details such as:

Relationships

• The FHIR ServiceRequest initiates the laboratory process and forms the basis for the FHIR DiagnosticReport.

• The FHIR DiagnosticReport includes one or more FHIR Observations, each representing an individual result.

• The FHIR Specimen resource is central to the model, linking the order, results, and observations to the biological material tested.

This template is employed when the LOINC term involves an observation that specifies an aspect of a process at a point in time where the process output is not included.

This template is documented here:

The java implementation of this template can be found .

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

This template is employed when the LOINC term involves an observation that specifies a process or an outcome of a process

This template is documented in Confluence here:

The java implementation of this template can be found .

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

This template is used when the LOINC term involves a component and is relative to something else, such as a reference point or another component.

This template is documented in Confluence here: Quality observable with Component and Relative to for LOINC (observable entity) - v1.0”

The java implementation of this template can be found here.

Attributes

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

• LOINC Scale: Describes the scale type, like quantitative or qualitative.

• LOINC Time: Indicates the time aspect of the observation, e.g., single point in time.

• LOINC System: Specifies the direct site of the observation.

• LOINC Method: Describes the technique used for the observation.

• LOINC Component: Represents the specific component being measured or observed.

• LOINC Divisor: Specifies what the observation is relative to.

Template slots are filled by taking the preferred term of the relevant value from the model and making the initial character lower case, if allowed by the case significance setting of the preferred term.

[PROPERTY] of [COMPONENT] to [DIVISORS] in [SYSTEM] at [TIME] by [METHOD] using [DEVICE] [CHALLENGE]

Some slots are optional, and are then tidied up along with any linking words (eg 'using')

The LOINC Long Common Name is specified as the Preferred Term and the LOINC Short Common Name is also included unchanged as an acceptable synonym. Finally a terse form of the LOINC Parts is added, with all part names specified, separated by colons.

In the case of the example below, this results in the following terms:

Loinc Parts

The LOINC release specifies whether each LOINC concept is Orderable, Observable, or Both in the ORDER_OBS column of the Loinc.csv file. This classification helps healthcare systems determine which concepts can be used for test orders versus those that are strictly for observations. In the LOINC Ontology, this information is provided in two simple type reference sets.

Reference Sets for Orderable and Observables

In SNOMED CT, subsets are represented using simple reference sets (Refsets), allowing implementers to filter and retrieve LOINC terms based on their orderability or observability. This structured approach facilitates the integration of LOINC terminology within SNOMED CT implementations.

For example, implementers can query:

• “Show all LOINC concepts that are Orderable.”

• “Show all LOINC concepts that are Observable.”

To support this, the LOINC Ontology includes two distinct reference sets:

• 635121010000106 | LOINC Observation Reference Set | – Contains LOINC terms classified as Observable.

• 635111010000100 | LOINC Orderable Reference Set |– Contains LOINC terms classified as Orderable.

The reference sets are distributed in a file named according to SNOMED CT conventions: der2_Refset_SimpleRefsetSnapshot_INT_20250321.txt

Each row in this file corresponds to a LOINC term and includes a refsetId that determines whether the term belongs to the Orderable or Observable subset.

Some LOINC terms are classified as both Orderable and Observable. In such cases, the term will appear in both reference sets, ensuring that it is available in queries for either category.

LOINC Observation Reference Set (first 4 rows)

LOINC Orderable Reference Set (first 4 rows)

The counts for the Observation and Orderable Reference Sets can be seen in the browser, in the left-hand panel, and clicking on the "Refset" tab:

Clicking on either of these concepts will bring them up in the right-hand panel:

Note that the concept that represents the reference set does not have any children (these would be different, more specialised reference sets if they existed), but the reference set does have members. These can be listed by clicking on the members tab:

Now we can also obtain this list, or even something more interesting, by going into the "Expression Constraint Queries" tab. For this example, we're going to look for the intersection of these two sets. That is, the LOINC concepts which are BOTH orderable AND observables. The ECL for this query is: ^ AND ^

Note that the counts here refer purely to those LOINC concepts that successfully translated into The LOINC Ontology at time of publication. The full LOINC release in it's original format contains additional codes for each.

This page provides an overview of key use cases for the LOINC Ontology

Description: When clinicians order laboratory tests, ensuring clarity and accuracy is essential to avoid errors, miscommunication, and delays in patient care. Clear identification of tests and consistent communication between systems are crucial for seamless workflows.

Clinical Example: A physician orders a blood glucose test for a patient. The test is selected using a SNOMED CT code in the EHR and the corresponding LOINC code is automatically derived to ensure accurate transmission to the laboratory using a code system applied by the Laboratory Information System.

Clinical Benefits:

This template is used when the LOINC term involves a component and is relative to something else as a ratio, such as a reference point or another component.

Note that Ratio concepts are given a parent of 540131010000107 |Ratio observable (observable entity)| to group them together.

This template is documented in Confluence here: Quality observable with Component and Relative to for LOINC Ratios (observable entity) - v1.0

The java implementation of this template can be found here.

Attributes

• LOINC Property: Represents the property of the observation, such as mass concentration or presence.

• LOINC Scale: Describes the scale type, like quantitative or qualitative.

• LOINC Time: Indicates the time aspect of the observation, e.g., single point in time.

• LOINC System: Specifies the direct site of the observation.

• LOINC Method: Describes the technique used for the observation.

• LOINC Component: Represents the specific component being measured or observed.

• LOINC Divisor: Specifies what the observation is relative to.

Template slots are filled by taking the preferred term of the relevant value from the model and making the initial character lower case, if allowed by the case significance setting of the preferred term.

Some slots are optional, and are then tidied up along with any linking words (eg 'using'). The SEPARATOR is determined programatically and might be "to" or a "/" symbol.

The LOINC Long Common Name is specified as the Preferred Term and the LOINC Short Common Name is also included unchanged as an acceptable synonym. Finally a terse form of the LOINC Parts is added, with all part names specified, separated by colons.

In the case of the example below, this results in the following terms:

LOINC Term

Introduction

Effective deployment of the LOINC Ontology requires efficient access to the content in ways that take advantage of the features of both terminologies. A terminology service is a software function that interfaces with, and provides access to, one or more representations of a terminology, allowing for streamlined retrieval and management of terminology data.

Various technical options are available for implementing terminology services, including relational databases, graph databases, and predefined services accessible via APIs (e.g., SNOMED International’s Snowstorm). Selecting an appropriate approach for deploying the LOINC Extension depends on factors such as existing infrastructure, integration complexity, and the level of flexibility required. Whether using a local database or a cloud-based solution, the choice should ensure effective access, updating, and management of the terminology content.

Regardless of the platform chosen, the deployment of the LOINC Extension involves importing a SNOMED CT Edition and the LOINC Extension into the selected database or server.

Required Release Packages

To deploy the LOINC Ontology, the following RF2 packages are necessary:

• The latest version of the national release available

• For national extension packages, the corresponding SNOMED CT International Edition (the version on which the national extension is dependent)

• The latest version of the LOINC Extension package, where the International Edition dependency aligns with the version being used

Release notes accompanying the LOINC Extension package detail the International Edition dependency, helping to ensure compatibility.

The LOINC Ontology aligns with specific releases of the SNOMED CT International Edition. Each version of the LOINC Extension is updated in sync with the International Edition to ensure consistent compatibility.

The LOINC Ontology is planned for biannual releases, occurring in March and September, following the LOINC release from the preceding month.

National Editions follow independent release cycles, which vary by country or member organization, and may be released monthly, quarterly, or biannually. SNOMED CT is designed to handle these variations, using comprehensive history tracking to manage discrepancies that may arise from differing release cycles.

For example, if a National Edition is released in May based on the March International Edition, and the LOINC Extension is based on the February International Edition, there may be references to inactive concepts between releases. SNOMED CT enables easy identification and resolution of these references, maintaining the LOINC Extension’s consistency across different release schedules.

No potential implementation issues can be described for this scenario. In this case, the National Edition and the LOINC Ontology follow the same release cycle and depend on the same version of the International Edition. This alignment simplifies implementation by eliminating version discrepancies. Any changes made to the International Edition that impact both the LOINC Ontology and the National Edition will be managed by their respective owners.

In this example, an implementer in November may select to use the October release of the National Edition with the latest LOINC Ontology release available, the September release.

The National Edition is the primary resource that determines the selection of dependency. As a derivative, the LOINC Ontology must align with the dependencies of the National Edition.

When deployed in an implementation terminology server, the configuration will be as follows:

• International Edition (August release) – The version on which the National Edition depends.

• LOINC Ontology (September release) – Originally dependent on the July version of the International Edition, which is no longer available.

• National Edition (October release) – The authoritative edition dictating dependencies.

In this setup, any changes made to the International Edition between July and August may impact the LOINC Ontology, as outlined below.

In this example, an implementer in September may select to use the July release of the National Edition with the latest LOINC Ontology release available, the September release.

When deployed in an implementation terminology server, the configuration will be as follows:

• International Edition (May release) – The version on which the National Edition depends.

• LOINC Ontology (September release) – Originally dependent on the July version of the International Edition, which is unavailable.

• National Edition (July release) – The authoritative edition dictating dependencies. The latest available National Release is in September.

Here, the LOINC Ontology may refer to an International Edition Concept created after the May release and, therefore, it would be unavailable in this environment.

Using a version of the LOINC Ontology that relies on a different version of the International Edition than the one used by the National Edition may lead to the following errors:

• Inactive or Unknown Parent Concepts – A LOINC Ontology concept may reference a parent that is no longer active or is unrecognized.

• Inactive or Unknown Attribute Values – International Edition concepts used as attribute values for LOINC Ontology concepts may be inactive or unknown.

These issues can arise in two ways:

• Inactive Concepts – If a concept has been inactivated in the International Edition after the release of the LOINC Ontology, but the National Edition is using a more recent version, the referenced concept may no longer be valid.

• Unknown Concepts – If the National Edition depends on an older version of the International Edition than the one used by the LOINC Ontology, some referenced concepts may be missing or unrecognized.

When discrepancies exist between the National Edition and the LOINC Ontology dependencies, several issues may arise:

• ECL selections may fail for concepts with version errors

  • For example, If a parent of a LOINC Ontology concept has been inactivated, then aggregations using the '<' operator (or other ECL hierarchy selections) will not include the child concept

  • ECL queries referencing inactive concepts directly are invalid

To minimize disruption from dependency discrepancies, users can adopt several strategies:

• Regular monitoring of concept status: Use SNOMED CT tools to track inactive and replaced concepts.

• Automated mapping and remediation: Utilize historical associations and mapping tables to replace inactive concepts with suitable alternatives.

• Pre-implementation impact assessment: Before deploying the LOINC Ontology, run queries to identify any inactive concepts and resolve dependencies.

Evaluating the impact of discrepancies between the dependency for the National Edition and the dependency for the LOINC Ontology is important for maintaining data consistency, usability, and interoperability. Users can assess the impact through several key factors:

1. Concept availability and integrity

   • If the National Edition is based on a different version of the SNOMED CT International Edition than the LOINC Ontology, there may be concepts referenced in the LOINC Extension that are inactive or unavailable in the National Edition.

   • Users should assess whether key concepts required for coding, reporting, and decision support are missing or have been replaced with new concepts.

Inactive concepts within the LOINC Ontology can be managed effectively using the SNOMED CT Expression Constraint Language, which allows you to extract inactive components and reference set members.

Retrieve inactive concepts from all SNOMED CT hierarchies belonging to the LOINC Ontology module:

Retrieve inactive concepts from the Observable entity hierarchy belonging to the LOINC Ontology module:

This query identifies all concepts within the LOINC Extension that are currently inactive (active = false). It is useful for reviewing or managing outdated concepts.

If you prefer to work exclusively with active concepts, you can use the inverse ECL query.

Retrieve active concepts from all SNOMED CT hierarchies belonging to the LOINC Ontology module:

Retrieve active concepts from the Observable entity hierarchy belonging to the LOINC Ontology module:

This query returns only those concepts that are currently active, ensuring that you are working with up-to-date information. You can further refine this query by adding hierarchical filters, such as focusing on concepts within a particular clinical hierarchy.

Despite these potential issues, the actual risk of problems is considered low due to the design of the LOINC Ontology. The LOINC Ontology has a flat hierarchical structure, therefore the number of International Edition parents is very low. These parent concepts are stable groupers in the International Edition, minimizing the risk of inactivation. The concepts used as attribute values come from a recent mapping effort between LOINC parts and SNOMED CT concepts, meaning most have been reviewed recently. As a result, a degree of stability is also expected for the attribute values. Using a newer version of the International Edition with the LOINC Ontology has a lower risk of inconsistencies than using an older version of the International Edition. This due to the fact that attribute concepts could be created during the process of updating the LOINC Ontology to a new version.

When deploying the LOINC Extension to SNOMED CT, you have two main options:

1. Use the Extension as-is, accepting that some components may reference inactive concepts

   • Benefit: Minimal setup time and resource use.

   • Challenge: Potential use of inactive concepts, which may affect coding accuracy.