11 - Editorial policies and procedures

This section last updated: 2021-06-01 (3 years ago)

11.1 Concept orientation and LOINC name changes

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 (term) is given an identifier and a fully-specified name. Other attributes, including other names such as a Short Name and Long Common Name, are also provided in the LOINC database. The concept is anchored by the LOINC code, not by the particular strings in the formal name we happen to use to explain the code. It is certainly not possible to convey all of the subtleties that exist in the world with formal machinery alone, which is why we are also working very hard to include narrative text descriptions with each term that further elaborate and explain the concept.

In a complex, organic terminology like LOINC, name changes and modifications are unavoidable for many reasons. Since its inception, LOINC has maintained a set of editorial policies that guide our adherence to this concept-oriented ideal even as the terminology evolves over time. An over-arching policy is that we can change the name (i.e. the human-readable representation of the concept) in any way that does not change the meaning of the concept. In other words, a modification is allowable and valid if it is still an unambiguous reference to a class of things in the real world.

For example, two different numbering systems have been used to identify the serotypes of Streptococcus pneumoniae, which are important in gauging the coverage of polyvalent pneumonia vaccines. The U.S. system uses only numbers while the Danish system includes numbers and letters. For a period of time, LOINC term names were split and used a mixture of the Danish and U.S. identifiers. Subsequently, we converted the few Danish serotype identifiers to their corresponding U.S. serotype identifiers. Even more recently, when we found out that the Danish nomenclature is, in fact, the one that is commonly used both internationally as well as in the U.S., and that the numbers assigned to serogroups and serotypes identified over the last several years made our existing terms ambiguous and confusing, we did a thorough review of our existing terms. As described in more detail in the Streptococcus pneumoniae serotype nomenclature technical brief, we deprecated all of the terms that were ambiguous and mapped them to new terms. In addition, we updated the names for the ones ones that were not ambiguous, because this was not a fundamental change to the underlying concept, but rather just the particular labels used to express it. Another example is when a microorganism genus and/or species are modified based on new knowledge or new sequence information (e.g., Clostridium difficile to Clostridioides difficile). In cases where the microorganism and its testing and disease process are the same but name has changed, LOINC will change the name of the Component and LOINC terms when and if 1) a preponderance of evidence in the literature and 2) a naming authority, such as International Committee on Taxonomy of Viruses (ICTV), supports the change.

Not all situations are crystal clear, so our general policy is to seek as much input as is feasible, and often, such cases are brought for discussion to the LOINC Committee.

11.2 Classification of LOINC term status

LOINC development follows best practices for terminology system development by never reusing or deleting codes. If a LOINC term is identified as erroneous or a duplicate of a previous term it is flagged as deprecated in the database, but the record is not removed. Changes in concept status are made very judiciously.

Prior to the LOINC version 2.31 release (June 2010), we identified such deprecated terms by populating the STATUS field of the database with DEL and wherever possible identified superseding concepts in the MAP_TO field of the LOINC Table. Active (non-deprecated) records had no value (null) in the STATUS field. Based on new use cases and input from the LOINC community, LOINC 2.31 implemented an expansion to that classification. The presently supported values for term Status, with the definition and implications for use, are:

Furthermore, LOINC 2.31 added two new fields:

Our initial implementation of these new concept status values in LOINC 2.31 populated the STATUS field with ACTIVE or DEPRECATED based on their existing status and have identified a limited set of terms that have been designated DISCOURAGED or TRIAL.

The principal reason identifying terms as DISCOURAGED is where we have strong inclinations that a particular term is no longer valid given current practice. For example, we have flagged as DISCOURAGED several lutropin terms with Properties consistent with mass or molar units because all lutropin sources that we could reach report concentrations in international units (IU) per volume and the drug lutropin is prescribed in terms of international units per volume. To avoid confusion on the part of mappers, the DISCOURAGED Status steers them away from these terms to the more likely candidates.

The principal reason for identifying terms as TRIAL is a very constrained circumstance, such as when the source of the term is still equivocating. This has been illustrated in our work to create a LOINC representation of federally-required patient assessment instruments. Here, the item meaning is defined in the context of use within that instrument. We have been fortunate to work with assessment developers in the early stages of instrument development. This is advantageous because it enables the codes to be included in data specifications and documents as they are developed, but we are in the position of creating codes and names for data elements whose attributes are still in flux. As the instrument evolves, the specific representation of the item (question) or answer options on the form may change. Ultimately, the representation will be settled by an authoritative body (such as CMS) and they are intended for use in one context – the official release of the instrument. Identifying these terms as TRIAL allows us to include them in the public distribution while clearly flagging their “pending” status. Once the final concept representation has been determined, terms initially labeled TRIAL would be reclassified as ACTIVE (or perhaps in rare circumstances DEPRECATED or even rarer DISCOURAGED).

In LOINC 2.42, the MAP_TO field of the LOINC Table was removed and replaced with a separate MapTo table. The original MAP_TO field was created to store a single replacement LOINC term number for when a LOINC was deprecated. We later learned that there were times when there was more than one possible replacement term, depending on certain conditions. To address this problem we created a new MapTo table that was first released with version 2.34. The original MAP_TO field was retained for a few releases, but was removed from the LOINC Table in version 2.42. See Appendix A for information about the MapTo table.

In rare cases, we have had to "undeprecate" DEPRECATED terms when upon further, very careful review, we discovered that the concepts are, in fact, valid. Such terms will revert back to a STATUS of ACTIVE but can be identified by the value UNDEL in the Chng_Type field. We have chosen to undeprecate the codes in such rare cases (instead of making new terms) because DEPRECATED terms continue to be included in the LOINC database, and some users may continue to use such concepts or have historical data associated with those codes. If we were to create new codes for the same concept, different users could potentially use different codes to identify the exact same data.

11.3 Concept persistence and term deprecation

LOINC codes are never reused or deleted, and the concept meaning is persistent over time despite the fact that there may be modifications to the name (as described above). If we discover that a LOINC term’s meaning is a duplicate of another existing term or it is somehow erroneous, it will be given a Status of DEPRECATED but not removed from the database.

In the past, when we encountered duplicate terms (i.e. terms that had different names but meant the same thing), our general policy was to deprecate the newest term. Many times, this convention worked well because the older term was more likely to have been incorporated into user’s systems through mappings, etc. However, this was not always the case. Sometimes, the new term had the clearer, more recognizable label and thus it was most likely the most mapped-to term. Therefore, our current policy is to make the change to require (in our estimation) the least amount of re-mapping for existing users.

Our general policy is not to make any edits to a term once it is DEPRECATED. However, in rare cases we may update one or more names of DEPRECATED terms in order for them to correctly represent the original meaning of the term. For example, in LOINC 2.66, the Long Common Name for 26693-2, which has the Component Streptococcus pneumoniae 12f Ab, was updated from Deprecated Streptococcus pneumoniae 12 Ab [Mass/volume] in Serum to Deprecated Streptococcus pneumoniae 12f Ab [Mass/volume] in Serum.

11.4 Publication of LOINC codes in advance of official releases

Supported by the LOINC Committee, Regenstrief has had a long-standing policy of returning new LOINC codes to those who made the request (i.e. the submitter) as soon as the LOINC term passes our internal QA processes rather than waiting for the next official release. The LOINC Committee has also approved Regenstrief's publication of the new codes on the LOINC website after they pass internal QA but in advance of the next official release. It is understood that providing these codes back to the requestor and listing them on the LOINC website is done for informational purposes only, with the additional caveat that the concept could change prior to inclusion in a public release.

The public should not be expected to have adopted such "pre-released" LOINC codes until they appear in a formal release. Yet, such an approach is valuable because it facilitates the inclusion of new codes in implementation guides and other documents and systems that have their own, often lengthy, development cycles.

11.5 File versioning and naming

Beginning with the June 2018 LOINC release, we implemented a policy on versioning and naming of LOINC release artifacts that was approved by the LOINC Committee. This policy includes approaches to version numbers, major versus minor (or patch) changes, and content versus file structure changes. See the LOINC Versioning page on our website for details.