In some terminologies, there is an effective date (perhaps with a different name) that indicates when the term first started being used and an expiration date which can show the date at which the term is no longer in use.
Loinc doesn’t have dates in the csv files. It has a version. Is it valid to transpose the date of the version as the effective/expiration dates? Or should we only use the version, bearing in mind that our source date with Loinc will not necessarily include a version.
HI Ruth,
I am not entirely certain I understand what yo means when you say " the date at which the term is no longer in use."
In order to answer this question, we need to look at several fields in LOINC:
Version first released
VersionLastChanged
CHNG_TYPE
Status
The LOINC Status definitions are found here ( Knowledge Base – LOINC)
| Status | Description |
|---|---|
| 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. Wherever possible, the superseding concept is indicated in the MAP_TO field of the MapTo Table (see Appendix A) and should be used instead.|
|DEPRECATED|Concept is deprecated. Concept should not be used, but it is retained in LOINC for historical purposes. Wherever possible, the superseding concept is indicated in the MAP_TO field of the MapTo Table (see Appendix A) and should be used both for new mappings and updating existing implementations.|
Here is where it can be a little confusing. A LOINC code could have a Version first released of 2.72 but have been created with a trial status which basically means, use at your own risk. Conversely a LOINC code could be changed from Active to Discouraged in version 2.74 and all this means is that the LOINC code is no longer appropriate for use in new mappings, but is valid to remain in legacy mappings.
Unfortunately, LOINC is a little more complex when it comes to determining if a code may still be used.
I hope this helps.
Thanks
John
Good morning,
In addition to what John indicates there are a few other points that might be helpful.
-
Best practice is for LOINC codes to be adopted within 90 days of a release as indicated in the User Guide and online Knowledgebase. “The LOINC Committee recommends updating content within 90 days of a LOINC release.” This includes any changes in a code with the statuses John mentioned. A number of mappers, terminology providers, and other LOINC users, will review the LOINC difference report to identify which codes have changes, the list of new LOINC codes, and then review which are in use in their implementations to see if any changes are needed in their implementations. For example, if a LOINC is deprecated and a map to is listed for another LOINC code in the event the first LOINC was a duplicate, implementers may need to remap to the second LOINC.
-
LOINC codes do not have an expiration date. Some codes when first released “went into effect” and continue to be in effect until one of the status John mentions changes.
-
Messaging standards such as HL7 FHIR, use “effective date” as a generic term to describe all kinds of dates for data. It is generic as many resources and implementation guides are used for many different purposes, use cases, or scenarios. The term is not great for some areas, such as laboratory data. Some may ask similar questions about the meaning of effective date. Is it the date and time a specimen is drawn, when a laboratory order is placed, when a laboratory test is performed, when a laboratory test is resulted, etc. As you can see using such a generic term for many specific needs really muddies the water and can cause confusion and ambiguity, especially with regard to what it really means and how the value is intended to be used. HL7’s process is to have folks submit ballot comments on resources and IGs with requests for changes, which are then reviewed by workgroups and voted up or down.
2 Likes
I am looking at this from the retrospective point of view for historical data. The answers and concerns you raise are from the point of view of adopting a Loinc® code. What I have decided, based on this, is that there could be two approaches. One approach is to look at when the code was first introduced and if I were to find a record that uses the same code before that date (or in data I don’t have if the source provided an earlier version) that would mean that there is some kind of quality issue. A second approach is to simply ignore the effective date of the code (which would correspond to the release date of the version plus or minus a number of days ) and the status. As long as the code matches to any code in Loinc® then it is a valid code.
1 Like
How are you planning to use the date info? What question are you trying to answer? Is it to understand if a mapped LOINC on historic data is valid? If it is to determine if a code is a valid LOINC, there is also the check digit verification.
1 Like
HI Ruth,
I agree with @pitk0006 response that I am uncertain what the use case is that your describing and am not entire certain what is meant by saying “Valid LOINC Code”.
If you are simply trying to determine if a LOINC code is truly a LOINC code and not a CDC Race Ethnicity code as both code systems use a similar syntax of “XXXXX-X”, then validating the check digit as Andrea indicates would be an appropriate solution.
If you are trying to determine if a LOINC code was available for use at a certain point of time in a data stream, then using the release date for the “Version first released” is a valid approach. You will need to take into consideration that a LOINC code may have been authored and available for provisional use at any time during an authoring cycle so it could potentially have been valid and available for use anytime during the 6 months prior to the release date for the “version first released”. You will also need to take into account that LOINC shift release cycles from June/December to September/February for Version 2.71 in August 2021.
1 Like
I apologize for not replying earlier. The use case I was looking at is : a lab record from 10 years ago is researched and the LOINC code is matched to the code in the record. Would it matter (to the researcher) if that Loinc actually didn’t exist at the time the lab was done? If it did matter that the lab from 2015 had a code that wasn’t introduced in any form to loinc until 2023; your answer is that they could use the release date and version. I think that suffices.
Hello,
There are many historic records where a valid LOINC was mapped, but may have had a status change to deprecated or discouraged, but they still were valid LOINCs at the time the data was encoded. They shouldn’t be used going forward, but ok that they are on historic data.
There are many lab tests, orders or results, and other surveys, etc. where LOINC codes do not yet exist. LOINC is dependent on folks requesting codes for existing or new terms, methods, etc. In these cases, terms may not have been mapped if there was no available LOINC (e.g. Before COVID, there were no specific COVID LOINCs). They emerged in 2020. There were however Coronovirus tests (broader for any, not just SARS COV2), which initially identified cases.
Sounds like you might have a different use case in mind? Why do you need the dates/what problem are you trying to solve?
The problem I was looking at , when I entered this a year ago, no longer exists. I have moved on. I did provide the use case. For historical data with a loinc code- how would I rate the validity of the code at the time of the observation?
So LOINC code validity uses check digit as described. It seems like there is an expectation that LOINC codes expire or are otherwise not valid with status changes, which is not the case.
1 Like
Some additional information that may be related to what you wrote….
Folks may map historic data to LOINC codes at anytime whether for clinical, research, public health or other needs. Thus a LOINC code now available can be mapped to historic data. A great example of this is many chemistry and immunology tests only had a single LOINC which was mapped and in use. However, an IVD vendor requested more specific Immunoassay method LOINCs for the analytes. Given these provide more detail about the test, as part of routine maintenance an entity may update their maps to use these. The previous codes are not invalid. The newer code provides more detail and a better mapping option. However, both codes are equally valid.
We know some Health IT systems do not regularly maintain their LOINCs and perform updates like this, while others do or some take LOINC updates once a year.
1 Like
Thanks to Andrea and John for your deep interest in this issue. I was aware even before last year of the statuses of Loinc. As I said before, I was looking at this from a retrospective point of view, not as one loading current loinc codes for a lab or emr. I apologize for my sloppy language of using the term “valid” for the date, which I only did today. Previously I was careful not to use that word but it feels like you jumped on it so apologies. The original question was to understand how to get a date at which time a term was changed- which can include deprecation. That was my original question, in lieu of a date at which point a term changed, do I use the date of the version? This was to allow us to record the date of the change, not to remove the term. However it could be helpful if text of a term changed. I don’t know if that helps but that was the question. Again I’ll repeat. for Loinc, if we want to record the date of a change to a term, what date shall we use?
Hello,
Generally date of change is not used. Changes are usually indicated by version. A code may be updated multiple times across multiple versions depending on the type of change (deprecation, trial, trial to active, etc.). I supposed if you want to use a date, the date of the release or patch could be used.
According to me, we have to take it as it is.
HI @rberge ,
The LOINC version can loosely be associated with a release date, if you want to do datetime calculations.
For example: Version 2.81 was published on 8/12/2025. LOINC currently releases biannually in February and August. In 2021, LOINC changed from a December/June release cycle to the current August/February release cycle. The release day is generally the 15th of the month, but the exact day may vary slightly. With this knowledge you can derive an “effectiveTime” (i.e. Derived EffectiveTime) based on the version.
To address the “Term first started being used” portion of your comment. we first have to define what this phrase mean to your organization in terms of the LOINC status. Does “Started being used” mean the term has a “Trial”, “Active”, and possible a “Discouraged” status? Some would suggest the answer should be “Active”, however, there are LOINC codes that were created with a “Trial” status that have never become Active. In some situations, a LOINC code could move from Trial directly to discouraged or deprecated without ever having been formally “active”.
Thus, the syntax looks like one of the following:
- (LOINC Version OR Derived Effectivetime) AND status IN (‘Trial’,’Active’) = Term first started being used
Does “term is no longer in use” mean “Discouraged” or “Deprecated”? Per the status definition, a LOINC code with the status of Discouraged should not be used to create new mappings but is acceptable to exist in legacy maps, therefore, it may still be present in current day data streams. Deprecated, means the LOINC Code has been retired (i.e. inactivated) and should not be present in existing or new maps.
Thus, the syntax looks like one of the following:
- (LOINC Version OR Derived Effectivetime) AND Status = ‘Discouraged’ = Not technically “Active” but not technically “Retired” (could be included in the active bucket depending on the use case?)
- (LOINC Version OR Derived Effectivetime) AND Status = ‘Deprecated’ = Retired (With caveat")
Here is the Caveat:
The reality is, once a LOINC code is recorded in an electronic health record, it is part of a legal document and will therefore potentially be present in the patient records for all time. If someone were to request a full copy of a patient’s medical record, they will likely get deprecated LOINC codes. If there is an error in mapping that is “resulted” to the electronic medical record that result value will be mapped to an incorrect LOINC code in perpetuity in the electronic medical record. The Lab may, but mostly like will not, send an updated result to just fix an erroneous mapping. Similarly, If I LOINC code was active at the time a lab test was performed and resulted but was subsequently deprecated, the lab will not send an updated result with a new LOINC code even if that test is still being performed.
To answer the question “Is it valid to transpose the date of the version as the effective/expiration dates?”, I think the answer is a cautious “Yes” with caveats depending on the LOINC status associated with a given version (EffectiveTime) and how your specific organization chooses to define active versus expired based on the LOINC Version plus the LOINC status.
We should also keep in mind that this is not a one-way street. A LOINC code can change status from “Active” –> “Deprecated” –> “Active”. Your organization’s business logic should define how to handle this situation. This scenario is not unique to LOINC as it can be done in SNOMED as well.
This is definitely a situation in which your organization needs to define and document its business logic and make that logic as transparently available as possible.
I hope that helps.
J
1 Like