This page is part of the Loinc/IVD Mapping FHIR IG (v0.2.0: STU 1 (FHIR R4) Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

General Principles and Design

LOINC Mapping Summary

When communicating results from a device to the Laboratory Information System (LIS), two concepts must be mapped: the device’s Vendor Analyte Code to the LIS Test Result code. Neither In-Vitro Diagnostic (IVD) Test codes or LIS Test Result codes are based on industry standard vocabulary. The manufacturer assigns Vendor Analyte Code to their devices, while the Laboratory creates test result codes for the tests they provide. Through LIS configuration tools, the test result code is associated with one or more LIS test result codes based on context, e.g., IVD Test Code used with one vs. another specimen would yield a different LIS test result code. This process has been in place for decades and has been optimized to support the Laboratory’s specific reporting requirements (including conformance to Clinical Laboratory Improvement Amendments (CLIA) for the US).

To enable analytics and clinical decision support, harmonization to a common vocabulary is critical. For Lab test results, Logical Observation Identifiers Names and Codes (LOINC(R)) is the coding system of choice, thus introducing the question on how to map the LIS Test Result Code to LOINC and do so consistently across all labs to enable analytics and clinical decision support reliably.

For now, and particularly until an LIS communicates ordered tests with the device using LOINC, the device cannot provide the appropriate LOINC code with the test result. The LIS must provide the mapping as they associate the Vendor Analyte Code with the LIS Test Result Code. To date this mapping process has relied on a combination of the LOINC registry, RELMA, and the individual’s knowledge of LOINC plus the LIS’ test compendium.

The device manufacturer can aid in the process by providing a list of suggested LOINC codes for each of their IVD Test Codes, including context of the result, specimen, and other considerations that would influence the choice. Such guidance would help reduce the scope of potential LOINC codes to consider, thus improving efficiency and quality of the mapping process, particularly across laboratories, i.e., arriving at the same LOINC code for the same test.

The following diagram may help further clarify that:

• The LIS maintains a map between the IVD Test Code and their LIS Test Result Code.
  • One IVD Test Code can yield different LIS Test Result Codes depending on specimen and other parameters.
• Each of the LIS Test Result Codes must have a LOINC code associated with it so the results report includes the appropriate LOINC code as well for downstream use.
• Laboratory staff today rely on LOINC definitions (using RELMA or the web based tool), their local mappings, and their expertise/knowledge about the device, test, and parameters, to associate a specific LOINC code to the LIS Test Result Code.
• Adding the LIVD suggested mappings, where available, enhances the Laboratory's staff to arrive more quickly and correctly at the right LOINC code.

When the lab professional builds the test results that their LIS will manage and interact with the devices, they can use the device vendor’s suggestions to more accurately, consistently, and efficiently map the results in their LIS to a LOINC code in context of the device’s IVD Test Code. The following example clarifies the information a lab professional would use during their configuration.

Example:

• Vendor Analyte Code = 1067 (Gluc) is mapped in the LIS to:
  • LIS Test Result Code = 123 - Random Glucose
  • LIS Test Result Code = 456 - Fasting Glucose
  • LIS Test Result Code = 789 - 1 Hour Glucose
• LIVD Mapping Vendor Analyte Code = 1067 (Gluc) suggests:
  • Based on vendor comment [comment], vendor result description [result] A, vendor specimen description [specimen] "cerebrospinal", LOINC axes => 2342-4
  • Based on vendor comment [comment], vendor result description [result] B, vendor specimen description "urine", LOINC axes => 63382-6
  • Based on vendor comment [comment], vendor result description [result] C, vendor specimen description "serum/plasma", LOINC axes => 20438-8
• Consequently, most appropriate mapping:
  • LIS Test Result Code = 123 - Random Glucose
    • LOINC Code = 2342-4
  • LIS Test Result Code = 456 - Fasting Glucose
    • LOINC Code = 63382-6
  • LIS Test Result Code = 789 - 1 Hour Glucose
    • LOINC Code = 20438-8

LIVD Concepts

The basic structure that the LIVD Publication must support is based on the Digital Format for Publication of LOINC to Vendor IVD Test Results as published by IICC - IVD Industry Connectivity Consortium. It can be represented as follows:

The implementation guide supports the following mappings:

• A publication is typically for one vendor's devices, but it is possible to combine information from multiple vendors into an aggregate publication.
• One vendor IVD Test Result to many LOINCs
  • This is a very common occurrence. Depending on the context of the result, specimen, or other qualification, the same IVD Test Result can be mapped to different suggested LOINC codes as also shown in the example above. Antoher example may be that an IVD test for serum glucose could map to one LOINC code considering a mass concentration (e.g. mg/dL) or another LOINC considering a substance concentration (e.g. mol/L). Or, a urine albumin could map to one LOINC code for a 24 hour excretion rate with units of mg/(24.h), versus another LOINC code for a random urine with unit of md/dL.
• One LOINC to many vendor IVD Test Results
  • This is a much less common occurrence.
    • For example, an IVD instrument may distinguish stat tests from routine tests by the IVD test code. In this case, the LOINC [13969-1] Creatine kinase.MB [Mass/volume] in Serum or Plasma is associated with two IVD Test Results, depending if the test is routine or stat (prioritized).
    • Or, consider a susceptibility test that has different IVD Test IDs based on the original specimen source. In this case, the LOINC [6932-8] Penicillin [Susceptibility] by Minimum inhibitory concentration (MIC), which is named for testing on the isolate, could be associated with multiple IVD Test Results for one IVD Instrument depending on the clinical context. For example, the break points are different for suspected meningitis versus blood infections and to date LOINC has only distinguished test codes by suspected source of infection for some antibiotic susceptibility codes.
• The IVD Test Code Map enable these many to many mappings, also considering that there may not be a suggested LOINC code for a particular IVD Test Result, or clearly that not every LOINC code is related to an IVD Test Result.

LIVD Data Definitions

LIVD Publication

This information establishes the version for the publication as expressed through the LIVD Catalog profile, including:

• Publisher is the entity publishing the mapping information.
• Publication Version ID is human-readable information provided by the vendor that can be used to differentiate LIVD Publication versions.
• LOINC Version ID is the version of LOINC that was used for the mapping.
• The LOINC License requires a statement of attribution and notice that LOINC content is copyrighted.
• LOINCCopyright component holds the required attribution statement.
• Localization is the language used for this LIVD Publication.
• Region is an optional vendor description for which geographic or administrative region this localization is valid, e.g. de-CH (German (Switzerland)) is self-explanatory, but not en-CH (English (Switzerland)).

Equipment

The equipment elements are expressed through the LIVD Device Definition profile, including:

• Manufacturer is the name of the manufacturer of the device.
• Model is the model of the device as provided by the manufacturer.
• UID is the unique device identifier, that may be the one used in the Unique Device Identifier (UDI) constructs.
• UID Type is capable of supporting the unique device identification system to identify medical devices through their distribution and use. When fully implemented, the label of most devices will include a unique device identifier (UDI) in human- and machine-readable form.

Note that types and cardinality are aligned with values reported in Laboratory Analytical Workflow (LAW) Profile OBX-18 Equipment Instance Identifier.

IVD Test Results

The IVD Test Result components are aligned with values reported in OBX-3 Observation Identifier as applicable and expressed using the LIVD Observation Definition profile.

• Vendor Analyte Code is one of two possible values:
  • For an automated test result, it contains Vendor Transmission Code used by the instrument when sending the test result to a health information system, such as an LIS.
  • For a manual test result, it is the Vendor Analyte Identifier for the test result produced by the Test Kit.
• Vendor Analyte Name is human-readable text the vendor used to identify the analyte. The text might be displayed by the instrument or could be used within an assay insert.
• Vendor Reference ID is an additional vendor identifier, such as an identifier that can be used to locate the associated assay insert published by the vendor.

Additionally, various details on the Observation Definition that can aid in the mapping from the IVD Test Code to a LOINC are included as optional attributes, even though not referenced in the original IICC white paper.

IVD Analyte Code - LOINC Mapping

The potential mappings of the IVD Analyte Code to LOINC code are captured in the LIVD Concept Map profile. For each IVD Analyte Code and a suggested LOINC code, the following attributes are captured.

• Vendor Specimen Description is human-readable text that provides information about the specimen used for the test, such as “Serum or Plasma.” The field is used to document the vendor description of the specimen used for the IVD test.
• Vendor Result Description is human-readable text that provides information about the result that is produced.
  • For non-numeric results, this field should describe the result by including one of the following:
    • Binary – pos/neg, reactive/non-reactive.
    • Ordinal – none, few, many.
    • Nominal – the test can report none found or one or more possibilities from a taxonomy of choices, such as organism names.
  • Numeric results and associated units of measure:
    • For numeric results, this field should describe the result by including a representative unit of measure, preferably represented as a UCUM unit.
    • If one unit of measure is reported, then include it in this field.
    • If multiple units can be reported that can be converted to one another by a multiplicative scale factor independent of the analyte (such as mg/L and ug/dL), select one of the units as a representative unit.
    • If multiple units can be reported that cannot be converted by an analyte-independent scale factor (such as mol/L and as mg/L), then define a mapping for each unit. These different types of numeric results require their own LOINC codes – one for the test reported as molar concentration and one for the test reported as mass concentration. Similarly, the results of a urine analyte (e.g. Sodium) reported as either mmol/L (spot urine) versus mmol/(24.h) (24 hour urine) have different LOINC properties and map to two different LOINC codes. The same is true for viral loads which can be reported in units of copies/mL, Log (copies/mL), IU/mL and Log (IU)/mL; and none of which can be converted by a simple scale factor. These result types have different properties and thus different LOINC codes. In such cases, define a mapping for all units that are appropriate for this IVD test.
    • In some cases, the same IVD Test may be reported as a **Binary** result, or a spot numeric result of the mass concentration, etc. In such instances, the same **_IVD Test Result_** will map to multiple LOINCs. The Vendor Result Description should be used to assist the laboratory in manually selecting the appropriate LOINC for their laboratory.
• Vendor Comment is human-readable text clarification, such as “This is a STAT (prioritized) version of the test”.

Note that Vendor Specimen Description, Vendor Result Description, and Vendor Comment are included to assist a laboratory in selecting the appropriate LOINC code(s) for the vendor IVD tests used by the laboratory. This information is not intended to be parsed by an IVD Software System that automates the mapping of vendor IVD transmission codes to LOINC codes. The inclusion of this information should reduce errors in the manual selection of LOINC codes by a laboratory.

LOINC Code System

For each of the LOINC codes being considered, a minimum set from the code system is included to further aid in the mapping process. These are included in the LIVD LOINC Code System profile.

• LOINC Code
• LOINC Long Name
• Component
• Property
• Time
• System
• Scale
• Method

Sample Data

As part of defining the whitepaper, IICC also developed a spreadsheets that contains the relevant data and a potential representation of that data that can be found here.

LIVD Data Mappings to FHIR

This guide is based on the HL7 FHIR standard and therefore uses terminology, notations and design principles that are specific to FHIR. Before continue reading this implementation guide, it’s important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.

• FHIR overview
• Developer’s introduction
• (or Clinical introduction)
• FHIR data types
• Using codes
• References between resources
• How to read resource & profile definitions
• Base resource

Overview

The concepts described above are mapped to a number of FHIR resource that have been profiled to support the scope of the LIVD Publication. The diagram below shows the HL7 FHIR resources/profiles and their relationship:

• LIVD Catalog Profile - This provides the information about the LIVD Publication. The profile is based on the Catalog profile based on the Composition resource. Note that, while the LIVD Catalog Profile does some organization of the resources, there is no need for representing the format of the data. The formatting and presentation is left to the client consuming these resources.
• LIVD Device Definition Profile - This profile reflects the equipment (device) that is represented in the publication. Each LIVD publication must include at least one device, and can be many.
• LIVD Device Observation Definition - This profile reflects the IVD test codes that each device can produce.
• LIVD Concept Map Profile - This profile supports the data necessary to document the actual mapping between the IVD test code for a device and the LOINC codes (0, 1, or more) to consider.
• LIVD LOINC Code System Profile - This profile supports the relevant LOINC code data to assist in the mapping process.

The LIVD Bundle Profile will enable packaging of the resources.

Detailed Mapping

The following table provides the mapping of LIVD data of interest to FHIR resource attributes. Note that the use of FHIR introduces additional attributes that either are needed as required elements in FHIR or provide additional capabilities.

LIVD Attribute	FHIR	Comments
Publication
Publisher	Composition.author.display
Publication Version ID	Composition.identifier.system Composition.identifier.value
LOINC Version ID	CodeSystem.version
LOINC Copyright	CodeSystem.copyright
	CodeSystem.publisher
	CodeSystem.status
	CodeSystem.title
	CodeSystem.name
Localization	Composition.language
Region	Composition.ext-region
	Composition.type
	Composition.status
	Composition.date
	Composition.title
	Composition.section
Equipment
Manufacturer	DeviceDefinition.manufacturerString
Model	DeviceDefinition.modelNumber
UID	DeviceDefinition.uidDeviceIdentifier.deviceIdentifier
UID Type	DeviceDefinition.udiDeviceIdentifier.issuer
	DeviceDefinition.udiDeviceIdentifier.jurisdiction
	DeviceDefintiion.capability.ext-observationDefinition
IVD Test Results,
Vendor Analyte Code Vendor Transmission Code Vendor Analyte Identifier	ObservationDefinition.code.system ObservationDefinition.code.code
Vendor Analyte Name	ObservationDefinition.code.display
Vendor Reference ID	ObservationDefinition.ext-vendorReferenceIdentifier
	ObservationDefinition.code.version
	ObservationDefinition.permittedDataType
	ObservationDefinition.method
	ObservationDefinition.quantitativeDetails
	ObservationDefinitio.validCodedValueSet
	ObservvationDefinition.ext-device
IVD Analyte Code - LOINC Mapping
Vendor Specimen Description ConceptMap.group.element.target.dependsOn.property ConceptMap.group.element.target.dependsOn.value
Vendor Result Description Binary Ordinal Nominal	ConceptMap.group.element.target.dependsOn.property ConceptMap.group.element.target.dependsOn.value
Vendor Comment	ConceptMap.group.element.target.comment
	ConceptMap.status
	ConceptMap.source
	ConceptMap.group.element.code
	ConceptMap.group.element.display
LOINC Code System
LOINC Code	CodeSystem.concept.code
LOINC Long Name	CodeSystem.concept.display
Component	CodeSystem.concept.property.code CodeSystem.concept.property.valueCoding.code
Property	CodeSystem.concept.property.code CodeSystem.concept.property.valueCoding.code
Time	CodeSystem.concept.property.code CodeSystem.concept.property.valueCoding.code
System	CodeSystem.concept.property.code CodeSystem.concept.property.valueCoding.code
Scale	CodeSystem.concept.property.code CodeSystem.concept.property.valueCoding.code
Method	CodeSystem.concept.property.code CodeSystem.concept.property.valueCoding.code
	CodeSystem.property
	CodeSystem.content