OHDSI Home | Forums | Wiki | Github

Custom concepts for *_type_concept_id and *_status_concept_id columns

Implementers
#1

Hello,

For our OMOP implementation we would like to use some custom concepts, but I can’t find a comprehensive convention or best practice on how to use them. The only “rules” we found, were best practices given to us through the EHDEN project, stating that custom concepts needs a >2bilion number in the *_source_concept_id column and a 0 in the *_concept_id column. But there are no *_type_source_concept_id or *_status_source_concept_id columns.

How should we go about using custom concepts for *_concept_id_fields like condition_status_concept_id, condition_type_concept_id…
We need it to differentiate between conditions found in different record types coming from electrocardiography recording machines.

Our current approach is just using the >2bilion numbers in the normal concept_id columns, since it is clear by the id-number that these are non-standard custom concepts.

Kind regards,
Stijn

#2

You should not create your own concepts for OMOP defined columns such as condition_status_concept_id. Data Quality Dashboard may flag them as errors and analysis programs will not know what to do with them. Use the standard concept for those fields. If you need to differentiate between conditions found in different record types coming from electrocardiography recording machines add a new column to Condition Occurrence and use your custom concepts to populated this new column.

#3

@StijnAZD:

What @DTorok said.

What EKG records do you need to distinguish where they are coming from, and is this a condition status? Conditions are diagnoses, signs or symptoms.

#4

@Christian_Reich : The EKG records contain diagnoses, so they should go into the condition_occurrence table. We want to differentiate those diagnoses from diagnoses extracted from our EHR through different condition_type_concept_id’s, but can’t find a matching standard concept.

@DTorok : So if I understand correctly, to use these custom concepts, we would have to put 0 in the condition_type_concept_id field (because there is no useful matching standard concept) and our custom concept id in a new condition_type_source_concept_id column? Seems somewhat redundant, as being over 2 bilion clearly identifies custom concepts already, but I can follow the compatibility argument.

#5

@StijnAZD

Not every standard concept_id field is going to contain a concept_id which exactly matches your source code description. And that’s ok. The standard concept_id fields are used for network research. For your internal research needs, you can add additional fields to every table in the OMOP CDM and not “break” any network research studies or software tools. What we have done in Colorado is add additional fields to our CDM. One of these fields is the source table name, this makes it easy for us to see where the data came from at the source. See this poster for additional information on customizing your CDM.

I wouldn’t have your condition_type_concept_id = 0, you should map it to the closest standard concept_id. For your example, I think EHR Physical Examination might be a good enough match. Then adding an additional column for the source table will give you further information about where these data are from.

#6

@MPhilofsky : thanks for your reply, we’ll adapt our ETL to follow the standard, with additional source columns.

For us, it wasn’t clear from the documentation how to reconcile our internal needs with the standard conventions; we couldn’t find any explicit rules on how to deal with custom concepts. We assumed the standard tools would be able to deal with the custom concepts, as their id is easily differentiable and analysis would still be possible if the proper relationships to standard concepts are set (e.g. make our custom concept a descendant of the EHR Physical Examination concept).

#7

@StijnAZD,

You’re welcome! We, the OHDSI community, have just revived the Themis working group. The goal is to “Define and document conventions on how the data are stored in the CDM”. And your question is just the type of thing we would like to document in our conventions. Would you please post this to the Themis Github site here? Themis is just starting out and I am trying to organize the community needs while also setting up the WG and Themis process for handling these requests. I don’t want it to fall through the cracks since this question has come up more than a couple of times. Thanks!

Also, our first Themis WG meeting was yesterday, you can watch it here, our WG page/channel is here, and we would love to have you join our work group calls. New community members have a fresh set of eyes and can spot gaps in the documentation much better than those of us who can recite the rules & best practices by memory. Our next meeting will be Thursday, April 20th at 7:30am Eastern Time here.

1 Like
t