OHDSI Home | Forums | Wiki | Github

Concept Type consolidation - please take a look

The condition_status is good.

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

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.

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?

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?

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.

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

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!!!

@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:

Thanks, @Christian_Reich!

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

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?

We can add. We have them internally. Didn’t think it would help, but hey, seems it does. Next release.

Hi,

Is a measurement recorded by the monitor or the ventilator defined by type_concept EHR 32817 ? Or is there another which references measurement collected by a machine ?

It might be good to add non-standard to standard mapping relationships from the spreadsheet to OHDSI vocabulary.

@alexander do you mean these?

Looks like a really good idea.

Have you guys used this table and validate the mapping proposed by @DTorok ?

We had those started, but then didn’t bring them in. Reasons: (i) lack of use case (nobody has Type Concepts as source data), (ii) ambiguity in the maps and (iii) lack of a Wide Mapping table. Some of them have to be split into Status concepts.

We used them in our ETL and after updating version of dictionaries we had to re-map few concepts manually as they are not standard any more.

I can’t say it was a big deal for us, but it would be better to have non-standard to standard mapping after the consolidation of some concepts in the vocabs to make the update easier. It looks a little weird when type concepts are not standard anymore and are not mapped to standard ones.

I agree. This has been an issue for some our sites. If the “maps to” could be added to these deprecated concepts, it would make life easier for many ETLs.

We did it intentionally in order to avoid ambiguity in mapping of those that can’t get 1-to-1 links.

t