Store death causes in condition_occurrence table

[pavgra]

Today OMOP's death table contains information about a person's death_date and a cause of death. Discussion in http://forums.ohdsi.org/t/condition-occurrence-death-diagnoses/2609/52 figures that there may be a need for storing several causes of death per person. This means a need to have multiple records. It's clear that just storing multiple records in the death table using its current structure is not the best idea: that would bring redundancy and possible ambiguity, because of multiple death dates per a person. That's why it is reasonable to move the death date, since it's a one time thing per person, in the person table, and leave the death table for just storing the causes of death. But if we go forward, we can see that resulting death table basically stores all info presented in a condition_occurrence table, and what is more, logically, cause of death is a condition. That's why second step of the proposal is to replace the death table by storing causes of death in condition_occurrence table.

[cgreich]

@pavgra:

So, what's your proposal?

1. Remove the DEATH table
2. Move death_date and death_datetime to PERSON
3. Merge death_type_concept_id into condition_type_concept_id of the CONDITION table
4. Change the Death Type concepts into Condition Type concepts
5. Merge cause_concept_id, cause_value and cause_source_concept_id into condition_concept_id, condition_source_value and condition_source_concept_id of the CONDITION table, respectively (since they have to be in the Condition domain anyway)

That way, we know a person died, and the causes we can get by filtering for death related Condition Type Concepts.

Sounds clean, with one exception: You need to read the Condition Type Concepts in order to decide they are causes of death. There is no modeling mechanism to make this clear.

[clairblacketer]

This sounds great, I have added it to the agenda for the December meeting

[gklebanov]

@pavgra / @cgreich - great proposal, it will really make it much cleaner.

Except for #2- why do we need to "move death_date and death_datetime to PERSON" if we can just use condition_start_date and condition_start_datetime in CONDITION_OCCURRENCE table to specify when death occurred? never mind there can be multiple valid death records.

With this approach - no modification to PERSON at all

[cgreich]

@gklebanov:

True. That would be even cleaner. Except that we really hate different death dates, because then the analytic has to pick the right one. Since this is an artifact of the data (unless you are a cat you can't die more than once) it should really be dealt with by the ETL.

Let's see what the community has to say.

[clairblacketer]

@pavgra @gklebanov

I think this is a great discussion and I would like to bring it up at our 9/4 CDM meeting as it is a perfect candidate for CDM v6.0. Can you flesh this out into a full proposal? I have a link here for a proposal template - not all of it may apply since you are requesting to remove a table but it can at least get you started.

[clairblacketer]

from 9/4/ meeting, proposal:

1. Remove DEATH table
2. Use the CONDITION_CONCEPT_ID for death (SNOMED)
3. Use the CONDITION_TYPE_CONCEPT_ID to denote a condition is a cause of death in the CONDITION table
   a. Take the concepts in the 'Death Type' vocabulary and put them in the 'Condition Type' Vocabulary
   b. Concept_class_id will stay as 'Death Type'

The proper vocabulary needs to be specified on how to store cause of death, this would be:
WHERE vocabulary_id = 'Condition Type' and concept_class_id = 'Death Type'

[aostropolets]

How would you store the death with no cause then?

[clairblacketer]

I think the idea is that for each record of death, there would be a record in CONDITION_OCCURRENCE for the death itself and then a record for the cause of death. @cgreich is that right?

[vojtechhuser]

https://github.com/OHDSI/CommonDataModel/wiki/DEATH

types
http://athena.ohdsi.org/search-terms/terms?conceptClass=Death+Type&page=1&pageSize=15&query=

[pavgra]

@clairblacketer, why would you need a separate record for the fact of death? can a death happen w/o a cause?

[cgreich]

Yes. No cause means you only have a record with SNOMED 4306655 Death.

[pavgra]

@cgreich, can a death happen w/o a cause? why would you need to put records for both death fact and cause of death, when record for the cause of death indicates fact of death and not requires duplicative record.

[cukarthik]

I like how the proposal better incorporates cause of death, but I'm not sure I'm a fan of putting the death date in the condition occurrence as opposed to the person table. To me, this is the same as saying why don't we move the date of birth into the condition table and use the condition concept id 4083587 (DOB).
Sorry I missed the call today, so I might be rehashing this 😄

[cgreich]

@pavgra:

A cause of death is a Condition. Usually one so bad that as a consequence the patient dies. But from a philosophical perspective such cause of death is no different than any other condition. The death itself is also a condition, even though you are unlikely to recover from it (unless you are Jesus). So, putting both into the Condition table is legitimate. The problem now is how to connect the death to its cause. We could have used FACT_RELATIONSHIP (ugly), or the Condition Type (formerly Death Type). That's a not 100% clean from a modelling perspective, but practicable.

Why do we need the death record at all? Because we don't always have a cause. Actually, most of the time we don't.

[cgreich]

@cukarthik:

You are rehashing. We debated that up and down.

You are correct, a birth date and a death date is a symmetrical feature of each person. But from our observational data these are very different. Here is why: the birth date, like the gender and race, are modeled as fixed entities. They don't change or happen over time. While death is like any other event table: It happens at some point in time. You could argue that:

• Race and Gender can change, or might have to be corrected after a mistake. That's true, but in our model they are assumed static.
• Birth day is an event with a date. That is true, but not in our model. We don't have records in the PERSON table before they were born, In our model, there are no people without a birth date. But there are plenty of people who are not dead, and then they die. So, the former is de-facto static, the latter dynamic.