[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Using dynamic hints to manage the patient relationship
From: |
Busser, Jim |
Subject: |
[Gnumed-devel] Using dynamic hints to manage the patient relationship |
Date: |
Wed, 28 Jan 2015 13:54:17 +0000 |
This is a follow-on to an exchange on the -bugs list …
On 2015-01-28, at 3:40 AM, Karsten Hilbert <address@hidden> wrote:
> The SQL you provided:
>
> SELECT EXISTS (
> SELECT 1 FROM clin.encounter WHERE
> fk_type = (SELECT pk FROM clin.encounter_type WHERE
> description ~* 'seen.*clinic')
> AND
> pk_patient = ID_ACTIVE_PATIENT
> );
>
> looks fine and seems to say that you want to check whether
> the current patient has got any existing encounters being
> documented as being of type "seen<SOMETHING>clinic".
Yes, this was a precursor step to "testing" the following use case …
In the case where patients have little interest or need to return to the
praxis, whether because they are moving or for other reasons (but also in a
consultant praxis), they can acquire a status "discharged from care".
Currently in GNUmed, we have a couple of ways to capture or indicate the status
of a patient:
- whether or not deceased (indirect, inferred from the state of date deceased)
- the state of allergies
- tags
however I was thinking that an encounter of type "discharge from care" would be
more suitable than a tag, on account of the importance of documenting the
patient's understanding of the situation at such discharge.
It's happened to me a number of times that -- absent a way for the front desk
staff to be easily aware of discharges -- patients have arranged to see me when
they either had no need to see me, or when they really ought to have first gone
back and seen their GP.
So the above script was a test of notification, on activating a patient,
whether the fact of a certain kind of past encounter could signal to the desk
staff that they need to talk to one of the doctors before booking any further
visits for patients who fit this situation. The nice thing is that if they
would be re-referred, and would again need to be seen, this hint could be
suppressed until such time as they were again discharged from care.
Unless there is a problem with non-clinical front desk staff to access such
notifications. The hints reside in schema 'ref', so that should be ok. However
the suppressions reside in 'clin' … does this mean that staff would lack the
necessary database privileges for the middleware (query) to work?
-- Jim
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] Using dynamic hints to manage the patient relationship,
Busser, Jim <=