OHDSI Home | Forums | Wiki | Github

Summary for implementation

Implementers
#1

Hi all, I apologize in advance if this is redundant, but I can’t find the answers to my questions.

I am in the process of implementing OMOP from a CERNER database and have lots of doubts about the concepts. I will greatly appreciate if someone can answer the following questions with “Correct” or “Incorrect, do this instead”. My confusion is that seems like I need to convert everything to SNOMED.

  1. Starting with PERSON, the Gender, Race and Ethnicity concepts should be from the domain/vocabulary Gender, Race and Ethnicity respectively, if unknown concept is 0, correct?

  2. For the DEATH table, “death type concept” should be from the domain/vocabulary Type Concept/Death Type and “cause concept” should be a a domain/vocabulary condition/SNOMED, correct?

  3. Similarly for table CARE_SITE “place of service”, OBSERVATION_PERIOD “period type” and VISIT_OCCURRENCE “visit” and “visit type” should be from the domain/vocabulary Place of service/Place of Service, Type Concept/Obs Period Type, Visit/Visit and Type Concept/Visit Type, correct?

  4. For CONDITION_OCCURRENCE and PROCEDURE_OCURRENCE the “concept_id” should be SNOMED from the Condition/SNOMED, the “type concept” should be from the Type Concept/Condition (or Procedure) Type and the source concepts are the ones in which my original data is, which in this case will me mostly ICD9 and 10 and CPT, correct?

  5. Finally… if my data is in ICD or CPT, I need to map it to SNOMED first, should I use the CONCEPT_RELATIONSHIP table to do this with a relationship field to “Maps to” and the concept be Condition/SNOMED ?

Thanks in advance.

EV

2 Likes
#2

1 - 3look correct, but items 4 and 5 are incorrect

You should use the concept_relationship ‘Maps to’, but you should not limit
to query to SNOMED. Most procedure codes will map to the same vocabulary
that is CPT codes will mostly map to CPT codes and it will often be the
case that the procedure_concept_id and procedure_source_concept_id point
to the same concept. Most ICD codes will map to SNOMED. But there is
another important step that you seem to be missing. When you use the ‘Maps
to’ relationship the target table that the source data ends up in is
determined by the concept_domain_id of the ‘mapped to concept’.

For example
CPT4 90717 maps to concept id 2213475 which has a domain_id of ‘Drug’, a
Drug Exposure record should be created.
CPT 0503F maps to concept id 2101832 which has a domain_id of
‘Observation’, an Observation record should be created.
ICD10CM maps to concept id 435997 which has a domain_id of ‘Observation’,
and Observation record should be created

This idea of the domain id of the target concept determining where the
source record ends up in the CDM is one of the trickier parts of the ETL.
From you listed items, I am not sure that your ETL takes this into
account. See the ‘DIFFERENTIATING BETWEEN SOURCE VALUES, SOURCE CONCEPT
IDS, AND STANDARD CONCEPT IDS’ section of the CDMv5 spec.

1 Like
#3

Thank you so much, that makes so much sense, al this time I thought that concepts are to be mapped to only one other concept.

Just one more clarification, so in this particular case, ICD 9 and ICD10 codes should be primarily be mapped to conditions on the SNOMED CONDITION_OCCURRENCE and might have a SNOMED OBSERVATION, while CPT might be SNOMED on CONDITION + NDC on DRUG + CPT on PROCEDURE + HCPCS on PROCEDURE, again mostly, all depending on the code. Sometimes they match to only one thing, other times to more than one thing in different OMOP tables.

Again thanks.

#4

I know I’m more guilty than most of being sometimes loose with my language
about this topic, but for clarity sake, I’ll try to be precise here: I
think it’d be more proper to think about is as: ‘you should only map your
source codes to standard concepts, and each standard concept belongs to one
domain, which thereby tells you where to put the source code’. That is,
don’t think about it as each domain has one standard vocabulary, but rather
each domain has a set of standard concepts, which together may come from
one or more vocabularies. Also, don’t assume you know the domain of your
source code until you’ve mapped it to a standard concept: ICD9 diagnosis
codes do not all go to CONDITION_OCCURRENCE, because some of the codes are
in fact procedures (e.g. cancer screening) or observations (e.g. family
history of…) Some CPT/HCPCS codes actually reflect drug use, not
procedures, etc. Instead, you can consistently apply the following steps
as part of your ETL process:

  1. find the source concept id associated with your source code (look up in
    CONCEPT table, commonly looking in CONCEPT_CODE for the source code
    string),
  2. map your source concept to a standard concept using a valid
    CONCEPT_RELATIONSHIP record,
  3. look up the domain_id of the standard CONCEPT_ID,
  4. ETL your source data into the standard domain, storing the source value,
    source concept_id, and standard concept_id along with any domain_specific
    attributes.
1 Like
#5

thank you all for the input, now I feel I am making great advance.

Just one more quick question.

What should I do when I get a map to (CONCEPT_RELATIONSHIP) a Invalid concept?

Thanks again.

#6

Hi, @Emanuel_Villa my organization starts this year a new OMOP implementation project and we are one of the few Cerner shops in the Epic world :smile:

I found that Epic users have more experience and even some shared ETL/dev. resources, I thought perhaps you could share any ETL, OMOP mapping resources that you developed at your organization?

I also want to include @Christophe_Lambert as he also asked similar question some time ago.

Thank you!

#7

Cerner actually has its own internal OMOP project. Want to get connected?

1 Like
#8

We would also like to know about any ready-to-go Cerner HealthFacts ETL. Yonghui Wu and colleagues presented a poster on their Cerner HealthFacts ETL at the OHDSI 2016 symposium. I reached out to them afterwards, and they reported they were still working on it. I’ll ask them again…

#9

@Christophe_Lambert, we created a Cerner HealthFacts ETL at Janssen. It does not incorporate every table as there are many but it hits the big ones. We had to make a decision early on not to include the surgery tables as they didn’t have as much useful information for us and because we had limited time due to our licensing agreement. All documentation including test cases are located here: https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man/CERNER

#10

HI @mtomas, the Janssen team has developed an ETL for Cerner HealthFacts located here: https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man/CERNER and I would be happy to set up some time to meet with you if you would like to discuss a little more about our process of conversion to the OMOP CDM.

1 Like
#11

Absolutely! Thank you, Christian!

#12

That’s true. I wrote an email to him, we’ll see if he will respond.

I do not have right to replay to this topic per forum rules, so I guess for more in depth discussion I will have to reach you via PM.

Also adding: @Daniella_Meeker and @shawndolley as they were interested in similar topic earlier.

#13

Hi, @clairblacketer great info and definitely looking forward to meet with you in person or virtually :smile:

Our system (Cook County HHS) is one of the bigger Cerner sites, so it will be interesting to see how it goes… On the other hand, at this point we do not take data directly from Cerner but through the aggregate DBs of our BI unit, but perhaps there is a place to discuss possibility of dealing directly with Cerner tabeles directly. What was your situation?

And if Cerner itself is developing some kind of OMOP ETL solution, then it would be even better.

#14

Hello all, today our institution had a meeting with Cerner people, particularly with @tmckaig and the good news is that in 2019 HealthFacts dataset will be using OMOP CDM, so there will be no need for any conversions.

1 Like
t