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.