OHDSI Home | Forums | Wiki | Github

Concept Type consolidation - please take a look

CDM Builders
#41

Got it. Thanks!

#42

Thought it would be helpful to include the new Domain-free concept_id along with their names. See

#43

If you are unfortunate and still working with vocabulary 4.5 there is an error in implementation. All the concepts in columns A and B have been dropped from the concept table in release ‘OMOP Vocabulary v4.5 28-AUG-20’.

#44

@Christian_Reich,

Now that the new type concept_ids are out for use, I’m circling back to type_concept_ids for Death data.

There are only two type_concept_ids specific to death:

32815 = Death Certificate
32885 = US Social Security Death Master File

For CDM v6 the cause of death is in the Condition table. In order to identify the cause of death from other conditions, we need an appropriate type concept_id. 38003569 = ‘EHR record patient status “Deceased”’, was a good one. However, it’s been deprecated. Also, Registry data will have Death data and is commonly used to enhance EHR data. So, a Registry for death type_concept_ids is needed. This will also help out Colorado with their v5.3.1 OMOP :slight_smile:

#45

Got it. So:

EHR deceased status record - child of EHR
Registry death record - child of Registry

Like that?

#46

Perfect! Thanks!

Condition_occurrence, Death diagnoses
#47

Actually, I repeal.

The identity of a Condition is in the Condition Status. There are a bunch of those assigned to cause of death. And then use EHR and Registry for the provenance. No need for any new concepts.

Thoughts?

#48

Hi all, could you clarify the usage of new consolidated type concepts for Clinical Trials datasets.
In many CT datasets, the provenance of data is only a CRF. Does this mean 32809 - Case Report Form should be used for conditions, observations, measurements, etc. or 32817 - EHR is a better option?

#49

I found my way to this thread after being confused by the various “Type” vocabularies still present in Athena. I am grateful that these Type Concepts were cleaned up and consolidated!

I have a question about the right concept to use for vital signs. In the inpatient setting, these are typically recorded by the patient’s nurse on a flowsheet, but I do not find any “EHR flowsheet” concept. The concept “EHR nursing report” (Concept ID 32832) doesn’t sound like a proper substitute. What are others using?

What about vital signs taken by a nurse in the context of an outpatient office visit, before the patient sees the clinician? “EHR physical examination” (Concept ID 32836) could be used, but a physician may draw a distinction between these “rooming” vital signs (for example, BP via automated cuff) and vital signs taken by the physician (manually, because the automated cuff readings are sometimes inaccurate).

#50

The condition_status is good.

What’s the difference between concept_id = 32891 ‘Cause of Death’ and 32895 ‘Death diagnosis’?

#51

Not sure I understand the question. 32809 “Case Report Form” is the Type if that’s where the data are collected from. If they are collected from the EHR than 32817 is the answer. The Types are used to indicate to analytical use cases if they want to prefer or suppress certain sources of information.

#52

Happy to hear that. :slight_smile:

I would take actual analytical use cases to determine if another Type is needed. Do you have one? Would you only want data from the flowsheet? Is your task to find out if nurse or physician measured vital signs result in different outcomes? @MPhilofsky? Any opinion?

#53

We use “EHR physical examination” concept_id = 32836 for vital signs.
You can differentiate the “Provider” who took the measurement by using the provider_id in the Measurement table.

How do you make this distinction with your source data?

#54

I consulted one of our physician informaticists on this question regarding the provenance of vital sign measurements. As @MPhilofsky suspected, there does not seem to be a difference in how vital signs are stored in our EHR’s underlying database – at least, given our EHR configuration choices.

I also checked if there are research questions that require distinction(s) beyond the context provided by the OMOP measurement table’s foreign keys:

  • person_id
  • provider_id
  • visit_occurrence_id
  • visit_detail_id

Perhaps as @Christian_Reich anticipated, we couldn’t think of any. For example, automated vital sign readings from telemetry in certain care settings would be obvious from those care settings.

I think we’re okay using “EHR physical examination” or simply “EHR” for vital signs.

#55

Thank you @Christian_Reich!
Yes, I meant the data were collected from eCRF, so 32809 is appropriate.

#56

If we want to indicate primary admission diagnosis or secondary discharge diagnosis in the condition_occurrence table then you can select this combinations of condition type and condition status codes as below?

  • condition_type_cocept_id = 32818 (EHR administration record) AND condition_status_concept_id = 32902 (Primary diagnosis)

  • condition_type_cocept_id = 32823 (EHR discharge record) AND condition_status_concept_id = 32908 (Secondary diagnosis)

I’d like to find out if this is the right way to do it and what the OHDSI community thinks. Thanks!!!

#57

@Jungmi:

Not quite. The Type Concepts declare the source of the information, not the content of the information. So, 32818 “EHR administration record” means we know about this administration (of a drug or device) from a record in the EHR. Likewise, the 32823 “EHR discharge record” means the information is gleaned from the discharge record. That might be a discharge diagnosis, but needn’t be. Discharge summaries can also contain information about the admission (“Patient XYZ was referred to our institution with a diagnosis of …”.

Both of what you need is in the Condition Status Concepts. They are pre-coordinated for primary and secondary, and admission and discharge:

#58

Thanks, @Christian_Reich!

#59

Is there a lookup from the ‘old’ type concepts to the new consolidated type concepts?

#60

I was looking for the same thing. It seems like the old type concepts. For example, ‘Radiology Report’ (44814641) does not map to the new standard code. @Christian_Reich, will this mapping be updated in the vocabulary or will these older codes become invalid?

t