OHDSI Home | Forums | Wiki | Github

Atlas inconsistently supports partial matches of ICD source codes when defining cohorts

General
#1

I need to use a set of ICD10 codes and DRG codes to define a cohort in Atlas.

Steps to replicate this bug:

For example, certain partial matches work, such as for importing the source code “10D00Z*” in ATLAS

image
image1352×890 39.6 KB

But certain others do not, such as “O00.*” or most others:

image
image1444×855 41.1 KB

Is this inconsistency in Atlas documented anywhere? I am worried if I mix and match the asterisk operator I might be missing source codes during import, especially in case I might be using undocumented features.

To resolve this, I am manually going through the ICD database and creating lists for codes not supported by Atlas.

For example, I mapped the delivery hospitalization cohort in https://links.lww.com/AOG/C28 to the following set of codes:

# delivery codes

O80, O82

# delivery related group codes

765.00
765.01
765.02
765.03
765.04
765.05
765.06
765.07
765.08
765.09
766.0
766.1
766.2
766.21
766.22
767.0
767.1
767.11
767.19
767.2
767.3
767.4
767.5
767.6
767.7
767.8
767.9
768.0
768.1
768.2
768.3
768.4
768.5
768.6
768.7
768.70
768.71
768.72
768.73
768.9
774.0
774.1
774.2
774.3
774.30
774.31
774.39
774.4
774.5
774.6
774.7
775.0
775.1
775.2
775.3
775.4
775.5
775.6
775.7
775.8
775.81
775.89
775.9


# cesarean/delivery codes

10D00Z* 
10D07Z*
10E0XZZ

# outcome of delivery

Z37.0, Z37.1, Z37.2, Z37.3, Z37.4
Z37.50, Z37.51, Z37.52, Z37.53, Z37.54
Z37.59
Z37.60, Z37.61, Z37.62, Z37.63, Z37.64, Z37.69, Z37.7, Z37.9


# exclude: abortion outcome 

O00.0
O00.1
O00.2
O00.8
O00.9
O01.0
O01.1
O01.9
O02.0
O02.1
O02.8
O02.81
O02.89
O02.9
O04.5
O04.6
O04.7
O04.8
O04.80
O04.81
O04.82
O04.83
O04.84
O04.85
O04.86
O04.87
O04.88
O04.89
O07.0
O07.1
O07.2
O07.3
O07.30
O07.31
O07.32
O07.33
O07.34
O07.35
O07.36
O07.37
O07.38
O07.39
O07.4
O08.0
O08.1
O08.2
O08.3
O08.4
O08.5
O08.6
O08.7
O08.8
O08.81
O08.82
O08.83
O08.89
O08.9

So sorry if this is covered elsewhere, it’s my first time trying to replicate this type of study using Atlas.

Thanks so much!
Jaan

#2

I’m surprised ‘wildcard’ works at all: the way the import from source code should work is it takes each value (separated by , or CRLF), and looks for an exact match to that value in the concept_code column. I’ll have to take a look to see if it is doing something else in the code to handle *, but it should only be making exact matches on the source code values you put into the textbox.

#3

Fantastic, thanks so much @Chris_Knoll !

Do you know what the best practice is for creating a cohort using wildcard operators to create cohorts for OMOP data then?

For example, in an SAS environment, one could use if diagnosis_variable_name in: ("Z370", "Z371", "Z372", "Z373", "Z374") then deliverydagnosis=1; or

 if substr(diagnosis_variable_name,1,4)= "Z370" |
substr(diagnosis_variable_name,1,4)= "Z371"|
substr(diagnosis_variable_name,1,4)= "Z372"|
substr(diagnosis_variable_name,1,4)= "Z373" |
substr(diagnosis_variable_name,1,4)= "Z374" then deliverydiagnosis=1;
#4

There’s no wildcard operator for defining code lists. Basically, you use the OMOP vocabulary to pick a parent concept, and then ‘include descendants’ as a sort of way to ‘input one thing but get a bunch of extra things with it’.

#5

Got it, thanks! It sounds like for importing ICD codes into Atlas using the ‘import → source codes’ interface in ATLAS , I’ll need to manually enter every code. I’ll keep doing what I was doing then :slight_smile:

#6

Yes, that is correct: be precise and specific about what codes you want to use.

1 Like
#7

If you want an easy way to get ICD9 code lists with an asterisk, you can go to http://explodeacode.jigsaw.io and make it a little easier. We built this a long time ago and we don’t have an ICD-10 version. But if it is helpful for ICD-9, please use it.

2 Likes
#8

FWIW, we are working on a new interface in Atlas for source code import which allows you to pick the right vocabulary for that source code. We should have that out by January.

1 Like
#9

Dear @Chris_Knoll and everyone else,

I know this topic is old, but I could not find a newer one, which is related to our problem in ATLAS.

I encountered a problem while trying to generate a standard concept set from ICD10 codes. I entered manually the ICD code list (more than 100 codes), separated with “,”, and ATLAS could only find the ICD codes. Even when I checked the “mapped” mark, the mapped SNOMED codes did not appear in the concept set. So therefore this concept set is not standard and we are not able to create a cohort with it.
@jaan you also mentioned, that you enter the codes manually, but did you map them then to SNOMED also manually in ATLAS, or Atlas did it for you automatically?

Do you have a solution to this problem? I found a way to find the SNOMED mapping to these codes in ATLAS, by hand, but for more than 100 codes it is very time consuming.

Best,
Agota

#10

Hi @Agota_Meszaros ,

There’s a feature in the work to help with this activity. The ‘mapped’ mark in Atlas is sued to bring source codes in that are mapped to the concept you selected as the ‘mapped mark’. But that’s the opposite of what you want (I believe you want to start with source codes and map them to standard).

So for now, that’s a manual probess but we should have a function for this in an upcoming release of atlas.

#11

Thank you @Chris_Knoll for the information! I misunderstood the “mapped” mark then. Yes, we received ICD10, non-standard codes from the researchers, and we would like map them to standard. But then until the release of this new feature, we will do it manually.

One more question (maybe really obvious to others): how can I receive information about the new Atlas releases, the updates? Is there a newsletter for that?

#12

Hi @Agota_Meszaros :

I found the issue that describes the feature, you can find it here if you are interested:

Releases are announced on the OHDSI forums (see this post) and the details about what was included in a given release is found in release notes.

1 Like
#13

Thank you! :slight_smile:

t