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.bro...@montagesystems.com.au ph 0414 925 845 skype: eric_browne > On 5 Jan 2016, at 5:49 pm, Heather Leslie > <heather.les...@oceaninformatics.com> wrote: > > 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 > > From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On > Behalf Of Heather Leslie > Sent: Tuesday, 5 January 2016 5:44 PM > To: For openEHR clinical discussions <openehr-clinical@lists.openehr.org> > Subject: Alive vs Dead > > 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 > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
