12 - Recommendations for best practices in using and mapping to LOINC

This section last updated: 2023-08-15 (8 months ago)

12.1 Business rules for users mapping their local panels to LOINC panels

Through discussion with the ACLA, the S&I Framework aLOINC Order Code Initiative, and others, the LOINC Committee has vetted a set of business rules to help LOINC users understand how to compare their panels to a LOINC panel. These rules help clarify what variation is allowed within the LOINC panel definition that still constitutes a “match” for their panel. In these rules, we use “element” to mean a child LOINC that is a member of the panel definition.

12.1.1 Must contain all of the required elements

To establish equivalence (e.g. for mapping), a user panel must contain all of the required elements of a LOINC panel. Some of the other business rules define allowable substitutions, but the general rule is that all required elements must be present in the user panel.

12.1.2 No extra primary measurements

A user panel cannot be considered equivalent to a LOINC panel term if it contains additional primary measured tests that are not part of the LOINC panel definition.

In Fall 2020, the Laboratory LOINC Committee decided that an exception to this rule includes LOINC panels that contain terms that are representative for the type of testing being done but where the specific list of analytes tested may vary across geographic region or laboratory. In this case, it is the reporting laboratory's responsibility to use the set of LOINC codes that are appropriate for reporting the results for the individual tests performed, even if all of those LOINC codes are not included in the LOINC panel. Examples of such panels include:

• Allergen panels that representing testing for individual components within an allergen category, such as 49222-3 Food allergen panel - Serum and 51662-5 Core respiratory allergens panel - Serum
• Autoimmune serology panels that represent testing for autoantibodies associated with a particular category of autoimmune disorders , such as 94708-5 Encephalopathy autoimmune Ab panel - Cerebral spinal fluid and 94712-7 Movement disorder autoimmune Ab panel - Cerebral spinal fluid
• Multiplex microbiology panels that represent testing for microorganisms associated with infections of a specific body region, such as 88569-9 Ocular pathogens panel - Cornea or Conjunctiva Qualitative by NAA with probe detection and 92695-6 Gastrointestinal bacterial pathogens panel - Stool by NAA with probe detection

12.1.3 Optional elements are optional

A user panel can be considered equivalent to a LOINC panel term whether or not it contains the elements marked as optional in the LOINC panel definition.

12.1.4 Substitutions related to Method

Panel elements that do not contain a Method specification (i.e. the Type of Method part is null) can be treated as a “representative” term that a user could replace with another LOINC term that differed only by specification of Method.

For example, LOINC contains an adenovirus panel:

55160-6 Adenovirus IgG and IgM panel - Serum

with two elements that lack Method specification:

13914-7 Adenovirus IgG Ab [Units/volume] in Serum

5042-7 Adenovirus IgM Ab [Units/volume] in Serum

If a user had a local panel that was similar but had instead mapped to terms that specified the Method of EIA, they may wonder whether their panel was equivalent to the panel in LOINC. Using this business rule, the answer is yes. Either or both of the methodless LOINC panel elements could be replaced by these method-specific LOINC terms that are equivalent on the other attributes:

51822-5 Adenovirus IgG Ab [Units/volume] in Serum by Immunoassay

51823-3 Adenovirus IgM Ab [Units/volume] in Serum by Immunoassay

However, when a panel element measures an analyte by a particular method, then the LOINC term reported for that analyte would have to be done by that method. Neither replacement by a methodless term nor by a different method would be allowed.

12.1.5 Substitutions for mass versus substance Properties

LOINC defines different terms that distinguish between mass-based and substance-based (moles/milliequivalents) measures for a single analyte. Different jurisdictions vary in whether they favor reporting in mass units (e.g. mg/dL) or molar units (e.g. mmol/L) for certain analytes.

In order to promote the international reuse of panels, the LOINC Committee has agreed (at its June 2015 meeting) to allow users to substitute panel elements that a) agree on all other LOINC parts, and b) contain an analogous molar Property to a reference element with a mass Property or vice versa.

To illustrate, panel element terms with the Property of mass concentration (MCnc) could be replaced by substance concentration (SCnc) terms, mass rate (MRat) terms could be replaced by substance rate (SRat), terms etc. For example, in the Lipid panel with direct LDL - Serum or Plasma (LOINC: 57698-3) a user could make substitutions as below and still have a comparable panel:

And so forth.

12.1.6 No substitutions of quantitative/semi-quantitative for qualitative (and vice versa)

A quantitative or semi-quantitative panel element (e.g. one that has a Scale of Qn or SemiQn) cannot be replaced by a qualitative term (e.g. one that has a Scale of Ord) and have the panel be considered equivalent. Likewise, qualitative terms cannot be replaced by quantitative terms in the panel definition.

12.1.7 Panels and reflex (reflexive) testing

LOINC contains a small number of panels specifying the inclusion of reflex (or reflexive) testing. Some of these were created to take the American Medical Association's reflexive CPT codes into account, and some were for very specific testing algorithms as recommended by professional organizations. In May 2020, the Lab LOINC committee decided that going forward, panel names would not specify reflex testing (i.e., the Component will not contain "W Reflex"), and that existing and future panels that contain the appropriate concepts for the testing being done could serve as reflex panels regardless of the name. We continue to review and update the names and required/optional/conditional elements of existing panels, and we welcome your input regarding panels that need review.

12.1.8 Special case of differential counts (including conventions for not reporting zero counts)

Panels, like blood differential counts and urinalyses, for which zero counts (e.g. for the % of blast cells) are usually not reported explicitly present a special case. These are included in the panel definition but are marked as conditional (C) to signal that under some circumstances (e.g., when they have a value of zero), they are not reported. Differential counts present another problem in that a given cell type could be reported as a fraction of the total WBC and/or as an absolute count, so both species are included in the panel for differential counts, but as discussed above, both are not required in the report.

12.1.9 Panels with only narrative definitions of the elements they should contain

As described above, in certain special cases, such as public health and veterinary testing, LOINC may define a panel term by a narrative definition rather than enumerating the set of child elements. In such cases, the user must read the definition and use their professional judgment as to whether or not their local panel is comparable to the LOINC panel.

12.1.10 Substitutions related to System

Panel elements with a general System may be replaced with other LOINC terms that only differ by having a more specific System. For example, terms with a System of Respiratory.upper may be replaced with LOINC terms with a System of Nph (nasopharynx), Throat, or Nose, and terms with a System of Genital may be replaced with LOINC terms with a System of Vag (vaginal), Cvx (cervix), Urethra, etc. Substitutions with terms that have less specific Systems are NOT allowed; for example, you may not substitute a term with System of Respiratory for a Sputum term.

Substitutions with terms with unrelated Systems are also NOT allowed, such as substituting a LOINC term with System CSF for a term with System Ser/Plas, or substituting a term with System Urine for a term with System Respiratory.

The following table illustrates acceptable substitutions related to System.

12.1.11 Single primary results

If a single primary result (either measured or derived) is being reported along with secondary results that serve as supportive or interpretive findings, the LOINC code for the primary result should be used as the order code. For example, if the ratio of an analyte to creatinine is the primary result but is report along with the creatinine result, the LOINC term for the ratio should be used as the order and a LOINC panel will not be created. This recommendation was agreed upon by the Laboratory LOINC Committee in March 2021.

12.2 Examples of applying the business rules for users mapping their local panels to LOINC panels

12.2.1 Comparison Panel: Varicella zoster virus IgG and IgM panel - Serum (LOINC: 45063-5)

This user-defined panel is considered comparable since the component tests are the same and it is acceptable to use method-specific LOINC codes for panels defined with methodless LOINC codes.

Elements of LOINC Panel

Elements of User-defined Panel

12.2.2 Comparison Panel: Creatine kinase panel - Serum or Plasma (LOINC: 24335-2)

This user-defined panel is not considered to be comparable since it includes two additional measured components that are not in the LOINC Panel.

Elements of LOINC Panel

Elements of User-defined Panel

12.2.3 Comparison Panel: Drugs of abuse 5 panel - Urine by Screen method (LOINC: 65750-2)

This user-defined panel is considered to be comparable since the components use the same method-specific LOINC terms and the additional test is a non-measured component (i.e., it is a variable provided by the requester that is echoed back with the results).

Elements of LOINC Panel

Elements of User-defined Panel

12.3 Querying LOINC and creating intensional value set definitions based on LOINC database structure

Specifications that contain queries meant to be run on the LOINC distribution or that contain intensional value set definitions should be expressed with the LOINC attributes contained in Appendix A - LOINC Database Structure. (In JSON representations such as HL7's FHIR, the LOINC attribute serves as the key in an object's property definition. Not to be confused with the LOINC notion of Property, in JSON, a key-value pair is often referred to as a property). The available LOINC attributes are the field names listed in bold in LOINC Database Structure section. Unless Regenstrief publishes a definitive specification otherwise (see discussion of canonical LOINC representation in FHIR below), these names, and their spellings, are the official attribute names. For example, specifying the set of LOINC terms with a scale of document would reference the LOINC attribute SCALE_TYP and its value of DOC.

In addition, for LOINC codes that are part of the Document Ontology or those that are radiology procedure codes, there are additional attributes that may be used in attribute-based Value Set Definition components. All attributes will have string values that may be used for the attribute (property) value part of the definition. Some will also have coded identifiers (e.g. LOINC Part codes) that can be used in addition to the string.

For Document Ontology:

• Document.Kind
• Document.TypeOfService
• Document.Setting
• Document.Role
• Document.SubjectMatterDomain

These Document Ontology attributes are currently published in the accessory Document Ontology File (available as a separate download from the LOINC website), and will likely be extended in the future. They will always be the unique values in the PartTypeName field of the Document Ontology File. Starting with the LOINC version 2.61, these are also published in the LOINC Part File artifact (also available as a separate download).

For Radiology:

• Rad.Guidance for.Presence
• Rad.Guidance for.Approach
• Rad.Guidance for.Action
• Rad.Guidance for.Object
• Rad.View.Aggregation
• Rad.View.View type
• Rad.Reason for Exam
• Rad.Maneuver.Maneuver type
• Rad.Timing
• Rad.Pharmaceutical.Substance Given
• Rad.Pharmaceutical.Route
• Rad.Anatomic Location.Region Imaged
• Rad.Anatomic Location.Laterality.Presence
• Rad.Anatomic Location.Laterality
• Rad.Anatomic Location.Imaging Focus
• Rad.Modality.Modality type
• Rad.Modality.Modality subtype
• Rad.Subject

These radiology attributes are published in the PartTypeName field of both the LOINC/RSNA Radiology Playbook File and the LOINC Part File. Both of these artifacts are available as a separate download from the LOINC website.

12.3.1 Canonical representation of LOINC as a FHIR CodeSystem

Together with the HL7 FHIR® team, we are working to create a specification for the canonical representation of LOINC in FHIR as a CodeSystem resource. This is a work in progress. An initial draft of that specification is available at https://loinc.org/fhir/loinc.xml.

This specification is specific to HL7 FHIR®, and it's definitions of the LOINC attributes would supercede the general guidance about names for attributes (properties) given above. For example, in the canonical representation for FHIR, the radiology LOINC attribute Rad.View.Aggregation will be named closer to the conventions for FHIR-style property names as "rad-view-aggregation".

12.4 The Code System for identifiers assigned by LOINC

All of the identifiers assigned by LOINC, including LOINC codes, Part codes (i.e. LP* codes), Answer codes (i.e. LA* codes), Answer List codes (i.e. LL* codes), and Group codes (i.e. LG codes) collectively belong to the LOINC code system. Depending on your technology or application, you may identify the code system in different ways. For example, in HL7 Version 2 it would typically be the abbreviation "LN", in CDA documents it would be an OID (2.16.840.1.113883.6.1), and in FHIR it would be the URI "http://loinc.org".

12.5 LOINC term names in HL7 messages

Messaging standards like HL7 typically use a triplet <identifier code>^<descriptive text>^<coding system> for fields that contain coded entries, such as the OBX-3 Observation Identifier field. Given that LOINC now produces at least 3 names for each term (i.e., the six-part Fully-Specified Name, Short Name, and Long Common Name), users have wondered which LOINC name they should use in the <descriptive text> part of that field (or the equivalent displayName attribute in HL7 V3).

Regenstrief and the LOINC Committee assert that best practice is to send the Long Common Name to accompany the LOINC code in messaging. The Long Common Name is complete, unambiguous, and the most understandable LOINC description for human readers.

We recognize that there may still be some information systems today that are not able to accommodate the character length of the Long Common Name. We strongly recommend updating such systems to accommodate longer names. The LOINC Short Name is smaller in size, but not very human friendly and is not populated for all LOINC terms. (We are working to improve on both of these issues). Using the Fully-Specified Name (e.g. a colon-separated aggregate of the six part name) is generally not recommended because they are not as human friendly and contain more instances of ‘reserved characters’ like “^” and “&”, which would need to be properly escaped in the message.

Furthermore, we recommend the simultaneous communication of the sender’s local code and local name (in addition to the LOINC code and name) as allowed in the messaging structure to facilitate debugging and detection of mis-mappings. Laboratory local codes are often required to be sent by the performing laboratory to meet CLIA (U.S) and laboratory accreditation regulatory requirements in many countries.

It is also worth noting that use of the Long Common Name in messaging does not dictate which test name is displayed in user interfaces to clinicians. There are often regulatory requirements and/or local policies that influence what is shown to clinicians. Many of the implementations around the world using LOINC have a local “interface name” that users see. LOINC is working in the background.

12.6 Updating to new versions of LOINC

At the December 2015 Lab LOINC Committee meeting. Regenstrief and the LOINC Committee approved the following best practice:

We recommend that users update to the current version of LOINC within 90 days of its publication.

12.7 Using URIs to identify LOINC artifacts

In the context of RDF, OWL, and other technologies, URIs are the expected type of identifiers. Some LOINC users have asked for an approved convention for referring to LOINC-created identifiers (e.g. LOINC codes, LOINC Answer List Codes, LOINC Answer String Codes, etc). Here we describe approved patterns for use. Please note that this is an active area of discussion.

12.7.1 Using a URI to identify LOINC as a code system

In HL7 FHIR®, code systems are identified by URIs. As described in the section on LOINC as a code system, the recommended URI for this purpose is:

http://loinc.org

12.7.2 Using a URI to identify LOINC concepts as resources in RDF

The subject of an RDF statement is a uniform resource identifier (URI), or a blank node. After discussion at the Clinical LOINC Committee meeting in August 2015, we agreed to the following patterns:

For LOINC Terms:

http://loinc.org/rdf/{LOINC code}
e.g., http://loinc.org/rdf/2352-3

For LOINC Parts:

http://loinc.org/rdf/{LOINC Part code}
e.g., http://loinc.org/rdf/LP6990-8

In our current platform, URLs of these patterns resolve to the concept details pages (as used by search.loinc.org and RELMA).

Note: prior versions ofthe FHIR standard listed the preferred LOINC pattern as "http://loinc.org/owl". The current version of FHIR has updated that guidance to be consistent with our recommendations in this document.

12.7.3 Using a URI to identify LOINC concepts as a value set

In some contexts, LOINC Parts, LOINC Answer Lists, and LOINC Groups represent value sets. LOINC represents the Component by System Hierarchy as a tree where LOINC Parts comprise all of the branches and LOINC terms comprise all of the leaf nodes. LOINC Answer Lists represent collections of coded concepts that can be used as response values to LOINC terms. LOINC Groups aggregate a set of LOINC terms that share certain characteristics. In these cases, LOINC defines an implicit value set associated with the code (e.g. a LP* code, a LL* code, or an LG* code).

Here we define a convention to make explicit when you are referring to these entities as either a) a code in the terminology or b) the implicit value set associated with the code.

When referencing the code itself, follow the usual pattern of referencing identifiers from the LOINC code system.

When referencing the implicit value set, use this pattern for the value set identifier as a URI: http://loinc.org/vs/{id}

For LOINC Parts:

http://loinc.org/vs/{LOINC Part code}
e.g., http://loinc.org/vs/LP148409-8

For LOINC Answer Lists:

http://loinc.org/vs/{LOINC Answer List code}
e.g., http://loinc.org/vs/LL715-4

For LOINC Groups:

http://loinc.org/vs/{LOINC Group code}
e.g., http://loinc.org/vs/LG9568-9