Across many domains, the meaning of a particular observation can be best understood in the context of the set of possible answers (result values). For example, the questions/items in standardized assessment instruments often have highly specialized, fixed answer lists. In many contexts, it is the answer list that most completely defines the meaning of the concept represented by the question. Additionally, because many of the answer choices are highly specialized, few are represented by existing codes in reference terminologies. For these reasons, we have created a structured representation of answer lists in LOINC.
We identify the binding of LOINC observation codes to answer lists as “normative”, “preferred”, or “example”.
Normative lists are those specifically defined by a validated instrument or other authoritative source. When using LOINC codes bound to normative answer lists, only answers in the specified set are allowed as result values. Examples of sources for Normative answer lists are PROMIS or the Clinical Pharmacogenetics Implementation Consortium (CPIC).
Preferred lists contain a set of answers that users are strongly encouraged to use. They represent a recommended set, however, in contrast to a Normative list, alternate result values may be used if necessary. Preferred lists may come from a variety of sources, including professional organizations (e.g., American Physical Therapy Association), device manufacturers, and government (e.g., Centers for Diseases Control and Prevention, National Eye Institute).
Example lists are meant to be illustrative of possible result values. Users can also think of them as a starter set to which they may add or subtract depending on their use case. Many of the Example answer lists are in the lab domain, where different labs may report similar results in a variety of ways, such as “Positive”, “Present”, “Detected”, “Abnormal” or “Out of range” but for which we have a single Example answer list.
Starting in the version 2.61 release, we have created a mechanism by which a single LOINC term may be linked to multiple answer lists with different binding strengths defined in the context of a given panel. For example, if two different survey instruments have the exact same question with two different answer lists, rather than making two different codes with different Methods, we now have the ability, within the context of a panel, to attach a different answer list to the same question. We will only use this mechanism when the meaning of the observation is the same across panels. If the observations represent different questions, we will make different codes. We will apply this format to new terms moving forward and plan to update existing terms over time.
Not all answer lists are fully enumerated within LOINC. For example, some questions may have their answers drawn from a large terminology such as ICD-9-CM or CPT and we do not reproduce those lists within the LOINC structure. Answer lists that are not enumerated within LOINC are flagged to indicate that they are externally defined. We record the answer list OID (whether assigned by Regenstrief or another organization) and optionally a URL pointing to the external system.
Individual answers are assigned a non-semantic identifier with a “LA” prefix and a mod-10 check digit (see Appendix C). The answer codes LOINC assigns are unique by lexical string (ignoring capitalization), and by intention do not distinguish between strings that may have different meanings depending on their contextual use.
LOINC answer lists are also assigned a non-semantic identifier with a “LL” prefix and a mod-10 check digit (see Appendix C). LOINC answer lists are available for viewing in the RELMA program and on details pages. There are details pages for each LOINC answer list, and the answer list also appear as a section of the details pages for LOINC terms they are associated with.
Beginning with LOINC version 2.61, answer lists (and answers) are also available in the Answer artifact, which is a separate download from the LOINC website. This file includes two tables: one includes all of the Answer lists (including information about each list as well as the answer strings it contains) that are associated with LOINC terms in the current release, and the second contains links between all of the LOINC terms that have answer lists and those lists. Please see the AnswerFile_Readme.txt document included in the AnswerFile for more information.
9.2.1 Null flavors in LOINC Answer lists
It is often necessary to indicate that a valid result value is not present. For example, a question on a questionnaire might have a set of response choices and then one choice at the end like “unknown”, “not applicable”, “not available”, etc. In HL7 standards, these kinds of response values are called null flavors (see https://terminology.hl7.org/6.1.0/CodeSystem-v3-NullFlavor.html).
There are two techniques for communicating a null flavor. In version 3 messaging, there is a dedicated nullFlavor attribute that is available for every observation, so these choices are not part of the actual answer list. In version 2 messaging and FHIR, the convention includes the specific allowed null flavors within the choices of the answer set. We can see advantages to both approaches.
Within LOINC, we do not want to make different answer lists that vary only by the inclusion or exclusion of certain null flavors. This is true even for Normative answer lists. Thus, our policy is to add specific null flavors as entries in the answer list where we are aware of their relevance. But, any LOINC answer list (including Normative lists) can be extended or limited by null flavors without violating the intended conformance that is specified through the binding. So, if a Normative answer list included an “unknown” answer choice, LOINC would not create a separate code for the same observation with “not available” in the answer list instead of “unknown”. From the perspective of conformance to the LOINC meaning, users are also free to make such substitutions, insertions, or exclusions of null flavor(s) in the answer list.