OHDSI Home | Forums | Wiki | Github

Proper table for chief complaint / reason for visit?

(Tim Quinn) #1

Into which OMOP table should we load the chief complaint that is the reason for an encounter such as an ED visit?

I perceive the options are:

  1. condition_occurrence
  2. observation
  3. <none; chief complaints aren’t provider diagnoses, so they shouldn’t be loaded>

I know that past medical history, being self-reported by the patient, should be loaded to OMOP’s observation table, so perhaps chief complaints also should be loaded to observation?

A search of the forum uncovered the following post by @Christian_Reich indicating the condition_occurrence table, but perhaps it has been superseded by later thinking:

(Christian Reich) #2

We stand steadfast by our thinking, @quinnt. Conditions are recorded in CONDITION_OCCURRENCE and contain diagnoses, signs and symptoms as explained there. The provenance (e.g. EHR chief complaint record) is laid out in the condition_type_concept_id, and the nature or maturity in the condition_status_concept_id.

Suspicions, exclusions and history of disease are Observations, though.

Bottom line: The answer is 1.

(Tim Quinn) #3

Thank you @Christian_Reich for the clear and definitive verdict!

(Melanie Philofsky) #4

As always, the domain_id for the standard concept_id will direct you where the source data lives in the OMOP CDM. You will find many chief complaints/reasons for visits will live in the Procedure and Observation tables. Use type_concept_id = 32822 to distinguish these records from actual Procedure or Observation records. Just because a Person has a reason for visit = endoscopy/hip replacement/vasectomy doesn’t mean the procedure was performed. Make sure to warn your CDM users about this. Unless I am specifically studying symptoms or chief complaints, I would eliminate all records with *_type_concept_id = 32822 from a study. Also, I have seen reasons for visits/chief complaints that look like a diagnosis, i.e. stroke, COPD, heart attack, but are actually a follow up appointment for an event or self diagnosis.

Because of the “risk” for incorrect interpretation of data, especially with network Atlas studies where type_concept_id isn’t always specified, Colorado has decided to ETL all chief complaints/reasons for visit to the Observation table using standard observation_concept_id = 3019237.

@Christian_Reich I know there is a lot on our CDM WG plate, but this might be something to put on the to do list. Whether we make the type_concept_ids a more prevalent and educated choice in Atlas or we change our conventions around symptoms/chief complaints/reason for visit data, a discussion is warranted. There are a lot of these data in the EHR, many folks ETL it to the CDM, and OMOP EHR data are used more and more often in network research.

(Christian Reich) #5

I am not following. What is it you would like us to do?

(Melanie Philofsky) #6

I would like to open a discussion on whether we should make a proposal for Atlas to make the type_concept_ids a more prevalent choice in Atlas, so end users don’t mistake a Person’s chief complaint of stroke with an actual diagnosis of stroke or a Person’s claim for reason of visit to be a Procedure versus a Person actually receiving a Procedure. Or maybe move this data into the Observation domain and use concept_id = 3019237, chief complaint - reported.

Last time I looked, which has been a while, Atlas didn’t force the user to pick a type_concept_id. The default is to pull data from all type_concept_ids. If you’re doing a study which is looking at an initial event of “myocardial infarction” and the condition_type_concept_id is not specified, then you could be including folks with a chief complaint or reason for visit = “heart attack”, but after examination and testing by a Provider it is determined the Person has a different Condition. Or if you’re doing an inpatient study, it doesn’t matter which drug was ordered, it matters which drug was administered because the administered drug is an actual drug exposure. Every inpatient visit includes at least a handful of various ordered, prn drugs to alleviate sleeplessness, pain, constipation, fever, cough, etc. Most of which are not given.

I know that small quality issues in data are washed out by our very large datasets, but EHRs have a large amount of these data. In the datasets I have seen, this is recorded almost every time a Person has a Visit.

From my experience, there is a lack of knowledge around this field and EHR data in general. Colorado has participated in research which didn’t specify the type_concept_id. Causing study leads to think we had duplicated data in our CDM, when in reality we have ordered, administered and dispensed drug data which amounts to multiple records for the same drug and dose on the same day. Maybe I’m worrying about something that doesn’t really have an affect on results. Thoughts?