OHDSI Home | Forums | Wiki | Github

How to convert non diagnosis related but ICD code info to OMOP CDM standard

Vocabulary Users
#1

Hello Everyone,

We are currently trying to map our diagnosis codes to the OMOP CDM standard. While majority of our source terms had a relevant mapping in Athena, I would like to specifically check with you on the below terms

Medical care, unspecified
Examination and observation for an unspecified reason (Z04. 9)
Person awaiting admission to other health care facility (Z75.1)
Unspecified Reason For Consultation (V65.9)
Other Reasons For Seeking Consultation (V65.8)

I have few questions wrt the terms shown above

a) While I find these terms under our raw diagnosis data, I feel they don’t really indicate patients’ problems/symptoms/conditions. However, they have a corresponding ICD code for them. So, should they still go into the condition_occurrence table in OMOP CDM?

b) I don’t find any matching concepts for these terms in Athena under “Condition” domain. I look for condition domain because the raw data is from diagnosis domain…

c) I also checked in other domains such as observation but no luck. So, we have currently mapped it to zero. Moreover, they occur very rarely in our data. (less than 50 records)… But would like to understand the process/procedure.

#2

@SELVA_MUTHU_KUMARAN:

There is no diagnosis, which means, don’t write a Condition record. You really don’t need these “something, but I don’t know what” records. They cannot be used in an analytical use case. But if you think those records indicate more than some administrative artifact and the patient has a problem do write an empty (concept_id=0) Condition.

#3

@SELVA_MUTHU_KUMARAN,

Have you read The Book of OHDSI? Specifically, chapters 4,5,6? These chapters tell you to look up your source code in the Concept table and then map it to a standard concept_id using the Concept Relationship table. The concept.domain_id for the concept_id where standard_concept = ‘S’ will tell you where the data lives in the CDM. You MUST follow the rules or your data will be unusable in any network query.

You don’t find them because they don’t live there. v65.9 has a standard domain_id = Observation.

#4

Isn’t this a rule or at least a convention?
https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#Source_Values,_Source_Concept_Ids,_and_Standard_Concept_Ids
says:

  • If the Source Value cannot be mapped to a SOURCE_CONCEPT_ID or Standard CONCEPT_ID, then direct the data record to the most appropriate CDM domain based on your local knowledge of the intent of the source data and associated value. For example, if the un-mappable Source Value came from a ‘diagnosis’ table then, in the absence of other information, you may choose to record that fact in the CONDITION_OCCURRENCE table.
#5

Yes. That’s right. If you think you need to write a condition but can’t map it then write one with the concept_id=0. If not, don’t. Where is the problem?

#6

I was thinking about what to do when I have data that is not using a clear coding system and I have some records that might be only administrative artifacts (a laboratory system where most of the records are results of measurements but there is also “free text” metadata about the measurements). Do I have to load them using most probable domain (in this case measurement)? Currently I think I have to, until they are mapped to standard concepts or identified as administrative artifacts (I am the ETL person that has no medical knowledge. I can make guesses about obvious cases like “cancelled” . The medical experts are going through the possible values so this is only a temporary problem -> no problem at all).

#7

@prikala:

The OMOP CDM is no attic, where you put in data “in case you might need it”. Remember, your data are for you, but the CDM is for the community. They don’t know what to make of those records which have a life only in a local context. So, sounds to me like you throw them out, but who knows. Do you have examples?

#8

This is good, I will use this…

I’m sorry, not at this time. The source data is complicated and it is too early to say what will be mapped and what is left unmapped
(I discussed this with the medical expert just today).

t