This section last updated: 2020-06-16 (2 years ago)
In addition to the Fully Specified Name (FSN), which is the 5 or 6 major Parts of a LOINC term concatenated together using the colon character as a separator, each LOINC term has several different names that have been added as LOINC has evolved. Each of these was created for a different purpose and presently, they are generated programmatically with manual curation in special cases. We began with the Short Name and Long Common Name in 2002 and 2009, respectively.
Even after creating the Long Common Name, we continued to receive periodic requests from users to produce “prettier” display names for use in user interfaces, etc. While systematically created LOINC Long Common Names can be guaranteed to be unique (except for truly duplicate concepts), they are sometimes not the most user-friendly. This is also true for our automatically-generated LOINC Short Names. However, mostly what users wished for were names that leave out some of the defining attributes of the term (e.g. Property, Scale, and “default” specimens in the System) because they are unfamiliar to clinicians. This is problematic across all of LOINC because it would create ambiguous and duplicate names. For such reasons, we have always expected that users would link their own local preferred names to LOINC terms for use in reports and displays. Within a given local system context it may be possible to resolve the ambiguities created by names that omit these attributes. For example, if the user display always shows the reported units of measure, then having the Property in the display name may not be necessary.
However, we continued to think about how we could create a more "friendly" name and with the input of the LOINC Community, we developed the Consumer Name and Display Name as described below. We welcome feedback from anyone that has implemented or plans to implement these names.
In August 2002 we added the Short Name, which is a short, mixed case name for the LOINC concept. All laboratory and clinical LOINC terms have a Short Name. (Many survey LOINC terms do NOT have a Short Name). Our goal was to produce names no longer than 40 characters in order to fit within the space allocated by most laboratory reporting systems. In contrast to the LOINC FSN, case is significant in the LOINC Short Name. When possible, we have used common acronyms and common names rather than the more formal name rules of the FSN. For example, we used the English names of allergens in the short names rather than the formal Latin species names (in part because they were shorter). We have used all upper case to represent acronyms, and mixed case in organism names as specified in naming conventions (e.g., genus is capitalized, species is not). For virus names we used the acronym assigned by Index Virum, where available.
The LOINC Short Names are subject to change and should not be used as identifying keys in any database.
In 2009, after collecting and reviewing display names from several sources, we began releasing the Long Common Name. These names are also created by an algorithmic process and are checked for uniqueness. Most abbreviations and acronyms that are used in the LOINC FSN have been fully spelled out in English. For allergens, the common English names are used instead of the more formal Latin species names. For coagulation, the more commonly used phrases, such as “Prothrombin time”, have been used.
We started creating Long Common Names first for laboratory terms, but are now producing them for all terms. The text strings for the long common names are subject to change over time as we continue to refine the algorithmic process and collect feedback from users. In particular, many of the Long Common Names for clinical terms have not had as intense focus as the laboratory terms have, so we expect these to be refined over time. In LOINC release 2.54, many of the echocardiography and ophthalmology were updated based on input from DICOM and the National Eye Institute, respectively. Through the LOINC 2.65 release, every LOINC Long Common Name was unique. This was true even for deprecated duplicate terms, some of which had additional periods appended to their names in order to make them unique. However, the LOINC Committee recommended that concepts that are truly duplicate (i.e., have the exact same values for each of their major Parts) should have the same Long Common Name, and we have implemented this change starting with the LOINC 2.66 release.
Beginning with LOINC version 2.64, we began publishing Display Names, which were developed as a prototype for a more "clinician-friendly" set of names compared to the current LOINC Short Name, Long Common Name, and Fully Specified Name. They are created algorithmically from the manually crafted display text for each Part and are generally more concise than the Long Common Name. Currently only LOINC Laboratory terms have Display Names, though we may add Display Names for Clinical terms in the future.
In general, Display Names are unique for a given concept; however, in the case of truly duplicate concepts (i.e., have the exact same values for each of their major Parts), the Display Name will be the same. Unlike the Short Name and Long Common Name, the Display Name does not include an indicator that a term is deprecated.
Some of the high-level rules used to create the Display Names include:
The Consumer Name was originally hand-crafted for a very small subset of LOINC terms. At its inception, these names were labeled as "experimental". In 2019 we undertook a concerted effort to develop a more comprehensive set of consumer-friendly names, primarily based on the increasing availability of consumer-facing health and wellness apps that take advantage of existing LOINC codes for the underlying data.
Consumer Names are created based on manually crafted consumer name text for each Part. In contrast to the other names, this text may represent a more general concept for the defining Part. These names do not represent each of the defining Parts of a given term, are not unique, and do not include an indicator that a term is deprecated.
Some of the high-level rules used to create the Consumer Names include:
The current collection of Consumer Names have a "pre production" maturity level and we welcome user feedback about them. Until they reach production status, we plan to release them in a separate file rather than in the existing Consumer_Name field in the LOINC table.
We assign each LOINC term to a general category called a Class. These categories are relatively broad and are intended to make it easier to sort and browse the database. They are not intended to be binding definitional characteristics of the term, and we may refine them over time. A more detailed listing of the Classes is presented in Appendix B. Throughout this document many of the naming conventions and approaches are described in reference to a Class of terms. Here we provide a bit of explanation about some of the laboratory term Classes.
The Class of Microbiology includes all tests used to identify microorganisms and evidence for infection by specific organisms as well as cultures direct microscopic exams that identify organisms or prove evidence for present or past infection with specific organisms. Microbiology includes tests for antibodies, antigens, DNA and RNA. The Serology Class does not include measures antibodies or antigens related to microorganisms. Molecular pathology Class does not include RNA or DNA based tests for infectious organisms. (They are all included in Microbiology.)
The Class Blood bank includes all blood bank testing including ABO-Rh testing. Allergy Class includes testing for antibodies to allergens (cat dander, trees, etc.). Serology includes rheumatological, and autoantibodies, and antigen measures not covered by these two classes. Hematology/cell counts exclude coagulation studies that are found in a separate Class. Measures of complement activity are included within Hematology, not Chemistry. Chemistry does not include challenge tests such as Glucose tolerance, ACTH stimulation, etc.; these are in a separate category called Challenge tests.
LOINC terms can be matched to local test codes that fulfill different roles. For example, a LOINC code can be used to place an order, to report discrete observations, or in some cases a LOINC term can serve in both ways.
The purpose of the ORDER_OBS field in the LOINC database is to provide users with an idea of the intended use of the term by categorizing it as an order only, observation only, or both. A fourth category, Subset, is used for terms that are subsets of a panel but do not represent a collection of items that is known to be orderable. Our categorization of a term in this way is not a normative or binding resolution. That is, it is not a definitional attribute of the term. Rather, it represents Regenstrief’s best approximation of how the term is used. (If you feel a term should be categorized a different way, please let us know.)
In HL7 messages, the place in the message where the LOINC code is used will indicate what role the LOINC term is fulfilling. If it is in OBX-3, it is being used as an observation. If it is in OBR-4, it is an order.
Examples of each category include:
34531-4 Blood type and Crossmatch panel - Blood
This term represents an order for a type and cross that would never carry an answer (i.e., result value). Panel terms typically fall in the Order only category.
51890-2 Factor VIII units given [#]
This term is a discrete observation that would carry a result of the number of units given to the patient, but would never be placed as an order for ‘Factor VIII Units given’.
882-1 ABO and Rh group [Type] in Blood
This term could be used to place an order as well as report the result of the test (e.g., A Positive).
In the LOINC Table, a LOINC term can be linked to one or more optional "associated observations" in the AssociatedObservation field. Associated observations are additional variables that may be reported along with the primary observation. Within LOINC, we can link primary observation terms to other single LOINC terms or panels containing a set of terms.
There are three main use cases for linking LOINC terms to other associated observations:
Associated observations can be used in conjunction with lab results that are typically sent in an unstructured format, such as genetic testing results. We encourage laboratories to report as much data as they can using the discrete variable LOINC codes so that the data are more directly computable. For example, associated observations linked to a BRCA1 gene targeted mutation analysis may include concepts such as gene identifiers, the reason for genetic testing, genetic sequence variation that was found, genomic reference sequence, and specific version of the coding system that was used to report the results. At the same time, laboratories can still retain the flexibility of sending text reports that can be formatted for readability.
Many LOINC document codes can be used with one or more related HL7 CDA implementation guides (IG). To facilitate identifying which sections (and sometimes entry level codes) may be used with a particular document code, we are working to link a panel of associated observations for each IG.
Ask-at-order-entry (AOE) observations in LOINC are observations obtained from the requester as part of the test order and generally delivered back to the requester as part of the result package. For example, the concentration of inspired oxygen is always an AOE question for blood gas measurements as well as the date of last menstrual period for pap smears.
Within LOINC, we can connect AOE observations to the primary test using a similar structure as described for associated observations. The linkage between the primary observation and AOE observations is stored in the AskAtOrderEntry field of the LOINC Table. We have not implemented AOE observations extensively yet but have the mechanism in place, and we are working with multiple organizations to target specific domains, including infectious diseases and other public health domains such as lead testing.
The LOINC database includes a field (RELATEDNAMES2) for related names associated with LOINC terms. We provide these associations as a service to LOINC users to help them find the concepts they are searching for. We often colloquially use the word "synonym" when referring to related names, however, most of the terms in the RELATEDNAMES2 field are not true synonyms. Values in this field may include common names, abbreviations, previous nomenclature, common misspellings, allergen codes, and associated diseases. This information is intended to help users locate relevant concepts, but it may also result in "false-positive" search results due to overlap in the related names associated with different concepts. For example, one of the related names for Influenza is Flu, so searching for Flu will return LOINC codes relevant to Influenza. However, Flu is also associated with Fluid, so the same search for Flu will also return LOINC codes with the System of Body fluid, Amniotic fluid, etc.
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.
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://www.hl7.org/fhir/v3/NullFlavor/index.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.
In order to support several key aspects of development, Regenstrief has created LOINC parts, which are a coded representation of a value for a dimension used to specify a LOINC term. LOINC parts support the translation of LOINC terms into other languages, easy linking of synonyms across many terms, the creation of hierarchies to group related LOINC terms, and several other functions.
Individual LOINC parts are assigned a non-semantic identifier with a LP prefix and a mod-10 check digit.
The intended use of the LOINC parts and LOINC part hierarchies are to organize or be constituents of LOINC terms. As described in the LOINC license, they are not intended for use as a “standalone” terminology nor apart from LOINC terms.
Furthermore, LOINC parts and LOINC part hierarchies are not strictly managed under the same policies (e.g. concept orientation, concept permanence) as are LOINC terms.
Beginning with LOINC version 2.61, we are releasing a Part artifact as a separate download from the LOINC website. This file includes three tables: one includes all of the Parts associated with all of the LOINC terms in the current release, the second contains links between LOINC terms and their parts, and the third has mappings between a subset of Parts and related codes from external standard terminologies such as SNOMED CT. Please see the PartFile_Readme.txt document included in the PartFile for more information.
LOINC contains two types of descriptions, one at the Part level and one at the term level. Descriptions are attached to parts when the information is specific to the part, such as Component or Method, and they are attached to the term when the information applies to the term as a whole and not to any individual part of the term. For example, the Component part Glucose is associated with a description for the carbohydrate glucose, while the following term description describes the Peritoneal Equilibration Test, which applies to the combination of Glucose, Overnight dwell and Peritoneal dialysis fluid:
79264-8 Glucose [Moles/volume] in Peritoneal dialysis fluid --overnight dwell
A Peritoneal Equilibration Test (PET) is used to assess transport properties of the peritoneal membrane in patients undergoing peritoneal dialysis. Patients arrive at the dialysis unit in the morning with their overnight dwell fluid still in the abdomen. The overnight fluid is completely drained and sampled for testing. In the classic PET, 2000 ml of a 2.27% glucose solution is instilled and peritoneal dialysis is begun. Ten ml samples are drawn at time 0, 2, and 4 hours to measure creatinine, urea, and glucose. The PET assesses the rate of solute equilibration between peritoneal capillary blood and dialysate based on the ratio of the solute concentrations in dialysate and plasma (D/P). PET results are used to adjust various aspects of a patient's peritoneal dialysis regimen, including dwell time, number of exchanges, and dialysis volume and composition. [PubMed: 7474677]
Beginning with LOINC version 2.61, we are providing an artifact called LoincTableCore that is available as a separate download from the LOINC website. The purpose of this core table is to provide essential LOINC content in a format that is more stable over the long-run. The core table contains all of the LOINC terms that are in the complete table (i.e., the same number of rows), but a subset of the fields (i.e., different number of columns). The fields included in the core table are ones that are both crucial for defining each LOINC term and whose structure is not likely to change in the short-term. We are providing this format in order to make it easier for implementers to update to the latest LOINC release without having to make changes to their database structure. However, depending on their use case, some implementers may still need to refer to the complete LOINC table in order to find all of the relevant information.
Beginning with LOINC version 2.61, we are providing an artifact called Groups that is available as a separate download from the LOINC website. The goal of the LOINC groups project is to create a flexible, extensible, and computable mechanism for rolling up groups of LOINC codes for various purposes. Representative use cases include aggregating data for displaying on a flowsheet within an EHR system, retrieving data for quality measure reporting, and collecting data for research. This is a work in progress and the contents of the file and the groupings MUST be validated by users prior to implementation in any aspect of clinical care. Please see the GroupFile_Readme.txt document contained in the GroupFile for more information.