Background

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 https://loincsnomed.org/ along with downloadable content and the LOINC Ontology Browser.

Objective

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

The objective of the SNOMED CT Implementation Guide for the LOINC Ontology is to describe the structure and content of the LOINC Extension for SNOMED CT and provide practical guidance for its application. The guide explains how the integration of LOINC and SNOMED CT works in both directions, supporting standardized representation of observations in SNOMED CT while also enhancing the clinical utility of LOINC.

The scope of this guide is to provide a foundational framework for understanding and implementing the LOINC Extension to SNOMED CT, addressing both conceptual and practical aspects of its use.

As a dynamic document, its content will evolve in alignment with updates to the extension, ensuring it remains current and relevant. This adaptability allows the guide to incorporate new features, use cases, and advancements as the extension develops, supporting users in effectively applying the latest capabilities.

By remaining flexible and responsive, the guide ensures ongoing alignment with the evolving needs of healthcare interoperability and data standardization.

This guide outlines the foundational framework for understanding and implementing the LOINC Extension for SNOMED CT, focusing on both conceptual and practical aspects.

The document will evolve alongside updates to the extension, incorporating new features and use cases to ensure relevance. This adaptability supports users in leveraging the latest capabilities for healthcare data standardization and interoperability.

This guide is designed for a diverse range of stakeholders involved in the implementation and application of the LOINC Extension to SNOMED CT. It provides practical insights and best practices tailored to specific user groups, helping them understand and utilize the extension effectively in their respective domains:

• SNOMED International Members seeking clear guidance and uniform best practices for implementing and documenting the integration of LOINC and SNOMED CT, ensuring consistent application across healthcare systems.

• Clinicians interested in understanding how the integration can enhance clinical data collection, improve patient care workflows, and support comprehensive clinical documentation.

• Information Managers responsible for incorporating SNOMED CT into health information models and workflows, aiming to optimize data standardization and interoperability in laboratory and clinical settings.

This SNOMED CT Implementation Guide and the development of the LOINC Extension to SNOMED CT are the result of a collaborative effort between key contributors from SNOMED International and the Regenstrief Institute. Their expertise and dedication have been critical in establishing the cooperative agreement and advancing the extension.

Attributions

• Name: Collaborative Team from SNOMED International and Regenstrief Institute

  • Affiliation: SNOMED International and Regenstrief Institute

  • Description: This team was responsible for establishing the cooperative agreement in October 2022 and leading the development of the LOINC Extension to SNOMED CT. Their contributions include identifying overlapping terminologies, minimizing duplication, and designing an integrated extension to improve interoperability and usability.

This SNOMED CT Implementation Guide is specifically designed to support the implementation of the LOINC Ontology within SNOMED CT. The guide provides a structured framework for understanding the integration of LOINC’s granular laboratory observables into SNOMED CT’s Logical design. It is organized into five main chapters:

• Chapter 1: Introduction - This chapter provides an overview of the LOINC Ontology, including its development through the collaboration between SNOMED International and the Regenstrief Institute. It outlines the objectives, scope, and intended audience of this guide.

• Chapter 2: - This chapter provides a foundational understanding of LOINC, detailing its purpose, structure, and role in healthcare data standardization. It explains how LOINC supports the representation of laboratory tests, clinical observations, and other coded health data. Additionally, the chapter introduces the LOINC Extension within SNOMED CT, outlining how it enhances interoperability and aligns with broader clinical terminology standards.

• Chapter 3: - This chapter describes key use cases that demonstrate the value of integrating LOINC into SNOMED CT. It covers scenarios where the LOINC Extension enhances data interoperability, improves laboratory result standardization, and facilitates clinical decision support.

We encourage and welcome feedback from all readers to ensure this guide remains accurate, relevant, and useful. The review process is an ongoing effort to engage the community in improving the content. A feedback button is provided on each page of the guide, allowing readers to share their comments and suggestions directly related to the content.

Comments or inquiries that are not relevant as feedback on specific page content should be directed to the Regenstrief Institute () for further assistance.

All feedback will be carefully reviewed, and updates will be incorporated as appropriate. The guide will be revised and updated with every new release of the LOINC Extension to SNOMED CT, ensuring it reflects the latest developments and enhancements. Your input is invaluable in helping us maintain a resource that meets the needs of its users and supports the effective implementation of this extension.

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.

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.

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}

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

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:

The java implementation of this template can be found .

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

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

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.

Introduction

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.

Diagram

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:

• A Laboratory Order can result in one or more Results.

• A Result must be associated with a single Specimen.

• A Specimen is optionally linked to a Laboratory Order, offering flexibility in how samples are managed.

• Laboratory Order:

  • Represents the details of a requested laboratory test.

  • Acts as the starting point for test processing and result generation.

• Specimen:

• Laboratory Order Attributes:

  • code: The identifier for the laboratory test being ordered

  • priority: Indicates the urgency of the test request

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:

The following points outline the key aspects of member licensing:

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.

Provide Feedback

LOINC Terms are expressed as SNOMED CT concepts by following a transformation algorithm detailed in pseudocode. This has been implemented as a number of Java classes, freely available in this package in the SNOMED International GitHub Script Library project.

Overview

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

3. The process works through the part detail file, selecting a template based on the 'Property' part of each LOINC Term

4. Each part is mapped to a SNOMED CT Attribute where:

   1. The Part Type maps to a SNOMED Attribute type as specified in the template and

   2. The Part Number maps to a SNOMED Attribute value as specified via the Part/Attribute Map (maintained in the Snap2Snomed tool)

5. The terms for each concept are then completed, using the preferred terms of the attribute values that have been modelled.

6. The entire set of modelled concepts is the compared against the LOINC Extension in the SI Authoring Platform

7. A delta archive is produced which details changes required from the previous state of the content.

In addition, LOINC Panels are created as primitive concepts, where the individual tests in each panel are available as transformed SNOMED CT concepts.

See

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:

The java implementation of this template can be found .

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

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

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.

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.

• Test Details

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.

This template is employed when the LOINC term involves an observation that inherently exists within or is associated with something else, and relates to a specific location such as a specific sequence within a gene.

This template is documented in Confluence here: Quality observable with Inheres in and Inherent location 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 what the observation inherently exists within or is associated with.

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]

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 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: Process Observable for LOINC - No Process output, With Time Aspect (observable entity) - v0.1

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 what the observation inherently exists within or is associated with.

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

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.

The java implementation of this template can be found here.

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

Effective utilization of the LOINC Extension to SNOMED CT requires a well-defined information model that structures and organizes data consistently. An information model is essential because it provides a framework for accurately capturing, storing, and sharing data across healthcare systems. By establishing clear guidelines for how data elements are related and represented, the information model ensures that laboratory data is consistently documented and understood, facilitating seamless communication between healthcare providers and enabling reliable data analysis. Additionally, this structured approach supports interoperability, allowing different systems to work together efficiently and ensuring that health information can be exchanged and utilized effectively.

The integration of SNOMED CT and LOINC through the development of the LOINC extension to SNOMED CT has gained significant momentum in recent years, owing to its ability to complement and extend the capabilities of healthcare information systems. This section of the guide delves into the information models and terminology bindings that enable the precise documentation and utilization of laboratory data within electronic health records (EHRs). Emphasis is placed on HL7 FHIR as a prime example, showcasing how it can be leveraged to support the integration of SNOMED CT and LOINC, thereby ensuring accurate and standardized data representation in clinical workflows.

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

• Data Inconsistencies

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.

   • This approach is commonly used because it offers quick deployment, and SNOMED CT provides methods for managing inactive content, such as historical associations. The best practice is to use the latest version of the published LOINC Extension, ensuring alignment with a current SNOMED CT International Edition.

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

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.

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

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

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.

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.

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 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: Process 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 SNOMED CT process output.

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:

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.

Contents

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

   1. Clinicians use SNOMED CT codes to search and select tests in the EHR system.

   2. The selected tests are associated with LOINC codes, ensuring standardized data for lab orders.

2. Transferring Orders to the Lab

   1. The EHR system sends lab orders to the LIS using a structured message format (e.g., FHIR or similar standards), including SNOMED CT and LOINC codes.

   2. This ensures the lab receives clear and consistent instructions on the required tests.

3. Performing the Tests

   1. The lab uses the LOINC codes to identify the exact tests to be performed.

   2. SNOMED CT is used to provide detailed descriptions, such as specimen types and any relevant clinical observations.

4. Generating and Analyzing Test Results

   1. The lab performs the tests and records results, standardizing the data using LOINC codes.

   2. SNOMED CT may be used to document clinical conditions or observations associated with the results.

5. Transferring Results Back to the EHR

   1. Test results, along with associated LOINC and SNOMED CT codes, are transferred from the LIS to the EHR using a structured message format.

   2. This allows for seamless integration of lab results into the patient’s records.

6. Using Lab Data

   1. The standardized lab data is then used for clinical decision-making, research, and analytics, such as evaluating the effectiveness of treatments for conditions like diabetes.

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.

Example

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.

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:

  • coding: Uses the SNOMED CT conceptId 72641010000107

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.

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:

• Precision in test ordering and communication.

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

This section contains a high-level overview of LOINC with some additional information in areas of direct relevance to subsequent chapters of this guide. For a more complete introduction to LOINC and supporting resources see http://loinc.org/get-started.

Logical Observation Identifiers Names and Codes (LOINC®) is a terminology standard for identifying laboratory tests and other measurements. It specifies universal codes, names, and other attributes for laboratory results as well as clinical reports, physical exam findings, survey instruments and other observations. It was developed to enable the exchange and pooling of results from diverse sources in order to enhance clinical care, outcomes management and research.

Scope

LOINC codes include laboratory and other clinical observations. The laboratory portion of LOINC includes measurements made on specimens, such in chemistry, hematology, serology, microbiology (including parasitology and virology), toxicology, cell counts, antibiotic susceptibilities, and more. The clinical portion of LOINC includes codes for observations made on patients and populations. LOINC has codes for observations like vital signs and a wide range of other clinical observations. Vital signs and anthropomorphic measurement are included in the scope of the cooperation agreement. Other clinical domains are not currently included in the scope of the agreement with IHTSDO.

LOINC includes codes that identify test observations (e.g. blood culture, antibiotic sensitivity). Other code systems, including SNOMED CT, often provide values that can be applied to represent results (e.g. Staphylococcus, amoxicillin). If we consider the observation as a question and the observation values as answers, LOINC provides codes for the questions and SNOMED CT provides codes for many of the non-numeric answers.

Maintenance, Governance and Licensing

LOINC is owned, maintained, and licensed by the Regenstrief Institute, Inc. (RII). RII is a non-profit medical research organization associated with Indiana University School of Medicine. LOINC is available free of charge subject to the license conditions and terms of use . Updated versions are released twice a year. The LOINC web search tool is available at The LOINC database and a free browsing and mapping program, the Regenstrief LOINC Mapping Assistant (RELMA®), can be downloaded from

LOINC is widely adopted, and the user community continues to grow rapidly. The worldwide LOINC community presently has more than 34,000 users in 195 countries (see ).

Within the USA, LOINC has been adopted by large reference laboratories, health information exchanges, healthcare organizations, insurance companies, research applications, and several national standards initiatives and programs. In particular, LOINC was adopted as the standard for laboratory orders and results as part of the Centers for Medicare and Medicaid Services Electronic Health Record (EHR) "Meaningful Use" incentive program as specified in the Standards and Certification Criteria.

Outside the USA, LOINC has also been adopted as a national standard in more than 25 countries. In addition, there are many large data exchanges using LOINC around the world.

Each test is represented by a formal part LOINC name and assigned a LOINC code, which is a number with a check digit (see Table 1). Each code is also assigned an observation class (e.g., chemistry, hematology, and radiology); related names (to assist searches of the database); and other attributes.

For most classes of laboratory observations, there is also a "short name" (less than 40 characters long), and a Long Common Name that is more clinician friendly.

LOINC fully-specified names (including laboratory test results, clinical measurements, and results of other diagnostic studies) are defined in terms of six major axes as exemplified in the table below.

• 1. Component name

• 2. Property

• 3. Time

• 4. System

The fully-specified (formal) LOINC name must include entries for the first five major axes; the method axis is included only when the method distinction makes an important difference to the clinical interpretation of the result.

Four additional elements are represented as subparts of the main axes: challenge conditions (e.g., substance, route, and timing); adjustments; supersystem (e.g., fetus, blood product); and time operators (maximum, minimum, last, first), which are only used when relevant. The challenge axis is the most complex among these and may include details such as the amount, route, and timing (e.g., oral glucose tolerance test), but can also represent simpler conditions (e.g., fasting, sitting). Further details about these components can be found in the LOINC Users’ Guide.

Examples of LOINC terms are shown in this table

LOINC creates only those combinations that have clinical relevance in laboratory medicine. Terms are not created by blind permutations. Regenstrief (with guidance from the LOINC committee) reviews new code requests carefully to make sure that only meaningful LOINC codes that can be pragmatically used by the LOINC community are added to the database.

The atomic elements that comprise a fully-specified LOINC name are called LOINC "Parts". Each fully-specified name will consist of 5 or 6 parts (depending on whether the Method is important for interpreting the result), each with a part type corresponding to one of the major axes described above. Each LOINC Part is also assigned an identifier (that begins with the prefix "LP"), and internally Regenstrief maintains links between the full LOINC term and the Parts that comprise it. Regenstrief uses LOINC Parts in many aspects of LOINC development, such as: adding synonymy, building hierarchies, creating alternate display names, linking descriptive text, and more.

The Parts and their linkages are not distributed as part of the main LOINC table, but they are part of the content used by the RELMA program.

LOINC "part" concepts (e.g. sodium) serve as building blocks for the description of tests and observations, in association with a set of semantic relations. For example, Sodium:SCnc:Pt:Ser/Plas:Qn, the laboratory test in which the molar concentration of sodium is measured in the plasma (or serum) is identified by 2951-2.

The list of relations of this concept to other concepts ("parts") is shown in the examples below. For example, the "part" concept Sodium is linked to this test by the relationship component.

The LOINC terminology does not use description logic. However, the formal definitions provided by LOINC all conform to the 6-axis template and make use of named semantic relations.

In addition to creating codes for single tests, measurements, or observations, LOINC also defines concepts to represent collections of discrete elements such as panels (batteries), forms, and answer lists.

For example, a CBC/FBC test (complete/full blood count) is expected to deliver a set of results for different components including leukocytes, erythrocytes, hemoglobin, hematocrit, etc.

Regenstrief creates hierarchies to organize LOINC terms based on a structured arrangement of LOINC elements (also known as parts).RELMA has 5 selectable hierarchy trees that are commonly used to narrow the search limits returned:

• Class

• Multiaxial (component/system)

• System (specimen)

• Component

The LOINC hierarchy group LOINC concepts by specifying the parent-child relationship between the elements used in one (or more of the axes).

Most often, the hierarchies are used to restrict searches performed using RELMA.

The Multiaxial hierarchy organizes LOINC codes based on more than one of the LOINC name axes. For laboratory tests, it organizes first by the Component and then by the System. The Multiaxial Hierarchy is distributed as an accessory file that is part of the LOINC release.

The new LABORDERS.ONTOLOGY class introduces concepts to improve organization and allow for abstract, order-level granularity, addressing limitations of the LOINC Ontology used as a SNOMED CT Extension. These concepts serve two needs: grouper concepts for browsing a large list, and abstract order codes (requested by LOINC and SNOMED communities) that are less specific than result codes.

The new codes contain unique combinations of Component, System (specimen), and a new, abstract Property (measurement). They do not include scale or timing parts.

Crucially, these new concepts must not be used as result codes in result messages.

A LOINC panel is a grouping of related laboratory tests or observations often performed together or reported as a single entity. Components of a LOINC panel include:

• Panel name: Describes the group of tests or observations being measured

  • Example: "Basic Metabolic Panel"

• Component tests: Lists individual tests or observations included in the panel, each with its corresponding LOINC code.

This example demonstrates how LOINC codes, panels, and their respective parts and terms work together to identify and describe medical measurements and observations in a standardized and easy-to-understand manner.

• LOINC Code: 8480-6 (Systolic blood pressure)

• LOINC Panel: Basic Metabolic Panel (LOINC Code: 51990-0)

  • Component Tests: Glucose (LOINC Code: 2339-0), Electrolytes (LOINC Code: 55231-5), Kidney function tests (LOINC Code: 6299-2), etc.

A LOINC Answer List is a predefined set of possible answers associated with a LOINC term, typically used for representing qualitative or categorical results. These lists are often tied to laboratory tests, surveys, or other clinical observations where the result is selected from a finite set of options.

For example, the LOINC code 30324-8 (Cryptococcus sp Ag [Presence] in Serum by Latex agglutination) uses an answer list that includes values such as “Positive” and “Negative” to indicate the presence or absence of an antigen to Cryptococcus in serum by latex agglutination.

LOINC Answer Lists help standardize the possible responses for specific clinical concepts, ensuring consistency in how test results or observations are recorded and interpreted across systems.

LOINC Answer Values are the specific entries or responses within a LOINC Answer List. These values represent the standardized options clinicians or systems can choose from when documenting the result of a test or clinical observation. For example, in a LOINC Answer List for the code 72166-2 (Smoking status), possible answer values might include “Never Smoked”, “Former Smoker”, and “Current Smoker”. These predefined answer values ensure that responses are recorded uniformly, reducing ambiguity and facilitating the comparison of data across different systems and contexts.