Re: Patient (Person) status and deactivation? was Re: [Gnumed-devel] Patient details plug-in

[Karsten Hilbert]

On Sat, Jun 20, 2009 at 02:17:20PM -0700, Jim Busser wrote:

> We already acknowledge some people are staff but not patients, and it is 
> in fact via the EMR menu (or plugins) and not through the Patient menu 
> that a person is made into patient. If we are flexible, the Patient menu 
> can (should) be renamed to Person and, within it, "Merge patients" should 
> be "Merge persons".

Done.

> Menu item "Deactivate record" can apply to people who previously worked 
> as staff (but do not any longer work as staff) in the praxis.

That will be up to praxis policies. Every praxis I have
worked in had different ways of dealing with this,
prepending = to the last name, doing nothing, deleting the
patient ...

> However, for anyone who had been a patient, it can be important that we 
> not disable such ex-patients' records, because the praxis receives  
> questions about such people. It must remain possible to "find" them.  
> Therefore, maybe the menu item to "Deactivate record" should check  
> whether the person-in-focus has been a patient, and this should be part 
> of what the user is aware of, before they would click to confirm to 
> disable this patient.

See screenshot. ("patient" in title and logic error in that
Kirk DID in fact receive care are fixed)

> The related question is the concept of the "status" of a patient.
> - are they a current patient of the praxis? (meaning that, as far as we 
> know, they are still alive, and did not communicate that they will get 
> their care somewhere else?)
> - did they leave the vicinity (for example to go to university) or  
> otherwise in a situation where, even though we may be happy for them to 
> return, the patient is "off to Galactica" and we will therefore not 
> "chase" them, but instead wait some communication from them?
> - was the patient difficult or unreasonable so some agreement was  
> reached that they would not be returning for care (the so-called "fired" 
> patient) so that the staff should not agree to make appointments unless 
> one of the doctors un-fires the patient (maybe such a caveat is an 
> allergic state between the patient and doctor?)
:-)))

We don't currently track that state.

> - is the patient deceased? When a deceased patient is brought into focus 
> it would be a good idea for the client to understand this and to give a 
> sound alert (beep) in addition to making this known in the status line.

We do have a deceased marker but don't use it yet. Your
suggestion is reasonable and good for a wishlist item. This
is also (IMO) the only one of the above states worth
tracking - as it marks the difference between "potential
patient" and "NOT potentially a patient"  ;-)

> When a patient has moved-on, do we have forwarding information, not only 
> where the patient may have moved, but also to which doctor(s) the patient 
> has instructed us where (to which new doctor) the patient may wish any 
> new medical information redirected?

We don't but when we get around to implementing the
"social/care network" (another tab under demographics) we
will.

We can, however, already document another address to which
the patient has moved.

> Maybe for such patients we disable the EMR portion, instead of disabling 
> the person themself? In other words, a status that prevents the creation 
> of new clinical entries unless the status of the patient is suitably 
> altered / updated?

"Eventually" is a suitable term, perhaps :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

confirm-person-deletion.png
Description: PNG image