And proper HL7 v3 Deceased Indicator Boolean with true / false And the decease date can be added All in the person entity
Works same as Grahame explains for FHIR. In summary If we meet someone in the real world we know he is alive. We are Modelling however and abstract from reality. Alive is a state after birth with some birthdate Alive is assumed state until Decease state is set to true with some date. Vriendelijke groet, Dr. William Goossen Directeur Results 4 Care BV +31654614458 > Op 5 jan. 2016 om 08:30 heeft [email protected] het > volgende geschreven: > > Send openEHR-clinical mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openEHR-clinical digest..." > > > Today's Topics: > > 1. Alive vs Dead (Heather Leslie) > 2. RE: Alive vs Dead (Heather Leslie) > 3. Re: Alive vs Dead (Grahame Grieve) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Jan 2016 06:43:30 +0000 > From: Heather Leslie <[email protected]> > To: For openEHR clinical discussions > <[email protected]> > Subject: Alive vs Dead > Message-ID: > > <me1pr01mb04833eff7d30bd0e6cac63c6fd...@me1pr01mb0483.ausprd01.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > 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 :). > > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160105/254504cb/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Tue, 5 Jan 2016 07:19:19 +0000 > From: Heather Leslie <[email protected]> > To: For openEHR clinical discussions > <[email protected]> > Subject: RE: Alive vs Dead > Message-ID: > > <me1pr01mb0483256ef0efb2eac888b144fd...@me1pr01mb0483.ausprd01.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > 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:[email protected]] On > Behalf Of Heather Leslie > Sent: Tuesday, 5 January 2016 5:44 PM > To: For openEHR clinical discussions <[email protected]> > 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 :). > > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160105/d786de30/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Tue, 5 Jan 2016 18:29:18 +1100 > From: Grahame Grieve <[email protected]> > To: For openEHR clinical discussions > <[email protected]> > Subject: Re: Alive vs Dead > Message-ID: > <cag47hgzgucdf2iva50x+kf485tsg04fkfw9u4y71qxop63k...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > > > > > > > On Tue, Jan 5, 2016 at 6:19 PM, Heather Leslie < > [email protected]> 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: >> [email protected]] *On Behalf Of *Heather Leslie >> *Sent:* Tuesday, 5 January 2016 5:44 PM >> *To:* For openEHR clinical discussions <[email protected] >> *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 <http://www.oceaninformatics.com/> >> >> *Clinical Programme Lead, *openEHR Foundation <http://www.openehr.org/> >> p: +61 418 966 670 skype: heatherleslie twitter: @omowizard >> >> >> >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > -- > ----- > http://www.healthintersections.com.au / [email protected] > / +61 411 867 065 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160105/15174d3f/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openEHR-clinical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > ------------------------------ > > End of openEHR-clinical Digest, Vol 45, Issue 1 > *********************************************** _______________________________________________ openEHR-clinical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
