gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] How gnumed deals with death


From: Jim Busser
Subject: Re: [Gnumed-devel] How gnumed deals with death
Date: Fri, 17 Jul 2009 09:17:10 -0700

On Sun, Jul 12, 2009 at 10:17:05PM -0700, Jim Busser wrote:

There exists, in the database, provision in the "identity" table (in
which is recorded the person's date of birth and a few other
particulars) via the field "deceased" (timestamp with time zone) which
would be reasonable to add to the person demographics editing widget.

Karsten replied

wishlist item of medium complexity

Before I add the above to launchpad...

On 14-Jul-09, at 12:33 AM, Karsten Hilbert wrote:

On Mon, Jul 13, 2009 at 04:28:25PM -0300, Rogerio Luz Coelho wrote:


ok but how do I go about to make gnumed understand this person is deceased

is it enough just to click on a Past Hx : "caused death"?


Unfortunately not but that's a good idea. Can we file that

as a wishlist item ?


When a user would add or update a health issue attempting to set "caused death" to TRUE what constraints or checking or interaction would be desirable?

Should there be only one cause of death? I think so. All problems that were active at the time of death could have been contributors, but maybe only one should be the primary. However might any users have already set more than one issue per patient as a cause of death? Is this fixable?

We cannot now implement a constraint that cause of death can only be set if "deceased" is not NULL by virtue of users possibly in production having already set a cause of death. Do we wish simply for the GUI to check the state of the value and, if null, warn the user and maybe offer (on save) to switch to the Demographics plugin.

Add the bits above (including reply text) to launchpad as a wishlist item separate from

add "deceased" to the person demographics editing widget.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]