LOINC – IVD Test Code (LIVD) Mapping, published by HL7 International / Orders and Observations. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/livd/ and changes regularly. See the Directory of published versions

LIVD Data Mapping 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 continuing to read 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 resources 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 Bundle - Packages all relevant resources of the LIVD Catalog.
• 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.
  • (A) Each LIVD publication must include at least one device, and can cover many.
• LIVD Device Observation Definition - This profile reflects the IVD Test Performeds that each device can produce.
  • (B) Each LIVD Device Definition has the capability to perform at least one observation, i.e., IVD Test Performed.
• LIVD Test Concept Map Profile - This profile supports the data necessary to document the actual mapping between the IVD Test Performed for a device and the LOINC codes to consider.
  • (C) A LIVD Test Concept Map must be associated with at least one LIVD Device Definition. It may represent multiple LIVD Device Definitions where, e.g., different models performing the same tests could share the same map.
  • The ConceptMap.source reflects the IVD Test Performed's code and must exist (D) as a LIVD Device Observation Definition.
  • The ConceptMap.target reflects the LOINC code that the IVD Test Performed's code maps to, as well as context information to aid in the mapping such as result, specimen or other considerations.
    • An IVD Test Performed may not have a mapping (e.g., no LOINC code available yet), one, or more.
• LIVD LOINC Value Set Profile - This profile supports the applicable LOINC codes from the LOINC Code System that is relevant to the mapping process. * (E) Each LOINC code in the LIVD Test Concept Map must exist in the LIVD LOINC Value Set.
• LIVD LOINC Code System Profile - This profile supports the relevant LOINC Code System data to assist in the mapping process. This enables the mapping process to be off-line as needed.
  • (F) Each LOINC Code in the LIVD LOINC Value Set must exist in the LIVD LOINC Code System
• LIVD Coded Result Value Set Sub-Set Profile - This profile supports the non-quantitative, coded values that an IVD Test can yield as the observation value.
  • (G) Each LIVD Device Observation Definition can only reference one Result Value Value Set Sub Set.
  • (H) Each LIVD Coded Result Value Value Set Sub Set may further reference another LIVD Coded Result Value Value Set Sub Set to ease configuration and re-use.
• LIVD Coded Result Value Code System Profile - This profile contains the full set of result values used across devices sharing the same result value definitions.
  • (I) Each LIVD Coded Result Value in the LIVD Coded Result Value Value Set Sub Set must exist in the LIVD Coded Result Value Code System
• LIVD Coded Result Value Value Set Super-Set Profile - This profile is used to eas the mapping definitions by aggregating the all LIVD Coded Result Values to be mapped.
  • (J) Each LIVD Coded Result Value in the LIVD Coded Result Value Value Set Super Set must exist in the LIVD Coded Result Value Code System
• LIVD Coded Result Value Concept Map Profile - This profile contains the mappings from the IVD Test Coded Result Values to the respective SNOMED and/or LOINC codes
  • The ConceptMap.source reflects the IVD Coded Result Value and must exist in the LIVD Coded Result Value Value Set Super Set (K) in the context of the LIVD Coded Result Value Value Set Subset (L) for the LIVD Device Observation Definition at hand.
  • The ConceptMap.target reflects the SNOMED and/or LOINC Answer codes that the IVD Test's code maps to. Although an IVD Coded Result Value can have both a SNOMED and a LOINC Answer code representation, it can only be mapped to one or the other based on for the actual coded result value for the test performed.
• LIVD LOINC Answer Value Set Profile - This profile supports the applicable LOINC codes from the LOINC Code System that is relevant to the mapping process.
  • (M) Each LOINC code in the LIVD Coded Result Value Concept Map must exist in the LIVD LOINC Answer Value Set or the LIVD SNOMED Value Set.
  • (N) Each LIVD LOINC Answer code must exist in the LIVD LOINC Code System.
• LIVD SNOMED Code System Profile - This profile supports the relevant SNOMED Code System data to assist in the mapping process. This enables the mapping process to be off-line as needed.
  • (O) Each LIVD SNOMED code must exist in the LIVD SNOMED Code Sysetm.

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.

</table>

LIVD Attribute	FHIR	Comments
	Bundle.type	This is set to "collection" as LIVD is modeled in FHIR to serve as a payload while it is not needed to be in the form of a document either, thus a well structured collection.
Publication
Publisher - the entity publishing the mapping information	Composition.author.display
Publication Version ID - human-readable information provided by the vendor that can be used to differentiate LIVD Publication versions	Composition.identifier.system Composition.identifier.value Composition.assigner.display
	Composition.type.coding.code Composition.type.coding.display Composition.type.coding.version Composition.type.coding.system	This represents only the LOINC Code representing this publication is a LIVD Catalog. It does not reflect the version of the LOINC code used in the detailed mapping.
LOINC Version ID - the version of LOINC that was used for the mapping	ValueSet.expansion.contains.system.version	Since a LIVD Catalog can include LOINC codes from different versions
LOINC Copyright - holds the required attribution statement	Composition.section.title Composition.section.code Composition.section.entry.reference	The relevant copyright text is in .section.entry.reference where the .section.title is "Copyrights" and the section.code is "copy-right".
Localization - the language used for this LIVD Publication	extension-Composition.language
Region - an optional vendor description for which geographic or administrative region this localization is valid.	extension-Composition.region
	Composition.extension-version
	Composition.status
	Composition.date
	Composition.title
	extension-Composition.note
	Composition.section	This enables organization like information together, particularly the equipment, tests, and mappings. </tr>
Equipment
	DeviceDefinition.identifier
Manufacturer - the name of the manufacturer of the device.	DeviceDefinition.manufacturerString
Model - the model of the device as provided by the manufacturer	DeviceDefinition.modelNumber
Testkit UID - the unique device identifier, that may be the one used in the Unique Device Identifier (UDI) constructs	DeviceDefinition.udiDeviceIdentifier.deviceIdentifier
Testkit UID Type - capable of supporting the unique device identification system to identify medical devices through their distribution and use.	DeviceDefinition.udiDeviceIdentifier.issuer
	DeviceDefinition.udiDeviceIdentifier.jurisdiction
	DeviceDefinition.capability.type extension-DeviceDefinition.capability.observationDefinition	This enables a linkage to the ObservationDefinition that represents the test that the device can perform.
	extension-DeviceDefinition.classification
	extension-DeviceDefinition.hasPart
IVD Test Performed,
Vendor Analyte Code - Vendor Transmission Code for automated tests or Vendor Analyte Identifier for manual tests.	ObservationDefinition.coding.code.system ObservationDefinition.coding.code.code
Vendor Analyte Name - human-readable text the vendor used to identify the analyte	ObservationDefinition.coding.code.display
Vendor Reference ID - an additional vendor identifier, such as an identifier that can be used to locate the associated assay insert published by the vendor.	ObservationDefinition.identifier.type ObservationDefinition.identifiervalue
	extension-ObservationDefinition.device	This enables a link to the device(s) that can perform this test
IVD Analyte Code - LOINC Mapping
LOINC Mapping Version	ConceptMap.group.element.target.version
	ConceptMap.identifier
Vendor Specimen Description - human-readable text that provides information about the specimen used for the test, such as “Serum or Plasma.”	ConceptMap.group.element.target.dependsOn:specimen.property ConceptMap.group.element.target.dependsOn:specimen.value
Vendor Result Description - human-readable text that provides information about the result that is produce Binary Ordinal Nominal	ConceptMap.group.element.target.dependsOn:result.property ConceptMap.group.element.target.dependsOn:result.value
Vendor Device Description	ConceptMap.group.element.target.dependsOn:device.property ConceptMap.group.element.target.dependsOn:device.value
Vendor Comment - human-readable text clarification, such as “This is a STAT (prioritized) version of the test”.	TestCodeConceptMap.group.element.target.dependsOn:other.property TestCodeConceptMap.group.element.target.dependsOn:other.value
	ConceptMap.status
	ConceptMap.source
	ConceptMap.target	This represents the target value set where the suggested LOINC codes are further defined.
	ConceptMap.group.target ConceptMap.group.targetVerion	This represents the LOINC code system and the version that was used for the mapping to the LOINC codes referenced.
	ConceptMap.group.element.code	This represents the test code used by the manufacturer for which a mapping to a LOINC is provided.
	ConceptMap.group.element.target.display
Test Result Values
Vendor Test Result Value Code	to be provided
Vendor Test Result Value Code Name	to be provided
Vendor Test Result Value Coding System	to be provided
LOINC Code System
Test Code Value Set
	ValueSet.version
	ValueSet.status
LOINC Code	ValueSet.expansion.contains.code
LOINC Long Name	ValueSet.expansion.contains.display
	ValueSet.expansion.contains.system
Component, Property, time Aspect, System, Scale Type, Method Type	extension-ValueSet.expansion.conctains.extR5-property.code ("COMPONENT", "PROPERTY", "TIME ASPCT", "SYSTEM", "SCALE TYPE", "METHOD") extension-ValueSet.expansion.conctains.extR5-property.valueCoding.code