OHDSI Home | Forums | Wiki | Github

Reason for admission in the condition table?

Implementers
#1

Dear OHDSI community.

I’m implementing OMOP CDM v6 for a network of ICU registries in South Asia.

We previously collected reason for ICU admission using APACHE IV diagnosis codes (we are moving towards using SNOMED).
APACHE IV diagnoses are divided into ‘operative’, eg appendectomy, and ‘non-operative’, eg anaphylaxis. These are recorded at the time of ICU admission and actually represent the reason for admission to the ICU.

I have 2 questions:

  1. Operative diagnoses (appendectomy, hip replacement) appear to fall into the procedure domain instead of the condition one. Is it acceptable to put these ‘operative diagnoses’ into the procedure table, instead of the condition one?
  2. We don’t know the time these diagnoses and procedures were made or carried out. The nearest time we have is the time of ICU admission. Is it ok to save these reasons for admission in the condition and procedure table with ICU admission time as the time of diagnosis and procedure? If not, how do I indicate that these diagnoses are actually ‘reasons for admission’?

Thanks,
Aasiyah.

#2

They belong in the Observation table. See here

#3

Thanks for pointing this option out. I had previously considered it, but have some concerns.

  1. Do you suggest storing both ‘operative’ and ‘non-operative’ diagnoses under the reason for admission code in the Observation table? The SNOMED parent for that code is ‘procedure related observable’, and I’m not sure that fits in well with the ‘non-operative’ diagnoses, as these are not procedures.

  2. I’m not convinced there is a difference between reason for admission and diagnosis for the ‘non-operative’ diagnoses. How is Pneumonia recorded as the reason for admission in the observation table different to Pneumonia recorded in the condition table, with a diagnosis time the same as the time of ICU admission (the first opportunity for the diagnosis to have been made in our dataset)?

  3. Does storing this data in the observation table make it harder for something like ATLAS to provide data summaries or separate patients out into cohorts?

  4. It’s possible for a patient to have more than just a primary and secondary reason for admission recorded. Are all further reasons for admission also ‘secondary’?

Thanks,
Aasiyah.

#4

This is the right choice.

Obviously, that is a problem, because time is all we have in most cases to determine what is cause and what is consequence in observational research. However, this is pretty typical. For example, diagnoses are often only declared at discharge time, rather than when the condition actually occurred. So, feel free to put in the best date you can glean from the data and watch out when you or somebody else wants to use this for research.

This is an elegant solution, but we haven’t made that convention. That means nobody knows you are hiding your data behind those observations. So, I wouldn’t recommend it, @MPhilofsky.

I would store neither there. Conditions go to CONDITION_OCCURRENCE, Procedures to PROCEDURE_OCCURRENCE.

The true conditions (e.g. “pneumonia”) goes into the Condition table. If you want to characterize when and for what purpose the diagnosis was made use the condition_status_concept_id field and the appropriate concepts.

Exactly.

We don’t have a “reason for admission” for procedures. We only have Condition Status concepts. An appendectomy is not the reason for an admission, the underlying appendicitis is. Appendectomy is an intervention. Of course in many cases there is only one reasonable intervention. But even in the appendectomy case the decision could be made not to go to surgery (if the inflammatory response is already over).

#5

Ah, I was viewing this question differently. I thought @aasiyah wanted to store the “reason for admission” / why the Person needed to be in the ICU / justification for transfer to the ICU. With the ‘reasons’ being related to a diagnosis (increased oxygen demands or unstable cardiac arrhythmia) or procedure related (post-op CABG, post-op lung transplant).

#6

Thanks @Christian_Reich and @MPhilofsky

I will go with putting ‘operative’ diagnoses in the procedure occurrence table, and ‘non-operative’ ones in the condition occurrence table. I’ll use admission date as the date time available.

We don’t have a “reason for admission” for procedures. We only have Condition Status concepts. An appendectomy is not the reason for an admission, the underlying appendicitis is. Appendectomy is an intervention. Of course in many cases there is only one reasonable intervention. But even in the appendectomy case the decision could be made not to go to surgery (if the inflammatory response is already over).

Agreed. We’ve made the distinction between ‘diagnosis’ and ‘operation’ clearer in our updated SNOMED version of data collection.

Ah, I was viewing this question differently. I thought @aasiyah wanted to store the “reason for admission” / why the Person needed to be in the ICU / justification for transfer to the ICU. With the ‘reasons’ being related to a diagnosis (increased oxygen demands or unstable cardiac arrhythmia) or procedure related (post-op CABG, post-op lung transplant).

I understand. Thanks for the suggestion. We’d like to use the information for clinical characterisation of patients, so to us, it doesn’t explicitly need to be recorded as a ‘reason for admission’.

t