ICD10 granularity issue requiring new more specific concepts

[jswerdel]

Currently the ICD-10 code K52.1 for Toxic gastroenteritis and colitis is mapped to SNOMED 128999004 - Inflammatory disorder of digestive tract. This is too high. There is a toxic gastroenteritis but no toxic colitis. This code is useful as it is used for examining the toxic effects of cancer treatment (see: https://pubmed.ncbi.nlm.nih.gov/37461984/)

[aostropolets]

Hello-hello @jswerdel! Is there a better SNOMED target?

[dimshitc]

@aostropolets so Joel refers to the toxic gastroenteritis - https://athena.ohdsi.org/search-terms/terms/197596
What do you think if we slightly violate the vocabulary mapping rule and map it slightly "downhill":
K52.1 for Toxic gastroenteritis and colitis (which is and/or) will be mapped to "Toxic gastroenteritis"?

[aostropolets]

I was about to suggest to map to two, colitis and gastroenteritis (even though ICD is or, not and), and funny enough colitis is replaced by chemical colitis https://athena.ohdsi.org/search-terms/terms/4248863 which has toxic enterocolitis as a synonym. Funny SNOMED.

[TinyRickC137]

Agree with @dimshitc
We can slightly violate our rules and change mappings to downhill 'Toxic gastroenteritis' and lose the 'colitis' part. Toxic gastroenteritis has a better hierarchy. Mapping to two can also work - and is also a violation.

Thoughts? Will it be easier for users to find this standard concept if we map to Toxic gastroenteritis?

@aostropolets @jswerdel @Alexdavv @cgreich

[Alexdavv]

I would map uphill, unless somebody reported a use case like here. Once reported, I would create the “OR” OMOP Extension and put it above both SNOMEDs.

[Alexdavv]

I would map uphill, unless somebody reported a use case like here. Once reported, I would create the “OR” OMOP Extension and put it above both SNOMEDs.

This could be a simple hand-made step towards the SNOMED Extension.

@dimshitc @jswerdel @TinyRickC137 @cgreich @pbr6cornell @aostropolets Thoughts?

[dimshitc]

We need to have agreement and additional investigation on how we create and maintain these OMOP Extension concepts.
Can we just do a quick mapping downhill to support the Joel's use case?

regarding the use case driven changes: I don't like this idea because users will never know which cases work which way.
There was some work done by @p-talapova where she identified the uphill mappings, maybe we can use it

[Alexdavv]

regarding the use case driven changes: I tdon't like this idea because users will never know which cases work which way.

Right. Except with my proposal, nobody will suffer - we still map to a correct uphill concept. With the downhill mappings applied by request here and there, users will definitely never know which cases work which way.

[dimshitc]

Users are used to the idea that SNOMED is standard for conditions, and if we want to introduce the SNOMED Extension, I we need to do it systematically.
I talked to @pbr6cornell and he opposes the OMOP Extension creation (I wouldn't call it SNOMED extension, as here we can add these equivalents of ICD AND/OR concepts which are against the SNOMED rules), mostly because it's hard to maintain.
But on a first glance it's not harder to maintain than the ICD - SNOMED relationships - it will be just intermediate step in ICD - SNOMED relationships.
So, we need to come up with some solid proposal for the OMOP Extension as the potential mapping target for the ICDs, which I would be happy to do together, @Alexdavv please let me know if your team has availability to work on this. But in meantime, to resolve the Joel's case, I would map slightly downhill as it was suggested initially.

[Alexdavv]

we need to do it systematically

mostly because it's hard to maintain

The idea (and the difference with the OMOP Extension) is to do it properly, using the SNOMED toolset, rules, and grammar which will reduce the maintenance burden but requires some initial effort indeed. So it's another way around.

I wouldn't call it SNOMED extension, as here we can add these equivalents of ICD AND/OR concepts which are against the SNOMED rules

Since it would be a local (still an official) extension, we can redesign some of the rules. It's anyway better than what SNOMED does when they transform ICD's "OR" into "AND" - this is the problem we/they need to solve at some point anyway @pbr6cornell

So, we need to come up with some solid proposal for the OMOP Extension as the potential mapping target for the ICDs, which I would be happy to do together, @Alexdavv please let me know if your team has availability to work on this. But in meantime, to resolve the Joel's case, I would map slightly downhill as it was suggested initially.

Do you mean the design principles or the actual maps? The former we have here.

[dimshitc]

The real SNOMED extension that follows the rules of SNOMED (even some redesigned) looks like a huge and not really helpful, because most of the ICDs which don't have 1to1 map don't follow the SNOMED rules.
I'm talking about OMOP Extension (which we already have), to be systematically used to create 1 to 1 mappings for ICD concepts (which we don't have).
Note, other sources like HCPCS, CPT4, ICD Procedures can be standard by design and thus don't need any extension.

[Alexdavv]

The real SNOMED extension that follows the rules of SNOMED (even some redesigned) looks like a huge

Well, this is a choice between investing in the reproducible and scalable solution once or doing the manual thing with a much hieger maintenance burden.

not really helpful, because most of the ICDs which don't have 1to1 map don't follow the SNOMED rules

What rules do you care about? If they have the right place in the hierarchy and are produced by the machine that handles the links and changes over time, it's all that we need. We anyway don't use most of the SNOMED features these rules are designed for.

Tagging @ekorchmar

Note, other sources like HCPCS, CPT4, ICD Procedures can be standard by design and thus don't need any extension

Of course, they need. The fact that we bring them to the Standard realm doesn't mean we achieve the standardization in the given domain. Remember the CPT4 visits? We only hide the problem to make people happy - some people call it a compromise.

[ekorchmar]

will reduce the maintenance burden but requires some initial effort indeed. So it's another way around.

Currently, NHS is is struggling with the process of redesigning a drug hierarchy from scratch, as SNOMED International is changing uphill rules they depended on. Why am I bringing this up -- what we propose here is to introduce a whole new entire process with SNOMED extension authoring and, worse, a new external dependency on IHTSDO internal processes and mutable rules. This is a big commitment, both in upfront work and long term maintenance, as SNOMED is a complex, living, changing system. And, well, OHDSI has less disposable resources than NHS.

I am not saying this because I am against the idea of OMOP SNOMED Extension -- I am rather for it; but not because I see it as a small upfront investment, but because I like the possibility to have a way to consistently resolve issues like K52.1 mapping.

better than what SNOMED does when they transform ICD's "OR" into "AND"

SNOMED may have done it in the past, now they avoid this, and try to rectify older concepts. But if anything, this shows that SNOMED is:

1. Full of legacy content that may be changed in unpredictable timelines;
2. Changes the rules as they go;

if we want to introduce the SNOMED Extension, I we need to do it systematically.

To introduce a new standard concept on example of K52.1, we would need to do at least the following:

1. Introduce a new supporting concept -- a "Stomach or intestinal structure"; closest existing concept Intraabdominal digestive structure still includes Liver and Abdominal esophagus;
2. Manually remodel the existing body structure hierarchy; we would need to manually check all or most of subsumption relations of this subhierarchy;
3. Correctly model a "Toxic inflammation of stomach and/or intestine" concept. We are not even guaranteed to have it modelled Fully Defined -- what is even a "toxin"? Toxic inflammations of anything I can find in SNOMED now are all primitive;
4. Manually find all Primitive and mis-modelled concepts that could be descendants of the new concept (Toxic gastritis, for example, is currently Primitive) and update their relations; ideally, also update their modelling.
5. Keep a close watch on SNOMED international and update our changes to align with upstream
6. Submit our changes to SNOMED international to (hopefuly) reduce manual work with updates; some of them will probably be rejected, including the addition of new concepts (they are good for us, but not for SNOMED Intl).
7. Repeat steps 2-6 each time SNOMED International updates, if at least to confirm that no changes are needed.

And this is for one concept. And once there are dozens of them...

On the other hand, just integrating the new OMOP Extension concept "Toxic gastroenteritis and colitis" manually runs into similar problems, minus adherence requirements, plus reduced visibility of breakages.

So eventually, we might just have to create an OMOP Extension due to inevitability of having to have a structure to manage the added content. Neither creating "fake" SNOMED concepts nor cheating mapping rules for individual concepts is sustainable. Two years from now, new person will look at the mapping of K52.1 to Toxic gastritis, not knowing about this conversation (probably burried in Closed Issues by then), and revert it to the current state, being absolutely right and justified. So at the end of the day, maintaining a SNOMED Extension, however costly, is sustainable.

[ekorchmar]

On a more practical note, pertaining to exactly Toxic gastroenteritis:

It would be better long term to have an explicit mapping target that will eventually be remodelled to SNOMED extension; it also reduces chances of accidental reversal comparing to mapping "downhill" to an existing concept while we are still considering introducing the SNOMED extension.

[dimshitc]

Eddy, thanks for the brilliant explanation of why proper SNOMED Extension is a burden.

But is there a problem to create an OMOP Extension of "Toxic gastroenterocolitis"? We already have Maps to relationships from that ICD10, which will be turned into the Is a relationships between "Toxic gastroenterocolitis" and SNOMED parents.
so to support that part of OMOP Extension, is not that different than to support ICD - SNOMED mapping where you need to see if involved SNOMED concepts become deprecated or new more suitable SNOMED concepts were added?

[ekorchmar]

How I would go about it is exactly to create a new OMOP Extension concept and build it in the middle of SNOMED hierarchy, including manual Subsumes relationships. This does run the risk of missing target concepts turning deprecated -- and we would have to manage this risk; once formal OMOP SNOMED Extension is here, this management becomes way easier with SNOMED tools, but until then it's manual.

Making a factually incorrect mapping may be a quicker and easier solution upfront, but is actually more brittle, and may be reverted very next update without anyone noticing. It could also cause problems for people trying to use this concept in other research problems.

[Alexdavv]

So getting back to my original proposal...

I would map uphill, unless somebody reported a use case like here. Once reported, I would create the “OR” OMOP Extension and put it above both SNOMEDs.

This could be a simple hand-made step towards the SNOMED Extension.

It seems like everybody's happy, right?

Eddy, thanks for the brilliant explanation of why proper SNOMED Extension is a burden.

@dimshitc I think you're missing the @ekorchmar point. We're already far away from the intersection on the graph. We're 1,444 concepts now, and it's not easy to maintain. So we're already in a red zone and by adding more we grow the maintenance burden exponentially.

[Alexdavv]

I talked to @pbr6cornell and he opposes the OMOP Extension creation (I wouldn't call it SNOMED extension, as here we can add these equivalents of ICD AND/OR concepts which are against the SNOMED rules), mostly because it's hard to maintain

@pbr6cornell We’re already there (see below). I don’t think a couple of use case-driven requests will change anything

[IrynaZherka]

The issue was addressed during the August 2024 release.
However, it is important to note that the code K52.1 is currently still mapped uphill in accordance with the current agreement on ICD codes mapping.

[Alexdavv]

Let's keep this issue open and collect more similar cases.
https://forums.ohdsi.org/t/approach-to-defining-an-ischemic-stroke-cohort/22434