The following source_concept_ids from our data do not have a ‘Maps to’ relationship_id to a standard concept_id:
3040061
3018135
3051883
3051883
3024726
3008338
3027184
3020331
3017427
3020331
These are deprecated concepts by the source (LOINC). We are not, or only in rare occasions, doing their work and find the upgrades. Sometimes it is not even possible: 3040061 “Deprecated VAP cholesterol panel - Serum or Plasma”. You’d have to split panels into the components. Sometimes it is possible: 3020331 “Lead [Mass/volume] in Blood” should be replaced by 3028605 “Lead [Mass/volume] in Serum or Plasma” since none of these analytes are measured in full blood anyway.
We don’t need to do their work and find the upgrade. We should keep them standard like we did with the deprecated CPT4 codes. We won’t have any future data with the deprecated LOINCs, the lab runs the new test. However, we do have data with the old test. And measurement_concept_id = 0 has no meaning.
Totally agree. There should be either an artificial concept with the same meaning or a re-validated concept. The records do not go away because CPT4 or LOINC decided that the concept doesn’t make sense anymore.
I’ve posted a couple threads around the same idea so I’m going to offer my thoughts to continue for a push in how standard concepts change in vocabularies.
A deprecated concept that was once standard shouldn’t lose their classification of “standard”. Established analysis that use these concepts will break often if they’re marked “not standard”. If these concepts were kept to be “standard”, but with the flag denoting deprecation/invalid/outdated/etc. (I believe it’s denoted in invalid_reason column) allows for some type of strategy of transition by the end users.
This will allow organizations to create processes to transition analysis to appropriate concepts where necessary. We want to avoid stop errors and preferably create warnings in existence of deprecated/invalid/outdated/duplicated/etc. concepts in end user processes.