The problem of standardization by semantic understanding

[gowthamrao]

We utilize semantic understanding to interpret meanings of concepts and subsequently determine 'standard' vs. 'non-standard' classifications, along with mapping. This approach is generally effective, but it encounters challenges when semantic interpretation diverges from actual usage.

For instance, the concept 'G6002: Stereoscopic X-ray guidance for localization of target volume for the delivery of radiation therapy' has multiple semantic interpretations.

Based on this, the following mapping decision was made:

While this mapping may seem reasonable semantically—aligning more with radiology procedures than radiation procedures—the concept in question is predominantly used in the context of radiation, specifically IGRT. More details can be found here: IGRT Coding Guidance . Plus the standard counterpart is not usable as it too broad.

I wish to point out that this issue represents a recurring challenge in the OMOP vocabulary standardization process, potentially leading to phenotype misclassifications in practical usage.

[dimshitc]

the mapping is only one concept even: it maps to 'Diagnostic radiography, stereotactic localization', the other two, are the 'Is a' relationships. I agree with you that it's a bad practice to map while losing granularity, and unfortunately these cases occur in the OHDSI vocabulary. @gowthamrao let's create a list of such concepts and contribute to the vocabulary team

[gowthamrao]

Thank you @dimshitc . A screenshot that @dimshitc shared with me

[cgreich]

This is a common problem that is particularly bad with HCPCS and CPT4 codes. Reason: They are built by cobbling things together, to optimize fee for service prices. While the standard concepts, typically from SNOMED, are much cleaner. Mapping inevitably runs into the problem of cutting up and going uphill.

Cutting up is ok if the source concept is an enumeration. However, when attributes of a concept are cut up, like in this case, you inevitably create the problem that they are no longer coordinated, since post-coordination is not supported in OMOP (thank God).

Going uphill is another problem.

The solution is OMOP extension concepts. They are one-to-one copies of the original, singular, can be placed correctly into the existing hierarchical structure, and you have no problem with deprecation of the source. However, making and maintaining them costs resources we don't have.

PS: We may want to change the grandiose title. Nobody knows what the problem is. :)

[dimshitc]

@cgreich Why OMOP extension? Why make things complicated? Just make this CPT4 standard, turn that 'Maps to' into 'Is a', so it Gowtham wants this very specific concept he'll have it in the data, if the other user wants all Diagnostic radiographies without details, they will get our concept because it will be included into the Diagnostic radiographies hierarchy

[cgreich]

Because of the life cycle. We don't control CPT4's deprecation decisions. But nominally, deprecated concepts should not be standard and participate in the hierarchy. I know we made an exception, but we did so because we had no resources to do a proper solution.

[dimshitc]

We don't control CPT4's deprecation decisions

you just admitted you do it in some way: when concept becomes deprecated, it remains standard.

But nominally, deprecated concepts should not be standard and participate in the hierarchy.

but nobody got hurt because of that, while if you do the opposite - create uphill mappings - people complain. I'll try to find more use cases similar to this

[cgreich]

you just admitted you do it in some way: when concept becomes deprecated, it remains standard.

It's a horrible workaround. Which one do you now trust: invalid_reason or standard_concept?

but nobody got hurt because of that

Everybody who relies on invalid_reason. It has lost it's meaning.

you do the opposite - create uphill mappings - people complain

Which is precisely why you want OMOP Extension plus hierarchical links to proper standards.

[dimshitc]

Invalid_reason becomes obsolete in this case. we can make it NULL, since for the OMOP the such concept is still active and standard. Or educate people that invalid_reason field stands for the invalid_reason for the source. Are there complains that people got confused by standard deprecated concepts? I like this discussion - at least I understand why you don't want CPT4 and HCPCS to be standard

[cgreich]

@dimshitc: You are pushing the problem from one corner to the other. If you arbitrarily set invalid_reason to NULL, you create a new problem with valid_end_date. And there is a finite amount of funny rules that you can "educate" people on.

Are there complaints: Of course. From time to time some Forum pops up, and then we "educate". It will never be right. Is it the most important issue on people's mind? I don't think so. Most folks will not even know about this thing at all. Ask around. :)