I like that. No coding change and then D would only mean one thing, there
is something wrong with this concept and it should not be used.
Assuming in addition, if invalid reason set to D then Standard Concept set
to NULL and ‘maps to’ relationship is removed, while if only the
valid_end_date is changed, the concept remains Standard and the ‘maps to’
relationship continues to exist.
correct
I also like that. Seems to be the simplest solution
We had a nice discussion 6 of March work-group and finalized the decision:
For a HCPCS and CPT4 concepts deprecated because of the source withdrawal, we make the Standard_concept = ‘S’ and invalid_reason = null, but valid_end_date reflects the withdrawal date.
This makes possible to use these concepts as standard and fill up the CDM, and also CDM builders can easily check the consistency of the data ensuring that event date is between concept’s valid_stard_date and valid_end_date.
Once we have resources available, we’ll implement these changes
Note, we make this for HCPCS and CPT4 only. In the future we’ll analyze the other vocabularies, understanding why the source deprecates the concepts and then we’ll make a decision whether we need to deprecate them or just change the valid_end_date but not affect Standard_concept and invalid_reason values.
1 Like
That’s great news! This will help our ETL since there were codes we were loosing b/c they were deprecated.
If the source code is deprecated in the source vocabulary (was valid before, if not valid now). Are the following correct?
- We will not make the source code invalid. We will set the valid_to_date to the date the code was deprecated.
- Mapping to standard will exist in the concept_relationship table
- If a code from standard vocabulary like snomed is deprecated, it will still exist as invalid is null, but would be mapped to shoulder equivalent snomed that is not deprecated.
Yes, but only for HCPCS and CPT4 as the source withdrawal means change of bulling system classification or something like that - when the semantic meaning is correct but concept is not in use anymore.
Yes, again for HCPCS and CPT4,
as they will not be deprecated they remain standard, so they’ll map to themselves or to SNOMED or RxNorm equivalent (if exist)
SNOMED and RxNorm mostly deprecate the concepts because of the semantic non-sense: Drugs with impossible dosage, Conditions breaking the rules of SNOMED hierarchy or having duplicates and so on.
Thus if SNOMED source deprecated we also deprecate this concept.
So the changes discussed here will be applied only to HCPCS and CPT4.
In the future will analyse the behavior of different sources and define the corresponding concept deprecation scenario for them.
Reviving this problem since we still need to deal with the source removing codes.
2020 release of ICD10PCS invalidates ~2000 codes. It does not seem that codes were erroneous per se. At a glance it looks like that ICD10PCS sometimes changes logic for definition of some procedures: for instance, hemorrhage control procedures are no longer coded for a specific organ and rather for anatomical region.
Since old codes are not wrong (duplicates or calamities) and will not be reused by new ones (since ICD10PCS does not allow to reuse codes), I suggest keeping historical codes Standard for ICD10PCS (at the moment they are deprecated).
1 Like
Is it the exact case when we can map it?
A specific organ procedure to an anatomical region procedure?
What’s the decision here, guys?
No decision yet. We want to hear from the community first.
Ok, no objection here.
We’ll make them standard, add them to the SNOMED hierarachy like we did for the other ICD10PCS concepts. Thus they will appear in concept sets defined through parent concepts and also will keep the original meaning.