@aostropolets, so what you propose is to have the discussed cause_of_death table, but get rid of the original death table (logically; not focusing here on naming). Although the solution lacks the ideological modeling purity which for some reason @Christian_Reich doesn’t like, not favoring fundamentals stated by Computer Science, it is better than storing multiple death facts per a person in the death table.
Friends:
That indeed is a wonderful idea. Even purist @pavgra should also carol this, since it abolishes the formerly parallel table with a one-to-one relationship to PERSON. Not sure why this is wrong again. 
Can you put it as a proposal into the CDM WG?
@Christian_Reich, I was misled by the death_type_concept_id field which I assumed to be a characteristic of death fact and treated as a single record per person. But, thanks for your clarification, the type concept is, in fact, represents a source of death cause, so clearly it goes into the cause of death table because it has 1:1 relation with cause. Now the picture is clear for me and causes no more confusion. The only negative consequence is that we lose the link between the death date and the cause which the date was based on.
Continued thinking on the overall cause of death topic and following question appeared in my head - @Christian_Reich, why OMOP stores three separate fields (cause_concept_id, cause_source_value, cause_source_concept_id), while those basically represent a condition and could be replaced with a new record in Conditions table + a single field in death cause table, which is a reference to the new condition record? May be even death_type_concept_id can be abstracted into condition’s condition_type_concept_id field? Then, theoretically, we could totally remove the death / cause_of_death table
That is an even better idea!! We have the death date in PERSON, and the cause, as a Condition, in CONDITION_OCCURRENCE, and the fact that it comes from a death certificate in the Condition Type. Clean.
Can you make this proposal to the CDM WG?
Given the changes to the OMOP Vocabulary TYPE, what types would you use for death? Since DEATH_TYPE concept class isn’t a thing any more.
Probably need a few more than just these:
32815 Death Certificate
32885 US Social Security Death Master File
Death from medical record? Death at discharge?
Friends who might be interested:
@Rijnbeek, @clairblacketer, @Christian_Reich
See the post here. The death is recorded in the condition status fields and the provenance is recorded in the condition type field.
I’m trying to follow the other thread unsuccessfully . . .
So in CDM v5.3.2 how do I record a death at discharge record. This is how I would do it:
- Write a record to the DEATH table, with DEATH_TYPE = 32823 - EHR discharge record
- The visit that contained the death at discharge, you could have the DISCHARGE_TO be 32218 - “expired” we could also set SOURCE_VALUE as “expire”
See @clairblacketer issue:
1 Like
Non-standard concept from the UB04 vocabulary?
This is patient centric, not hospital centric. When a patient dies it goes into the DEATH (v5) or PERSON (v6) tables. Not anywhere else. A Visit is defined as a setting of healthcare provision. Dead patients don’t receive healthcare.
I know it’s non-standard but I requested it be changed to standard 
Isn’t it common practice for hospitals to discharge patients as ‘expired’ if they died in the hospital? Why couldn’t we record that information on the VISIT_OCCURRENCE record? There would still be a record either in DEATH or a value in DEATH_DATE in the PERSON table but we would just be associating a visit with the death event.
1 Like
Two reasons:
- The OMOP CDM is not the perspective of the hospital. This is the perspective of the patient. So, a Visit captures the healthcare setting the patient engages with the healthcare system.
- Because you must not record the same information twice. Death belongs in DEATH/PERSON. Like Conditions occurring in the Visit are in CONDITION_OCCURRENCE.
Oh, I thought it was going to become a standard concept, so Colorado preemptively coded the discharged to morgue/expired records as such. Oops!
However,
the new type_concept_id will cover @ericaVoss use case for CDM v5.*
V6 Death is problematic because there isn’t a type_concept_id associated with the Person.death_date in v6. If the death record lacks a cause of death, a Condition Occurrence record, there won’t be any type_concept_id associated with the death. Source provenance is an important aspect of the CDM.
The patient still is interacting with the healthcare system when they pass away, so there should be some status at the encounter level
! If you want to see it that way then indeed we should put in the Visit “morgue” as @Vojtech_Huser suggested. Followed by “Purgatory” and “Hell” or “Heaven”. We also need a one-day “Judgement Day” Visit.
But if we want to let these people rest in peace let’s not. The Visit has nothing to do with death. The fact that somebody died we already have - in the PERSON table. Why do you so badly want to repeat it?
It makes analysis easier especially if you want to know if they expired during a hospitalization rather then checking dates. I think discharged to “morgue” is a good compromise Again, I’m not saying that this replaces death in the person table or death table, but in addition. Plus, there would be a DQD check to confirm the information is aligned.
1 Like
I am following this discussion from the sideline, two things as a suggestion:
- should a dischargeto concept not belong in the CMS/place of service vocab or similar? a discharge status is more patient-centred, but would not fit in the same ‘domain’ as “other hospital” “nursing facility”, “hospice”, or indeed “morgue”, “coronar”, “funeral director/undertaker/mortician”.
- as to the question of repeating: in v5 it seems that the death_type_concept_id column in the death table is sufficient to capture a hospital-recorded death, also if there is no death certificate or so available. However, in version6 there is no mechanism yet for representing information in an EHR that a person is dead without any further knowledge about cause of death and/or precise info about date and time etc.
Or is there? The CDM-documentation indicates that such a statement should be captured in the Observation table. A record with concept_id 434489 = dead and concept_type_id =32823 - EHR discharge record should work, right? Using the discharge date as the date of observation would generally fit very well with common EHR habits in point.
Which one? What’s the use case that forces us to record it that way?
Seriously, @Karthik? The entire OMOP CDM model relies on date relationships. The source data often don’t give us reliable cross-references. We don’t even know if procedures, drugs and devices belong to a visit explicitly in many cases. And now you want to have one special situation just for death, and only for one Visit (Inpatient)? How do you intend to make people familiar with that kind of a unique exception?
Look: I know where this is coming from. Folks in the EPIC EHR have a “discharge_disposition” field and want that field back with an entry “expired”, because they are used to it. That does not count as a use case. The clause “where death_date>=visit_start_date and death_date<=visit_end_date” is not too much to ask.
The Place of Service notion was retired a while ago. It is a crude mix of different things, and outside the USA with its quasi-standardization through the CMS it makes no sense. We now have Visit concept. They define the setting healthcare is delivered, who comes to whom in which environment, what is the level of service. Death is not a healthcare setting. It’s the opposite.
V6 has Person.death_datetime and the cause of Death can be recorded in the Condition_Occurrence table with a condition_type_concept_id = EHR record or Death Certificate, etc. and the condition_status = 32891, Cause of Death.
Your suggestion would work, but I believe the provenance should belong with the record in the CDM, as we do for all other clinical event records. Consistency or a convention to explain why we are not being consistent
FYI concept_id = 434489 has a domain_id = Condition, so this record would live in the Condition_Occurrence table.
Reviving this:
Please see the following thread for additional discussion
THEMIS Conventions for Death Table to Allow Multiple Records - Version 5.4 - CDM Builders - OHDSI Forums