gnumed-devel
[Top][All Lists]
Advanced

[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


reply via email to

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