ICD10PCS: bringing back deprecated codes

Vocabulary Users
1

As of this day, ICD10PCS source updates yearly and deprecates codes nearly each release, meaning they can not be used by care providers to report performed procedures anymore. However, since ICD10PCS vocabulary is Standard, our current approach of deprecating codes in CDM Vocabularies when source does it creates problems for people trying to use these codes, which are still abundant in existing records, for analysis.

This update, we are looking to “resurrect” all codes deprecated since addition to OMOP CDM and make them Standard together with their own internal hierarchy. To differentiate between active and deprecated codes, we are going to mark codes as Deprecated in concept_name field. This should serve as deterrent to using these codes as mapping targets from other vocabularies.

Eventually procedure Standardization process will lead to creating custom concepts inside SNOMED hierarchy to serve as mapping targets for deprecated ICD10PCS concepts, but this solution aims to keep existing ICD10PCS codes useful in short term.

1 Like
2

I’m not sure I like this idea. I prefer the concept_name be a direct representation of the concept_code as stated by the Vocabulary.

Since the Vocabulary team controls all mappings between OHDSI approved Vocabularies, why do we need a deterrent for the community?

3

We do not intend to simply name concepts “Deprecated”. I mean adding “Deprecated” as suffix to name:
Repair Lesser Omentum, Open Approach (Deprecated).

Because people may and are encouraged to create their own custom mappings for classifications that can not be put into common Vocabularies/

4

How would ‘Deprecated’ tag being a part of the name confuse you?

2 reasons:

  • we would always need to join to the ICD10PCS sources to know whether it’s deprecated or not. Much easier is to see it within a concept_name.
  • All the community does the custom mappings. There is no other way to represent it in Athena. But agree, probably we need a better way.
5

This definitely doesn’t confuse me :slight_smile: I don’t like it because it adds additional characters to a concept_name. When EHR data lacks a code, I will join to the Concept table on the concept_name and pull back the exact match. Sure I can parse, but why change the name when other options are available? Shouldn’t we use InvalidReason = ‘D’?

1 Like
6

Wait, friends. Don’t we already have a solution for this we use with CPT4 and HCPCS? We just set the end date, but keep it active and standard? Why are we keeping ICD10PCS different?

1 Like
7

Concepts must remain Standard, and concept can not remain both invalid and standard at the same time.

I was not aware that concepts can be active with valid_end_date being less than current date. I thought there are table constraints in place to prevent this from happening? I’ll investigate how we can do the same with ICD10PCS.

8

Actually I am agree. Why not to allow Standard concept being Deprecated? It would be more obvious for users and easier than looking into the dates.
What would be broken if we withdraw this constraint?
@Christian_Reich @Dymshyts

9

Problems is D can mean that the original concept was just plain incorrect (once in, concepts are not removed). To just change mapping code to ignore invalid_reason will create errors. Need a new invalid_reason to indicate that the source code was correct, but is now retired.

10

We have that. We set the valid_end_date to something in the past, but leave the invalid_reason and standard_concept intact.

11

Can you post here once the resurrection has taken place. In what version we should see them “rise from the dead”.

12

It’s done in version v20200731.
you can see it here https://github.com/OHDSI/Vocabulary-v5.0/releases/
in “Standard concept changes” table

1 Like