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:

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

Understanding Releases and Dependencies

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.

Scenario 1: The National Edition dependent on the same version of the International Edition than the LOINC Ontology

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.

Scenario 2a: The National Edition dependent on a different version of the International Edition than the LOINC Ontology

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:

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

Scenario 2b: The National Edition doesn't follow the same release schedule as the LOINC Ontology

 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:

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.

Potential Issues

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:

These issues can arise in two ways:

Consequences 

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

Mitigation Strategies

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

Impact Assessment

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

  2. Reference set consistency

  3. Historical tracking and concept mapping

  4. Data interoperability and exchange

  5. Impact on Clinical Decision Support (CDS)

  6. Workflow and implementation strategies

Summary of Actions

Category

Action

Query Example

Description

  1. Concept Availability and Integrity

Identify concepts with inactive parents and check if replacements are available.


<! ( * {{ C effectiveTime>=20250101 active=false }}


Identify concepts with inactive parents

This query is satisfied by the direct parents (<!) of any (*) concept in the substrate , where those concepts have an effectiveTime greater than or equal to the specified date, and an active value of false (i.e. only inactive concepts are returned)

Note that 20250101 is just provided here as an example.


2. Reference Set Consistency

Analyze reference sets to identify outdated or inactive concepts.


^ (< 446609009 |Simple type reference set (foundation metadata concept)|){{ C active=0}}


Note that this ECL only retrieves the members of simple type reference sets. If other types are required, the concept id for those types can be applied.

3. Historical Tracking and Concept Mapping

Identify inactive concept references in maps.


^ (< 900000000000496009 |Simple map from SNOMED CT type reference set (foundation metadata concept)|){{ C active=0}}


Note that this ECL only retrieves the members of simple map from SNOMED CT type reference set. If other types are required, the concept id for those types can be applied.

4. Data Interoperability and Exchange

Assess interoperability risks due to dependency mismatches.

N/A

Based on historical interoperability data, it would be possible to verify the recorded frequency of use of the concepts with incorrect references. Finding that a very common concept has incorrect references with the new dependencies might lead to the need to take remedial actions in a new local release.

5. Impact on Clinical Decision Support (CDS)

Identify inactive or missing concepts in CDS rules.

N/A

Existing Clinical Decision Support rules should be analyzed to identify if they directly reference an inactive concept or a concept affected by references to inactive concepts.

6. Workflow and Implementation Strategies

Decide whether to temporarily accept inactive concepts or proactively align the National Edition with the latest SNOMED CT version.

N/A

It is possible to include fixes in a new release of the national or local extension for mismatches between the LOINC Extension and the International Edition.

However, after careful evaluation of the existing mismatches, implementers can decide to go forward with a deployment of the terminology that includes a limited number of incorrect references.

Identifying References to Inactive 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:

* {{ C moduleId = 11010000107 active=0}}


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

< 363787002 |Observable entity (observable entity)| {{ C moduleId = 11010000107 active=0}}

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

Working with Active Components Only

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:

* {{ C moduleId = 11010000107 active=1}}


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

< 363787002 |Observable entity (observable entity)| {{ C moduleId = 11010000107 active=1}}

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.

Implementation Considerations

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
  2. Conduct pre-implementation processing to resolve references to inactive concepts