Alive vs Dead

Clinical (archive)
1

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

Clinical Programme Lead, openEHR Foundation
p: +61 418 966 670 skype: heatherleslie twitter: @omowizard

2

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

3

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

4

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

5

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

6

Thanks Grahame,

Knew someone would be able to provide a HL7 POV

H

7

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

Ian

8

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

9

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

10

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

11

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

12

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

13

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

14

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

15

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

16

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

17

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 :wink: ]

regards,
eric

Eric Browne
eric.browne@montagesystems.com.au
ph 0414 925 845
skype: eric_browne

18

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

19

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

20

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