Each new LOINC® release that Regenstrief publishes contains many edits to LOINC terms. About 7,000 terms were edited in version 2.61 and about 11,000 in version 2.58. That’s a lot of change every six months!
How is it that all those edits don’t cause havoc to users who store data with LOINC? Here’s how you can track edits to LOINC terms.
Oriented by concepts
LOINC is a concept-based terminology, which means that it provides a way of naming classes of things that exist in the real world. Each concept (LOINC term) is given an identifier and a fully-specified name. LOINC concepts are designed to have a clear meaning. That is, they are not vague, ambiguous, nor redundant. The concept is anchored by the LOINC code, not by the particular strings in the formal name that we use to explain the code.
Along with the LOINC identifier (code) and fully specified name, LOINC includes many other term attributes. The full LOINC Table includes other names, such as a Short Name and Long Common Name, are details like example UCUM units, related names, class, formulas, rankings for common tests, and more.
Edits to LOINC terms: better with age
In a complex, organic terminology like LOINC, name changes and modifications are unavoidable for many reasons. Not all of the edits in a LOINC release affect the fully specified name. In fact, about 1,200 of the 7,000 edits in version 2.61 were for that primary name. The rest were edits to other fields in the LOINC Table.
Changes to LOINC term names are not made willy-nilly.
Since its inception, Regenstrief has maintained a set of editorial policies for LOINC to guide adherence to the concept-oriented ideal, even as the terminology evolves over time. The main over-arching policy is
Changes to the name (i.e. the human-readable representation of the concept) are allowed in any way that does not change the meaning of the concept.
In other words, an edit to a term name is allowable and valid if it is still an unambiguous reference to a class of things in the real world.
Name edits are meant to improve clarity and consistency for users. But, not all situations are crystal clear, so Regenstrief’s general approach is to seek as much input as is feasible. Often, such cases are brought for discussion to the LOINC Committee.
Stable meaning
Although LOINC term names may be edited over time, the concept meaning is persistent. LOINC codes are never reused or deleted.
If Regenstrief discovers that a LOINC term’s meaning duplicates another existing term or that it is erroneous somehow, the term Status with changed to DEPRECATED, but the term is not removed from the database. Of the two duplicate terms, Regenstrief’s approach is to change the term Status that would cause (in our estimation) the least amount of remapping for existing users.
LOINC term Status
LOINC signals to users which terms are valid for current use with the Status field. Here are the current options for LOINC term Status:
ACTIVE
Concept is active. Use at will.
TRIAL
Concept is experimental in nature. Use with caution as the concept and associated attributes may change.
DISCOURAGED
Concept is not recommended for current use. New mappings to this concept are discouraged; although existing mappings may continue to be valid in context.
DEPRECATED
Concept is deprecated. Concept should not be used, but it is retained in LOINC for historical purposes.
Changes in concept status are made very judiciously. For terms that are marked as DISCOURAGED or DEPRECATED, wherever possible, a superseding concept is indicated in the MAP_TO Table. The implication is that superseding concept should then be used both for new mappings and updating existing implementations. If there is more than one choice for a replacement (e.g. because the deprecated term was ambiguous), the COMMENT field of the MAP_TO table provides an explanation of why you might choose one replacement term or the other.
Tracking edits to LOINC terms over time
With each release, LOINC provides several tools for helping users track changes to terms.
In the LOINC Table
Within the main LOINC Table there are several fields for tracking changes:
VersionLastChanged
The LOINC version number in which the record has last changed.
CHNG_TYPE
A classification of the type of change that identifies whether the change was to the Component, another field of the full specified name, or some other kind of change.
STATUS
As discussed above.
STATUS_REASON
This field classifies the reason for concept status (e.g. AMBIGUOUS, DUPLICATE, or ERRONEOUS).
STATUS_TEXT
A narrative explanation of why the term has this concept Status.
CHANGE_REASON_PUBLIC
A detailed explanation about special changes to the term over time.
Changes in concept status are made very judiciously. For terms that are marked as DISCOURAGED or DEPRECATED, wherever possible, a superseding concept is indicated in the MAP_TO Table. The implication is that superseding concept should then be used both for new mappings and updating existing implementations. If there is more than one choice for a replacement (e.g. because the deprecated term was ambiguous), the COMMENT field of the MAP_TO table provides an explanation of why you might choose one replacement term or the other.
Line by line changes
LOINC Table Changes File
The LOINC Table Changes File has both and csv table and a Microsoft Access data that helps users track changes from one release to another.
The CSV table contains records for LOINC terms in which one of the fields of the fully specified name or the Class have changed since the last release. The Access database includes one table that matches the contents of the csv file. It also has a second table that contains LOINC terms have changes in the fields of the fully specified name, Class, or select other fields (e.g. Long Common Name, Short Name, OrderObs, DefinitionDescription). See the Updates_Readme.txt inside the LOINC Table Changes File for more information.
LOINC Table Changes Report
The LOINC Table Changes Report is a pdf report that highlights all the changes to the primary LOINC name fields since the last release. The report presents a nice “before” vs “after” layout of the fields from the last version to the current one. It’s designed for users who want to review these changes manually.
