| OHDSI Home | Forums | Wiki | Github |
Thanks @Chris_Knoll for a great review. It’s a pleasure when somebody shares your thoughts.
I want to clarify:
Case 2. You say
and
that means, that we need to make this case as SNOMED Extension? (while Christian says, we shouldn’t)
Case 3.
Probably we can change the SNOMED hierarchy, SNOMED has this “Due to” relationship. So we can use it as a hierarchical relationship. but we need to be aware of ‘Cirrhosis from HepC’ case. So we need to check
@Christian_Reich,
according to the case 2.
what about the such situation:
S82.225K Nondisplaced transverse fracture of shaft of left tibia, subsequent encounter for closed fracture with nonunion Maps to 28012007 Closed fracture of shaft of tibia 436252
S82.225K Nondisplaced transverse fracture of shaft of left tibia, subsequent encounter for closed fracture with nonunion Maps to 302941001 Nonunion of fracture 73574
If the person had multiple fractures and they were revisited within the same visit, we never know which fracture had Nonunion.
The diabetes case is fine, if the users or Atlas will modify their queries.
But if we already implementing SNOMED Extension, it would be much easier to make it on a vocabulary level rather then CDM level.
Here is another good example whee SNOMED Extension is needed:
ICD9CM concepts
678.0 Fetal hematologic conditions
678.00 Fetal hematologic conditions, unspecified as to episode of care or not applicable
678.01 Fetal hematologic conditions, delivered, with or without mention of antepartum condition
678.03 Fetal hematologic conditions, antepartum condition or complication
These all are currently mapped to SNOMED’s “Fetal anemia”. However, American Haemotology Society states that term hematologic conditions includes “fetal anemia, fetal bleeding disorders …, fetal blood clots, and fetal blood cancers”, all four of which are present in SNOMED in one form or another, but do not have a common parent that we can reasonably use by itself or in conjunction with 70591005 “Fetal disorder”.
So we can create SNOMED Extension concept “Fetal hematologic conditions” that will have existing SNOMED concepts for “fetal anemia”, “fetal bleeding disorder”, “fetal blood clots” and “fetal blood cancers” as child concepts.
and “fetal disorders” will be it’s ancestor concept.
@Christian_Reich, thus SNOMED Extension solves the chronic problem with “AND”, “OR” concepts.
Another idea that can help with hierarchy mismatch, i.e. Case 3
is to make “Has due to” and “Finding asso with” SNOMED relationship_id hierarchical.
SNOMED itself doesn’t make hierarchy from these pairs, but the pairs looks like hierarchical, look:
while sometimes it doesn’t work
Well, we may define a list of chronic conditions: diabetes, congenital states, AIDS, etc. and build such a hierarchical relationships for them only.
The decision is kinda questionable: to modify the official vocabulary based on the manually filtered list of the concepts.
@Christian_Reich, looks like we need to request those changes in SNOMED first.
Hi, @Dymshyts, this is excellent research. I was going to comment on the problems with concepts that identify a diagnosis but then also include some causal event that the condition is referred to. The prior example you gave where you had diagnosis of X as a result of Y (ie: Nondisplaced transverse fracture of shaft of left tibia, subsequent encounter for closed fracture with nonunion Maps to 28012007 Closed fracture of shaft of tibia), the event being identified is X (the nondisplased transverse fracture), and it’s from a prior closed fracture with nonunion (I’m assumign that’s what 'subsequent encounter for… means).
I this case, I think it’s an error to have a mapping to the fracture of tibia and a closed fracture, because the prior closed fracture happened in the past. Just record that there’s a fracture of tibia.
However, if we can create our own hierarchy inside a snomed extention: I’d say that Nondisplaced transverse fracture of shaft of left tibia, subsequent encounter for closed fracture with nonunion falls somewhere below ‘fracture of tibia’ (something like fracture of tibia-> fracture of shaft of left tibia’ but also you can find a concept under ‘fractures resulting from closed fracture’ -> fracture of shaft of left tibia, subsequent encounter for closed fracture’, etc.
But, would this explode the concept hierarchy with all these possible multi-parent relationships and including all of these X due to Y concepts? But I do feel strong that X due to Y shoudln’t result in both a record of X and Y on the same day, simply because we don’t have the information that Y occurred simultaneously. I would expect somewhere else in the medical history you’d see Y as the primary event.
The main use case for putting these types of X because of Y in a hierarchy is that commonly you’d use the vocabulary to find things like ‘skin blisters’ but not ‘skin blisters from burns’ so you’d make a concept set expression saying ‘give me skin blisters and descendants, excluding skin blisters from burns’
-Chris
Well, this is still a fracture, even if the trauma happened a long time ago.
The same approach is used to another group of concepts - “with delayed healing”, like this one:
“Nondisplaced transverse fracture of shaft of left tibia, subsequent encounter for closed fracture with delayed healing”
I like the idea of hierarchy - it’s actually what I’m suggesting.
Another example where we might need SNOMED Extension
ICD9CM concept:
E871.4 Foreign object left in body during endoscopic examination
now is mapped in this way (we are making manual review of mappings now)
Maps to 74402000 Foreign body accidentally left during a procedure (domain_id = ‘Condition’)
Maps to value 363071007 Diagnostic endoscopy
so it will not work, because we don’t have value_as_concept_id column in condition_occurrence table. So during CDM conversion we lose the information about 363071007 Diagnostic endoscopy. So now we put this Maps to value only as the vocabulary reference.
Of course instead of putting Maps to value, we can add Maps to a history of Endoscopy, but in this case we lose the connection between Diagnostic endoscopy and Foreign body.
Thus we need to make SNOMED Extension concept “Foreign object left in body during endoscopic examination”
that will have at least two relationships:
Is a “Foreign body accidentally left during a procedure”
Has Due to “Endoscopic examination”.
This is a case where it’s a combo: the foreign body was left at the same time as the exam, so 2 records can be produced ‘foreign body left in body’ and the ‘diagnostic endoscopy’. I’d argue that the foreign body was left at the time of the diagnostic endoscopy, and not when it was found (which is probably the date that you’ll get when you see the E871.4 code).
Making a hierarchy solves this problem that could otherwise be solved by creating fact-relationships that relates the foreign object left in body with the diagnostic endoscopy. Is there any concern with creating a hierarchy of all possible causes, or would this hierarchy be curated by the prevalence of these linked-concepts we find in real world evidence?
who knows, maybe they left something, and found out only the next day.
hm. we can define the rule - if the concept has several Maps to records, fact_relationship is created
Thanks @Dymshyts for starting this discussion. I’m totally with you to have SNOMED Extension. Otherwise, you’ll miss significant number of records (ultimately patients) in the cohort and analysis if standard concepts (SNOMED) are the starting point to prepare code lists. I’m seeing the effect in few of our studies.
I’m curious on your process to
Do you use any tools? Or is this a manual process? Have you assessed SOLOR? From my understanding, this open source tool will eliminate the
and
by using description logic and logical expressions to extend the vocabulary. Stanford Protege might also be of use.
Melanie
@MPhilofsky I’ve recently heard about SOLOR. Do you know if it has the mappings between SNOMED CT and ICDs? Or, it is just about SNOMED, LOINC, and RxNorm?
Can you show us those examples? We will need them to make the case for adding SNOMED Extension concepts. It’s a departure from our strong principle to not create (non-administrative) Concepts.
according to their web-site info:
“Yes, SOLOR does not map one terminology system to another.”
it’s SQL-based algorithm, but, yes for most of the mappings decision was made manually, because it’s need to be clinically evaluated.
Have you try to run it? Do you know how to use the tool?
The same question about
There’s a lot of documentation, so some guidance from someone who used it would be useful
@abedtash_hamed and @Dymshyts,
SOLOR integrates SNOMED, LOINC, and RxNorm into one common terminology model (not sure if terminology model is the correct term). And can be used to extend the terminology. Something that is being proposed in this thread. On paper, this looks to be a good tool to support the extensions. Also, SOLOR is open source, if there is a community behind SOLOR with the same ICD-SNOMED problem, then maybe all the extension work won’t have to fall on the OHDSI community.
We also have concerns about using SNOMED. We have not started using the OMOP CDM, so we have not done an assessment on the ICD to SNOMED terminology mismatch and subsequent patient additions to cohorts without the specified ICD codes. But the reality is we live in the American extension of the ICD world.
I haven’t tried SOLOR or Protege.
One more thing 
There’s still the problem of concepts, concept relationships, hierarchies becoming deprecated.
We could use the extensions to keep the deprecated codes and relationships alive.
Sure, I’ll share the results with full comparisons.
there is another proposal
in a few words: not to deprecate the concepts that become obsolete according to the source. Use deprecation if the concept was added mistakenly.
For the RxNorm drugs, since we cannot have duplicates there, should we add that we will run the MapDrugVocab script, mapping deprecated to new ones (even if to higher granularity concept)?
Wrong panel.
but anyway:) it’s a good idea. let me analyse the deprecated RxNorm concepts
