There isn’t a Death table in v6. It’s now Person.death_datetime. No date, no death
Well, that explains why no one else was seeing what was blindly obvious to me.
In my opinion, this highlights the reason that there should be a Death table. There’s more information to store about a death than just its date. For example the death_type.
Are there any links to discussions about why they eliminated it?
and
and
Looks like I’m reaching consensus on bringing back the death_type_concept_id for death records 
I think this is the best idea that has been proposed. It could be a death_date_source as surmised or something as simple as
death_date_trust BIT NOT NULL DEFAULT 0
where 1 would flag that the death date is verified.
There is no reason to make life too complicated.
EDIT: Belay the BIT idea… that would introduce the same problem as a death flag.
Friends:
Death (the precise one), cause of death (the Condition leading to it) and where we got that information from (Type Concept) we have solved. No need to reinvent. In the same realm we could reinvent the BIRTH table, the GENDER table and the ETHNICITY table. Nulls are indeed the same logical thing as “magic dates”, just the natural way databases handle missing information, as @Chris_Knoll pointed out. Bottom line: We are good!
The only addition is a new use case where folks have information about death, but not the precise date. This is not that useful for mortality calculations, but it is useful for trial recruitment purposes. Obviously, a death flag is the same as death before a certain date (the date we learned about the patient’s death). Whether we represent this using a flag or an operator (less than or equal to) is not much different. The operator is more obscure, but it actually gives us more information because we could keep the date over refreshes (we remember when we first learned the patient is dead, and hence died before that date). @Chris_Knoll may have a preference.
Please put in a GitHub issue, and we feed it into the CDM WG machinery.
This isn’t solved in v6. There isn’t a type_concept_id for the person.death_date. If the Death doesn’t have an associated Condition, then the record doesn’t have provenance.
1 Like
Does this mean for v5.3.1 we make death_date nullable? I’m not a fan of “magic dates” since there is no consistence of what that date might be and end users would have to know something specific for each OMOP instance about the date used in the death date. Should I create a GitHub issue on this topic as well?
You folks have got to fix this problem. Death is the ultimate outcome. Years ago when I was trying to assess end of life costs, I was amazed at how difficult it was to find out if someone was dead, and more so a date of death. With a maximum effort, looking in 4 sources (e.g., no standard practice), we only got there in, as I recall, data for ~70%. You need a flag and a date. The American College of Surgeon, as I recall, made this a mandatory field in their registries.
It’s difficult to fix a paradox. You rightly state that death is an outcome, but how can you evaluate an outcome that doesn’t have a date? But, I think there’s a solution under the 5.X version of the cdm with the DEATH table: if the death table allows null death date, then you can insert a record into the death table to serve as the status of death, and include any other death-oriented information. This would allow you to exclude people from a study if you can’t determine the exact date of death (simply: people who have exactly 0 death records with death_date is null).
But I think they changed things in the 6.X line of the cdm to attach the death date to a person, and you can’t have a person without a record (to indicate the death occurred, but not when), so I don’t know where you go in the 6.0 version of the CDM. Maybe go back to a death table…it is a very specific context in the patient experience, right? Maybe it deserves a domain.
Nobody will disagree, @dastumpf, we definitely need the death information. Problem is that observational data are a product of the healthcare system, and by definition patients stop being an object of that the moment they die. Capture of death might occur if it happens during a hospital stay, but even that is not sure. Patients dying at home - all bets are off. So, good luck to the ACS trying to enforce anything like that.
@Christian_Reich @MPhilofsky
Coming in very late to this discussion. In CDM v 5.4 it looks like the death_date column still has a NOT NULL constraint. I sympathize with the arguments made for having a data and against having a flag.
I agree that one should be able to put a date in there, the actual date of death or a proxy somehow computed from the source. I would have expected though that there is a way to qualify what kind of death_date I am recording. If I interpret the available columns in the table correctly then there are only qualifiers for the source of the death information and the cause of death.
Would it not make sense to have a death_date_type_concept_id? Something that encodes whether this is an actual death date or an imputed ones (conceivably specifying whether it was a ‘last encounter’, a ‘source record date’, a ‘loading_date’, etc.).
What would be the vocabulary for that, @hannes? And what is the use case? How are you going to use it? Only believe they are dead if there is a certain type?
The objective is to understand whether the death_date in the death table is the actual death date from a reliable source or whether it is an imputed value that is used as a proxy (with the field being mandatory there is no choice); and maybe the type of proxy.
I am open to the argument that the recorded death type could provide a hint on whether the source provides accurate death dates, but I am not sure it is sufficient.
The use cases would include any endeavor that relies on a precise death date to calculate survival time. In the best of cases, one would be able to discern whether the possible error (deviation of the listed death date from the actual death date) is none (actual death date), days, months or even years off.
Ok, but that’s your job at ETL time. If you think you have a robust method to do the imputation, and you checked that against the data where you do have the death date, you use it. If not, don’t put it in. The OMOP CDM assumes it presents facts ready to analyze. Not facts that need double checking before.
Thank you. I think I got it. If I only have a death status / flag without date then I should NOT load this into OMOP CDM (yet).
Correct. Maybe, if you have a narrow sequence of your data and you can see within, say, a month when the flag appeared. You could then do a death date good enough by month. That will probably be ok for most use cases.
Understood. I see value in securing a minimum data quality standard before they are entered into OMOP CDM, especially if the resulting instance participates in larger studies across multiple instances.
I can easily work around the limitation (only populating the death table if a reasonable death date is available) by pulling in the death status from a non-CDM table for any query that needs it.
Hi - I’m new to OMOP, and working on a project. We have a different situation because our data must be de-identified, thus, we are only given a deceased flag/indicator - no date - under certain situations, like a person was > 89 yrs. Having the Death table with a NULLABLE death date is ideal in this situation. How do I socialize this idea?
Our site has a relative high percentage of deceased patients missing actual death date. I agree with @MPhilofsky that identifying last provider-person interaction isn’t easy. I am not confident how accurate the imputed death dates would be. Since OMOP 5.4 still require death date in the DEATH table, how about creating observation records for deceased patients who didn’t have death date and assigning them LOINC code LA10939-9 [Deceased]? It allows researchers to find and exclude all deceased patients if their study population are those who are still alive.
Thanks
Jack