[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patient (Person) status and deactivation? was Re: [Gnumed-devel] Pat
From: |
Karsten Hilbert |
Subject: |
Re: Patient (Person) status and deactivation? was Re: [Gnumed-devel] Patient details plug-in |
Date: |
Sun, 21 Jun 2009 00:18:00 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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