# Alive vs Dead **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2016-01-05 06:43 UTC **Views:** 6 **Replies:** 27 **URL:** https://discourse.openehr.org/t/alive-vs-dead/15416 --- ## Post #1 by @heather.leslie Hi everyone, Seeking some advice please. In the context of a data registry or research database to record if a person is alive or dead. Maybe there might be an alternative value of ‘unsure’ or ‘indeterminate’ as well, I guess. I’m wondering if there is any naming convention for this data element – I’ve come across ‘Alive status’ and ‘Vital status’ by googling and researching all the places I can think of. Surprisingly there seems very little available on the topic. SNOMED CT has alive and dead within the ‘General clinical state finding (finding)’ hierarchy, although ‘deceased’ is part of the ‘Finding related to general body function (finding)’ hierarchy. ‘Living status’ was proposed on a forum, but seems a bit weird if they are dead. To add to the confusion, the requirements I am modelling uses the name ‘Status’ (which needs some sort of archetype context) and the values are ‘Alive’ and ‘Deceased’ which cross the SNOMED CT hierarchies! We could just be very pragmatic and label the data element ‘Alive vs Dead?’ Curious problem – I thought there would be more on the internets J. Any wisdom you can share would be most appreciated. And then I guess we need to think of related data elements that might be grouped with this status. Regards Heather **Dr Heather Leslie** MBBS FRACGP FACHI **Consulting Lead**, [Ocean Informatics](http://www.oceaninformatics.com/) **Clinical Programme Lead,** [openEHR Foundation](http://www.openehr.org/) p: +61 418 966 670 skype: heatherleslie twitter: @omowizard --- ## Post #2 by @heather.leslie Just talking it through further with Hugh. The notion of a patient being alive is only possible while they are in the room with you. As soon as they walk out the door they could drop dead. So this adds a further complication. From a pure modelling point of view: · the only reliable status is to record if a patient is dead, maybe alongside date of death, cause of death etc – ie the archetype of death that contains clinically relevant data! · for querying - if the patient is not recorded as being known as dead or deceased, then we assume either the patient is still alive or that their status is unknown. I suspect that the reality is that many current systems do have an alive vs dead status of some sort – would anyone like to confirm or deny? Cheers Heather --- ## Post #3 by @grahamegrieve FHIR - either deceasedBoolean = false: known not to be deceased as of record date deceasedBoolean = true: known to be deceased as of record date, but date not known deceasedDate = [date] : known to have passed away on provided date CDA/RIM: same - but the names are different (and allows for time of death) V2: PID-29 - Patient Death Date and Time PID-30 - Patient Death Indicator = Y/N - so the same as RIM AS 5017 - Date of Death Date - Date of Death Date Accuracy Indicator - Source of Death Notification + stupid wrong rule that date of death <= date of birth + you are not allowed to know that the patient is deceased without knowing the date I'd think that the fairly ubiquitous HL7 model would have pretty good penetration, and would only be so consistent if it was meeting the requirements. Grahame --- ## Post #4 by @Heath_Frankel3 Just talking it through further with Hugh. The notion of a patient being alive is only possible while they are in the room with you. As soon as they walk out the door they could drop dead. So this adds a further complication. From a pure modelling point of view: · the only reliable status is to record if a patient is dead, maybe alongside date of death, cause of death etc – ie the archetype of death that contains clinically relevant data! · for querying - if the patient is not recorded as being known as dead or deceased, then we assume either the patient is still alive or that their status is unknown. I suspect that the reality is that many current systems do have an alive vs dead status of some sort – would anyone like to confirm or deny? Cheers Heather --- ## Post #5 by @heather.leslie Hi Heath, There are many things in the demographic archetypes that we seem to sometimes need in a clinical context. And this seems to be one. I couldn’t find it in any demographic archetype on CKM – do you have one? Regards Heather --- ## Post #6 by @heather.leslie Thanks Grahame, Knew someone would be able to provide a HL7 POV H --- ## Post #7 by @system Hi Heather, I have been using an 'Anonymised person' archetype for this purpose, including a 'Vital status' element which came out of the PARENT work and European Rare Disease registry definitions. This is still in an Incubator. [http://openehr.org/ckm/#showArchetype_1013.1.1745](http://openehr.org/ckm/#showArchetype_1013.1.1745) Ian --- ## Post #8 by @Heath_Frankel3 Hi Heath, There are many things in the demographic archetypes that we seem to sometimes need in a clinical context. And this seems to be one. I couldn’t find it in any demographic archetype on CKM – do you have one? Regards Heather --- ## Post #9 by @Karsten_Hilbert GNUmed models   date\-of\-birth   date\-of\-death and assums alive while the latter is NULL\. Heuristics shows a warning when the difference goes beyond 130 years\. Karsten --- ## Post #10 by @heather.leslie Thanks. What was the actual requirement for Vital status in PARENT? The more I think about it, confirmed by a number of responses already from the list, HL7 work etc, is that the notion of recording someone is alive is a bit of a nonsense really – very akin to the problem of recording exclusions for adverse reaction. We can only record that they are alive while we see them and they could easily drop dead as they walk out the door of the consulting room. The only hard data is if they are dead. Otherwise we assume they are alive. Heather --- ## Post #11 by @system Colleagues, I read reactions that indicate that sometimes you seem to model reality from the point of view of the living subject, the Subject of Care. And other times you seem to model statements by an author irrespective of the reality the SoC is in. In the world of EHR’s I (and the method called SIAMM) take the point of view that the EHR is about documenting statements by an author about a subject of care. These statements are subjective and not necessarily represent the real state of the SoC; it is a subjective statement that is real and true for the author only at that point in time. The Date of Birth and Date of Death in the demographics are therefor subjective statements documented by an author at that point it time, A SoC with a DoB and not a DoD is supposed to be alive. You must decide what you are modeling using archetypes. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #12 by @system Hi Heather, I think alive is a state, death is an event\. For oncology research, death is the most important event and we need relevant data\. Once I gathered more than 50 patients records across about 5 hospitals in order to assess survival curve of leukemia treatment\. I marked the date of death of each patients, and the last date that patients were confirmed to be alive\(outpatient or inpatient\) as ceased date of following\. The death archetype seems helpful for such research\. I think researcher would judge patient was alive if there are some records except death\. Shinji KOBAYASHI --- ## Post #13 by @heather.leslie Thanks Heath – death date, source of notification, location, certificate number in that archetype – demographic indeed. Clinicians record that the patient is not breathing, no pulse and conclusion that they are declared dead in the patient’s health record. Plus the cause of death including contributing clinical factors. There is crossover between demographics and clinical. H --- ## Post #14 by @system In the absence of a documented statement, that de SoC is dead and/or a DoD is documented, the SoC is supposed to be not-dead. And this supposition can lead to a documented statement that the SoC is supposed to be alive. "alive equals not-dead" Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #15 by @Heath_Frankel3 Thanks Heath – death date, source of notification, location, certificate number in that archetype – demographic indeed. Clinicians record that the patient is not breathing, no pulse and conclusion that they are declared dead in the patient’s health record. Plus the cause of death including contributing clinical factors. There is crossover between demographics and clinical. H --- ## Post #16 by @system Hi all Remember that the Subject of Care could not be born yet, though I guess that in most practices information about the unborn child is documented in the mother's EHR. In case of procedures or samples in utero, some systems can create a health record for the foetus itself, and as a result of this, can be registred as deceased before "it left the uterus" ( = birth?). This will be valid e.g. if there are twins and one dies before birth, or a child need transfusion before birth. Regards Vebjørn --- ## Post #17 by @Eric_Browne Heather, As usual, I think the requirements and likely constraints on how the data is acquired might largely dictate things\. Patient death status is often recorded in hospital Patient Administration Systems \(PASs\)\. In this context, it is also often propagated to other systems via HL7 V2 ADT messages\. HL7 v2 has a place to record this, and a timestamp for death if relevant, in the patient demographics PID segment\. The status field PID\-30 is Patient Death Indicator and can only take the values ‘Y’ or ’N’\. However, in practice, all bets are off as to how this field is populated\. Some hospitals record additional values in their PAS and so must somehow decide how to transmit these in HL7\. Some systems abuse the HL7 standard by using different values in PID\-30 e\.g\. ‘A’ for “alive"; ‘U’ for “dead", but unconfirmed”, 'D' for "dead"\. Many systems don’t populate the field at all\. Some populate the field only when the patient’s death has been recorded in the PAS\. Some systems have the meaning of ‘Y’ and ’N’ reversed, i\.e\. ‘Y’ denotes alive\. Many PAS outbound HL7 feeds support additional data in non\-standard, user defined Z segments\. It is quite common for the patient’s death status to be transmitted in a dedicated additional patient demographics segment \( other than HL7’s PD1 segment \), thus allowing for various forms of dead to be conveyed without breaching HL7 standards\. In the above cases, the property of alive vs dead is very much in the camp of HL7 person demographics \- i\.e\. a property of the person rather than any particular visit\. However\.\.\. HL7 ADT discharge messages support a discharge disposition field in the patient visit segment using user defined codes\. It is quite common for PAS HL7 A03 messages to contain at least some code in PV1\-36 Discharge Disposition that indicates death in hospital, if it so occurred\. The HL7 v2 code table for this is 0112 and suggested values refer to ‘Expired’ rather than ‘Dead’ with potentially dozens of qualifications surrounding death\. In Australia, discharge disposition is often described as "separation mode" in mandatory reported admitted patient statistics\. The above are mainly for administrative purposes\. Additionally, HL7 v2 messages can contain various clinical diagnostic data, often ICD\-coded, that might have been entered in PASs to denote and/or qualify patient death\. Cancer registries often use a field “Vital Status”, perhaps from historical precedence from US NAACCR/SEER data dictionaries, to indicate living or dead\. As with PAS entries, I’ve also seen the value “unconfirmed” used in this context in Australia, whereas the US SEER Cancer Coding and Staging Manual 2014 has two values: ‘1' denoting “Alive”; ‘4' denoting “Dead”, with the proviso "Assign code 4 for death certificate only cases”\. I’d caution against labelling a field “alive vs dead” on the grounds that the value can’t meaningfully be boolean \- though perhaps that might, in some circumstances, be a good thing\. “alive" or “dead" could also refer to the status of a registry case, rather than that of a person\. “Is deceased” or “Has died” ? \[ Using both supports future recording of post\-cryogenic or other types of resurrections ;\-\) \] regards, eric Eric Browne eric\.browne@montagesystems\.com\.au ph 0414 925 845 skype: eric\_browne --- ## Post #18 by @system Hi Heather, The context of “Death” recorded as Demographic data is different from the context of “Death” recorded in EHR data. The latter contains a list of other clinical events (such as vital signs) which are used to conclude “death”. The former only needs date/time of death. Back to your original requirement, you may want to check whether there are any other data (clinical events) related to death status or not. If not, I would think it is part of demographic data. Otherwise, it is EHR data. My gut feeling is that it may be part of demographic data, similar as DOB. With the current demographic archetype, we have: DOB DOD (optional) If a person only has DOB, no DOD, then alive. If DOD is populated with a date/time, then dead If DOD is populated as a null flavour, such as “no information”, then “unsure” Regards, Chunlan --- ## Post #19 by @system I think the orthodox openEHR view would be (see Chunlan's and Eric's responses particularly) : - demographic data would normally have a 'deceased status' and 'date of decease' which is the administrative knowledge of the patient's death, i.e. something recorded by provider admin staff - EHR data would include death as an event (as Shinji says) recorded by a doc, and if there is a persistent Composition containing basic patient clinical info (gender, DOB, etc) it would also go in there The HL7 view could be understood as follows: - hL7v2 messages indicate changes of state in things; and I think will be mainly ADT oriented, i.e. correspond to the administrative change to the openEHR demographic data - FHIR's view is a query - meaning depends on what resource it is coming from; it could be administrative or clinical event (Grahame?) - thomas --- ## Post #20 by @system My two cents\. Kafka would have loved this discussion, but he is dead\. I think dead is a state, not an event with a date\. Dying is an event\. Even when you don't know the date of dying, there can be proof a person is dead\. And even when there is no proof of a person being dead, there is law that says that a person can be declared dead, even when there is no proof, even when there is no date of dying known\. This happens sometimes with missing persons, missing in a fire, missing at sea, missing in the wild, etc\. Bert --- ## Post #21 by @grahamegrieve Hi Tom --- ## Post #22 by @system Most of these are 'ontological' discussions, i.e. discussions about all the weird things that could possibly happen in reality. We need to remember that we are not generally trying to model all that complexity, but just the general structures for what needs to be written down at specific points in time by admin and / or clinical staff. Those 'notes' need to be designed generically enough that they will cope with all these variations. Making most of the data items optional is a basic way to do some of that... - thomas --- ## Post #23 by @system I understand Thomas, just some arguments make me smile, like this one: "alive equals not\-dead" I am glad I am just a programmer\. ;\-\) --- ## Post #24 by @system Following your Kafka reference, we can think of 'K' in the Castle, who probably wished he was dead .... --- ## Post #25 by @Beatriz_de_Faria_Le1 Wonderful discussion. I go with Eric - “Is deceased” or “Has died” ? [ Using both supports future recording of post-cryogenic or other types of resurrections ;-) ] Here in Brazil at our national database with 220 M we use the HL7 demographic approach. I agree this ADT death is different from the death event - I think it would be could to have an archetype to describe the death event - but this is something else.. I wish you all a wonderful 2016! Full of discussions!! eHugs.. Beatriz --- ## Post #26 by @system I like that book of him almost most of all books I've ever read. If I was not so busy making a living I would now read it again. ;-) Every page is a new painting in words. But now back to business. --- ## Post #27 by @system I agree also with this, dead is a state, and about the event, f.e. the cause, or other circumstances can be described, if known, in a special for this case, archetype. --- ## Post #28 by @system I agree with Thomas. The EHR is about subjective statements, by an author, at a point in time, in a certain context, about an aspect (*state, event, process, …*) of the Patient system (*person and its environments).* Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- **Canonical:** https://discourse.openehr.org/t/alive-vs-dead/15416 **Original content:** https://discourse.openehr.org/t/alive-vs-dead/15416