CPT Hierarchy errors - lost children in 2023 and changed domains

[Alexdavv (Alexander Davydov)]

Hi, @Dymshyts et al!

I’m really sorry that we’ve been keeping all these CPT4 concepts in the Standard area for that long, so the change cost became that big.

@Dymshyts

I really like the idea … and effort of the OHDSI Vocabulary team

Nice to hear it, Dima!

@Dymshyts

The problem lays in the variety of meanings of the CPT and HCPCS codes

The problem lies much more on the surface: these codes have highly variable meanings even within a code. And how the given user interprets them depends on many factors including the specific knowledge of the vocabulary and coding rules, locally established practices, and the ability for mental gymnastics with multiple AND/OR statements and logical reasoning.

Users can’t do that. We don’t want users to do that. And this is not what the Standard concepts are supposed to be.

We keep working on the vocabulary improvement project and we’ll release vocabulary principles later this year (link1, link2). In line with the principles we keep improving the vocabulary cleanliness, and this case (among others, like negative information, Survey data) is one of the most characteristic examples to look at.

But right, if users find this information useful, we need to find a proper solution to Standardize it.

How about the following?

1. We ask folks who know and use CPT4/HCPCS in research to boil them down and extract meaningful information from them. Not the entire CPT4/HCPCS pool - only those that don’t qualify the criteria for Standard concepts (those mapped to Visits and other deStandardized concepts). Dima already started this work by identifying those that are used in cohorts or otherwise characterize the patients.
2. We look at the meaningful information together and decide what the proper Domains should be. Could be the Visit, Observation, Modifier? or something else.
3. Then we find a way to record this information in the proper Domain, or make an exclusion. The solution could trigger the creation of new more specific concepts within the existing hierarchies of Visit, or the Visits of new dimensions, or new Observation concepts in the OMOP Extension.
4. We come up with a guide for ETL, including the approach for merging the Visits coming from different sources, if needed.
5. Since CPT4/HCPCS is on the roadmap the vocabulary team can help with 3, 2, and partially 4, but we still need your help with 1 and 4.
6. In the meantime, given that the problem has persisted for more than 1.5 years (4 latest vocabulary releases) and the release cycle is 6 months, we try to focus on the solution space to get a proper approach implemented by the nearest release in August as opposed to make a rollback/shortcut solution in the nearest release and postpone the proper solution for the future.

Thoughts?

[Wilson_Pace]

Some of the discussion above about the “ambiguity” of a CPT code is based on faulty information about what a CPT code represents. E&M codes describe the “complexity” of the “procedure” in this case the visit NOT the complexity of the patient. So the use case described above about trying to use the higher E&M codes to infer patient complexity is not really sound. On the other hand the idea that the description of a “complex ED visit” is ambiguous is not correct either. The code indicates that the work involved to care for this patient reached a “complex” level related to other visits. It has nothing to do with underlying “complexity” of the patient. I agree with the various arguments above about both the differences between an “encounter” in the EHR vs a “visit” in CPT they are overlapping but impart different information. But there are many use cases where understanding the information contained in “visit” data is very helpful - the ICU use case is an example. Preventive services is another example. An actual clinical visit as has been mentioned is another one. Moving them into the “visit” table has not worked well as many have noted above. Putting them in the polyglot observation table bypasses the visit problem but continues to deposit CPT codes across the CDM and is an attempt to extract secondary meaning from a terminology designed to collect the work and actions being conducted with and to a person. Moving vaccine administration to the drug table is an example of this secondary interpretation. CPT should be used for what they are- a procedure that has been completed - not a way to impute other information.

[Chris_Knoll]

@Christian_Reich

@Thomas_White

Atlas doesn’t enable direct search of visit_detail.

That needs to be fixed. However, VISIT_DETAIL is mostly relevant to inpatient visits, is it not? An office or ER visit, which is what most of these concepts represent, should be in VISIT_OCCURRENCE, no?

Catching up on this convo,and not sure if it was true in Feb 2023, but at least as of 2.14, you can query visit detail:

[Christian_Reich]

@Alexdavv

We ask folks who know and use CPT4/HCPCS

They are actually very well defined. We have to get those definitions. Not that expensive.

@Wilson_Pace

E&M codes describe the “complexity” of the “procedure” in this case the visit NOT the complexity of the patient.

That is true. But it isn’t the point to characterize the patient. The point is to project the complexity onto the primary diagnosis of that visit and infer severity. Sounds reasonable to me. The question is how to properly represented the “lots of work up” in the OMOP CDM. Taking the CPT4 as is and shoving it into an Observation is the poor man’s solution, putting the onus on the analyst to make all those connections.

@Wilson_Pace

CPT should be used for what they are - a procedure that has been completed - not a way to impute other information.

Except in this case there is no procedure. “Lots of paperwork, working the phone and spending time on the patient” is not a procedure by OMOP standards. Actually, less than 50% of CPTs are procedures.

@Chris_Knoll

you can query visit detail

Great. Thanks, @Chris_Knoll.

[Dymshyts (Dmytry Dymshyts)]

@Alexdavv I don’t understand:
I gave perfectly fine solution that will satisfy all users, those who want visits, and those who don’t.

What’s the problem?
Let the users have their concepts. Let them have complexity of care.

@Wilson_Pace

The code indicates that the work involved to care for this patient reached a “complex” level related to other visits

This is normal when we first release not the perfect solution, we as a community learn what is best for all of us.

[Alexdavv (Alexander Davydov)]

@Dymshyts

I don’t understand:
I gave perfectly fine solution that will satisfy all users, those who want visits, and those who don’t.

What’s the problem?
Let the users have their concepts. Let them have complexity of care.

There’s no problem if “their” concepts remain non-Standard. But it seems users don’t like it - we’ve already done it, but it doesn’t satisfy. Can it be the reason to make them back Standard? We try to systematically solve the problem, not throwing them back in the dump and telling the world not to use them.

[Dymshyts (Dmytry Dymshyts)]

Yes, there’s a fundamental idea: the vocabulary should work without using non-standard concepts.
Tools don’t work with non-standard concepts.

@Alexdavv

Can it be the reason to make them back Standard?

Yes.

@Alexdavv

solve the problem

there was no problem until you made these mappings to visits
Sorry if it sounds rude, I didn’t mean it, as I said, we do our research, and can make not optimal decisions.

[Alexdavv (Alexander Davydov)]

@Dymshyts

Yes, there’s a fundamental idea: the vocabulary should work without using non-standard concepts.
Tools don’t work with non-standard concepts.

Exactly. But it doesn’t force you to turn the source concepts into the Standard. Usually, we have a way to map them, or claim them as a Standard for a given use case, or create the concepts to support the use case. In this case, we neither have a Standard to map to nor a shared understanding that these messy mixed (but “very well defined”) concepts can’t be a Standard for the use case.

@Dymshyts

there was no problem until you made these mappings to visits
Sorry if it sounds rude

No, it’s fine. There are no bad feelings because we were mostly driven by the request. And only then, with the QA principles work we actually realized the validity of the idea and its importance.

Tagging everybody involved @Thomas_White @aostropolets @zhuk @rookie_crewkie @MPhilofsky @Vojtech_Huser @stephanieshong @Maria_Khitrun @Charles_Bailey @nflower5 @clairblacketer

[Vojtech_Huser (Vojtech (Vojta) Huser)]

For the changed domains problem:
In CDM WG, VA team made a presentation few weeks back. I wish their slides would be posted. (well, maybe they are).
I would also gathers others who have challenges with current mappings.

We would ask all those stakeholders to propose a solution. If I remember one solution correctly it was: I think mapping to visit would stay but in addition there would would be one other mapping to self. It would make some CPT codes standard and put them to observation domain.

This would preserve the idea of decomposing them into what they are but would make a compromise to allow PIs depending on them to have them in observation. But I may not remember the solution fully. And it is violating some principles but we may need a compromise in this case.

[Tina_French]

@clairblacketer @MPhilofsky Did you post the slide deck from the VA presentation? Where would that be?

[MPhilofsky (Melanie Philofsky)]

Problem & cause

The OHDSI community needs the full meaning of the CPT4 codes to be represented as standard concepts in order do collaborative research.There are multiple use cases around utilization of services, acuity of patients, etc. which these CPT4 codes cover. And there aren’t proxy codes/concepts for any of these CPT4 codes. We can’t substitute anything else. And we can’t utilize the standard concept_id because “Emergency Room Visit” covers high utilization, complex visits and those waiting to get a splinter taken out by a non-physician provider. The loss of granularity and data points is the heart of the problem.

Use cases

@Charles_Bailey

• Presence of an E/M code indicates that a clinician actually interacted with the patient at the visit; this bit of metadata changes interpretation of things like the accuracy of condition_occurrence records and other facts reflective of clinical decision making.
• The final digit indicates the “complexity” of the visit, a CPT-ish term for how sick the patient was, allowing the study to distinguish coarsely between complications and routine follow-up.
• (As an added bonus, the critical care codes such as 9947x and 9929x are in administrative datasets often the only way to ascertain that a patient was receiving ICU-level care. As you might guess, this has been a topic of particular relevance in studying COVID-19.)

@Dymshyts

The problem lays in the variety of meanings of the CPT and HCPCS codes affected, which can’t be simply replaced by visit codes.

@Dymshyts

might be used in some cohort definitions to determine the severity of patient: if you look at codes 99281 - 99285, the 99281 stands for case when physician is not required (very simple case),
and 99285 stands for “high level of medical decision making”(complicated case), and 99282 - 99284 are in between.

@nflower5

some researchers at Stanford use these codes to differentiate office/outpatient visits for new vs. established patients.

@Thomas_White

These changes are breaking some of my concept sets (e.g. ones looking for new patient doctors’ visits). However, there appear to be hundreds of cases now where Concept Hierarchy codes that used to have descendants no longer do.

@Wilson_Pace

many use cases where understanding the information contained in “visit” data is very helpful - the ICU use case is an example. Preventive services is another example. An actual clinical visit as has been mentioned is another one

@MPhilofsky

other’s use cases as we discussed this am on the HSIG call .

@MPhilofsky

In case you missed the discussion on this topic in the CDM WG this morning, it is located here .

The mappings have quite a bit of information loss. Here are two examples:

As you can see, the only retained attribute in the non-standard to standard map is the “Emergency Room Visit”. The acuity of the person, the amount of resources required to care for the person, medical history and/or exam are not retained in the mapping.

Example #2:

This code represents per day utilization of dialysis services. It is mapped to a place of service code, which represents an End Stage Renal Disease care site. However, this “care site” has a domain of visit (I won’t go into my disdain for amalgamating of visits & care sites since this discussion is about CPT4). Nowhere in the CPT4 code does this say a person is being treated at an ESRD treatment facility. They could also be receiving hemodialysis services at their local hospital facility. This mapping is inaccurate and loses the “dialysis” portion of the code.

Then there is this one which remains standard and is clearly a Telehealth visit:

And Dima’s example of one mapped to Telehealth and loses all the other information:

@Dymshyts

Interrogation device evaluation(s), (remote) up to 30 days; implantable cardiovascular physiologic monitor system, implantable loop recorder system, or subcutaneous cardiac rhythm monitor system, remote data acquisition(s), receipt of tran… (Deprecated) | HCPCS | G2066

Potential solutions

1. Keep the mapping to Visits, but also add additional mappings for the other attributes to standard concepts in their respective domains (acuity to Observation, dialysis to Procedure, etc.).
2. Make these concepts standard and give them domain_id = Observations.
3. @Dymshyts suggested solution:

@Dymshyts

instead of having ‘Maps to’ relationship which makes source codes non-standard, and not usable in OMOP CDM properly, create, let’s say, ‘Has related visit’ relationship, so the ETL can create visits out of these CPT/HCPCS concepts, but be able to preserve original concept as standard; and replace ‘Maps to’ to non-visit concepts with ‘Is a’ relationships.

Implementing a solution

An announcement needs to be made on the Vocab Github, the forums as a standalone post, and all other posts on the topic need comments referencing the new, standalone post on the issue at hand (CPT4 codes/concepts need to be standard to be utilized for research), what the exact change is going to be and when it will happen.

Prevention

Last, but definitely not least, we need to stress test any major vocabulary changes moving forward. This change took the community off guard. At the University of Colorado, we didn’t know this change occurred until users of our CDM complained about the missing CPT4 codes. We also need to notify the community in advance when major changes take place. Especially if collaborators need to update the ETL, software, concept sets or cohorts to keep things from breaking with a Vocab update.

[aostropolets (Anna Ostropolets)]

Please come to the July 30 noon EST Vocab WG meeting to discuss the topic and come up with a solution.

[MPhilofsky (Melanie Philofsky)]

I won’t be able to attend the meeting. The solution should ensure the full meaning of the CPT4 codes are represented as standard concept_ids in the OMOP CDM. From conversations I have had with OHDSI friends and colleagues, I think solution #2 or #3 I stated above would be the most beneficial for users of these data.

@MPhilofsky

1. concepts in their respective domains (acuity to Observation, dialysis to Procedure, etc.).
2. Make these concepts standard and give them domain_id = Observations.
3. @Dymshyts suggested solution:

@Dymshyts

instead of having ‘Maps to’ relationship which makes source codes non-standard, and not usable in OMOP CDM properly, create, let’s say, ‘Has related visit’ relationship, so the ETL can create visits out of these CPT/HCPCS concepts, but be able to preserve original concept as standard; and replace ‘Maps to’ to non-visit concepts with ‘Is a’ relationships.

Yes, solution #1 also works, but then users/analysts of these concept_ids have to cobble together multiple standard concept_ids living in multiple different domains and some of these are not easily accessible because they map to a standard concept_id in the Visit domain. Most ETLs lose these data. This goes against OHDSIs goal to make the OMOP CDM analyst ready.

[aostropolets (Anna Ostropolets)]

Thanks for the input! The recording will be available for you after the meeting if you would like to provide additional feedback

[TPhillips (Tom Phillips)]

We are experiencing this same issue with visits.

How do I access the recording of the meeting? I don’t see a link on the meeting notice.

Thanks

[MPhilofsky (Melanie Philofsky)]

The recording is found here.

[aostropolets (Anna Ostropolets)]

The summary also can be found here along with the slides and recording links. The specific proposal discussed was:

• Make CPT4/HCPCS ‘visit-related’ codes Standard
  Proposed domain for CPT4 codes – Procedure (align with our def of Procedure domain + aligns with pre-2023 domain assignment).
• Create ‘Has related visit’ relationship, so the ETL can create visits out of these CPT/HCPCS concepts, but be able to preserve original concept as standard in another domain.

[TPhillips (Tom Phillips)]

Sorry I haven’t been able to listen to the recording.

Was there a discussion about the possibility of keeping the new mapping and adding additional “maps to” relationships for the additional concepts to fill in the gaps? That would be the best of both worlds.

[aostropolets (Anna Ostropolets)]

This is what this new “Has related visit” relationship aims for. Concepts should not be both standard and have mappings to other standard concepts, so a relationship other than Maps to is a viable alternative.

[TPhillips (Tom Phillips)]

We are new to OMOP and have the opposite problem of others on the forum. We have written all our code using the new visit mappings. We would have to rewrite all our code to the 2023 version of visits using the old codes if this is reverted.

I don’t think anyone was proposing mapping to non-standard concepts.

As @MPhilofsky pointed out, you could add multiple “maps to” for existing, or new, standard concepts for the additional missing information. That is already allowed for by the spec and done in other places in the vocabulary.

I have not gone too far down that path to evaluate the validity of doing so. However, it would solve the problem trying to be solved by the new visit standard mapping of having a “standard” representation of a visit from multiple coding systems. It would allow other coding systems, like HCPCS, etc, to map to the standard visit codes.

For the example above for CPT4 99285, could map to a standard visit “Emergency Room Visit” and a standard visit (or observation) concept_id for “High Level of Medical Decision Making”.

As others have pointed out they already are doing, we are considering adding visits based on some CPT codes, like 96402, for a “Chemotherapy visit”, in addition to the procedure code. If this was simply added as a map to a standard concept in 2314221, it would not require additional special coding in the ETL loading. In fact, we are considering adding our own “maps to” relationships to the vocabulary for that reason.