Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNOMED Extension proposal #185

Open
clairblacketer opened this issue Jun 5, 2018 · 0 comments

Comments

1 participant
@clairblacketer
Copy link
Contributor

commented Jun 5, 2018

original forum post along with comments

Proposal itself:
To add SNOMED-like concepts with SNOMED-like relationships and hierarchy
that allows us to make accurate condition mappings.

Rationale:
Mapping from ICD9CM and ICD10CM are pretty good and equal in general.

But sometimes we meet a bunch of problems related to inequality of the ontologies.

Here are the examples of mappings where we can't find exact match.
The cases below are grouped by the way of mapping:

Case 1. Mapping to a more general concept

M99.03 "Segmental and somatic dysfunction of lumbar region" Maps to 203708004 "Segmental and somatic dysfunction"
M99.00 "Segmental and somatic dysfunction of head region" Maps to 203708004 "Segmental and somatic dysfunction"
G96.11 "Dural tear" Maps to 15758002 "Disorder of meninges"
I77.812 "Thoracoabdominal aortic ectasia" Maps to 26660001 Dilatation of aorta

Advantage:
Although we don't have corresponding concept, we can put the condition into CDM. And it will work good in case if cohort definition includes some general criteria (i.e. Segmental and somatic dysfunction regardless of region, Dilatation of aorta regardless of the region).
Disadvantage:
It will not work at all if somebody wants to find patients with "Segmental and somatic dysfunction of head region", opposite the cohort will include all the patients with Segmental and somatic dysfunction of any region, that makes much bigger count

Case 2. Mapping to a several concepts describing condition and co-occurring condition

E10.321 "Type 1 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema Maps to 138881000119106 "Mild nonproliferative retinopathy due to type 1 diabetes mellitus"
E10.321 "Type 1 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema Maps to 312912001 "Diabetic macular edema"

G43.001 "Migraine without aura, not intractable, with status migrainosus" Maps to 230467008 "Status migrainosus"
G43.001 Migraine without aura, not intractable, with status migrainosus Maps to 56097005 "Migraine without aura"

Advantage: although we don't have corresponding concept, we can fully represent the patient condition in CDM, both conditions will have the same visit_occurrence_id (if given) and the same visit_start_date, visit_end_date.
So if the cohort definition includes the patients exactly with "Migraine without aura, not intractable, with status migrainosus", you need to find the patients with descendant concepts of "Migraine without aura" and "Status migrainosus" within the same visit_occurrence_id (if given) and visit_start_date, visit_end_date.
Disatvantage: Such a process of grouping by visit_occurrence_id (if given) and visit_start_date, visit_end_date makes the process of adding patients to the cohorts more complicated and less transparent and requires Atlas quries modification also.

Case 3. Mapping to a same-meaning concept but with different hierarchy (ICD10CM and SNOMED uses different principles for hierarchy sometimes)

E10.21 "Type 1 diabetes mellitus with diabetic nephropathy" Maps to 421893009 "Renal disorder associated with type 1 diabetes mellitus"
421893009 "Renal disorder associated with type 1 diabetes mellitus" doesn't have "Type 1 diabetes mellitus" as an ancestor, it actualy belongs to a Renal disease branch
So making cohort of Type 1 diabetes mellitus patient including descendant concepts of "Type 1 diabetes mellitus" miss the patients with "Renal disorder associated with type 1 diabetes mellitus". Thus to make a cohort definition the user needs to make complex cohort definition taking diabetic complication separately

F11.1 "Opioid abuse" Maps to 5602001 "Opioid abuse" 438130
while F11 "Opioid related disorders" Maps to 14784000 "Opioid-induced organic mental disorder"
And again, 5602001 "Opioid abuse" isn't a child of 14784000 "Opioid-induced organic mental disorder". So to find all the patients who used opioids the user need to make complex cohort definition, not just take all the descendants of F11 "Opioid related disorders" standard concept.

As you can see ontologies mismatch can lead to a wrong cohort definition.
Such cases are not very often, but still user needs to aware of them, thus it's needed to check the mappings every time creating a cohort.

Obviously, some decision need to be done.

From the vocabulary user perspective the best decision is to add to the vocabulary SNOMED-like concepts (SNOMED Extension) that have exact match to a given source vocabulary.
In this case vocabulary user don't need to use any additional queries and go through mapping peculiarities - just use the usual concept_relationship to go from the non-standard vocabulary concept to a standard one.

These SNOMED-like concepts will have hierarchical relationships as SNOMED concepts have. Thus using concept_ancestor the user will get the accurate cohort definition.
Let's consider this according the cases listed above:

Case 1
now:

M99.03 "Segmental and somatic dysfunction of lumbar region" Maps to 203708004 "Segmental and somatic dysfunction"
SNOMED Extension way
M99.03 "Segmental and somatic dysfunction of lumbar region" Maps to SnExt1 "Segmental and somatic dysfunction of lumbar region"
this concept has 203708004 "Segmental and somatic dysfunction" as parental concept

Case 2
Now:

E10.321 "Type 1 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema Maps to 138881000119106 "Mild nonproliferative retinopathy due to type 1 diabetes mellitus"
E10.321 "Type 1 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema Maps to 312912001 "Diabetic macular edema"
SNOMED Extension way
E10.321 "Type 1 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema Maps to SnExt2 "Type 1 diabetes mellitus with mild nonproliferative diabetic retinopathy with macular edema"
XXXX has 138881000119106 and 312912001 as parental concepts.

Case 3
E10.21 "Type 1 diabetes mellitus with diabetic nephropathy" Maps to SnExt3 "Type 1 diabetes mellitus with diabetic nephropathy" that have parents from both hierachies:
"Diabetes type 1" and "Disorder of Kidney"

@abedtash_hamed case

github.com/OHDSI/Vocabulary-v5.0

Issue: Mismatched ICD-9/10-CM to standard concept mappings
opened by abedtashh on 2018-01-05
I analyzed the mapping of a code list of malignant neoplasms of bronchus and lung neoplasm diagnoses in ICD-9-CM and ICD-10-CM...

C34 Malignant neoplasm of bronchus and lung now is mapped to Malignant neoplasm of respiratory system (not specific)
so we'll map to a SNOMED Extension equivalent which will have children
93734005 "Primary malignant neoplasm of bronchus"
and 93880001 "Primary malignant neoplasm of lung"
The first step - to build a hierarchical structure,
the second step is to allow the post-coordination that cannot be implemented in CDM itself
For example
now
C90.00 "Multiple myeloma not having achieved remission" Maps to 109989006 "Multiple myeloma"
so we lose the information about remission status
If we create new concept "Multiple myeloma not having achieved remission" it will have parental concept 109989006 "Multiple myeloma" and will have the link to a qualifier 03336008 "No mention of remission"

This approach looks quite time consuming, but it will solve all the condition mapping related problems.
Step 1 with hierarchy build is relatively easy as we already have mappings to a multiple concepts
also we can identify the cases when it's mapped to a more general concept and build hierarchy.

Please let me know you thoughts and suggestions

@clairblacketer clairblacketer added this to In progress in CDM v6.0 Jul 16, 2018

@clairblacketer clairblacketer moved this from In progress to on Dev branch/in development in CDM v6.0 Oct 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.