Re: [Gnumed-devel] improved soap notes creator screenshot

[James Busser]

Maybe rename thread "encounters... extend vs new, and how to decide?"

On 23-Nov-08, at 4:37 AM, Karsten Hilbert wrote:

> > In practice, when a patient is selected whose last encounter was not
> > beyond its expiry, the requesting user cannot know whether or not the
> > unexpired encounter ought to be extended since the unexpired  
> > encounter
> > could be something new and unrelated to their last contact with the
> > patient.
>
> Can you give a concrete example from GP land ?

The examples are easy to imagine in any multi-doctor praxis where  
more than one doctor had to access (and make entries in) the record  
during the window of an unexpired encounter. Invariably there will be  
portions of the day when some but not all doctors (clinicians) are  
available to deal with issues.

In GNUmed, a record may have to be accessed twice or more, and for  
reasons unrelated to each other, all prior to expiration of the first  
encounter, when
- an appointment has been booked in advance e.g. for preventive (pap  
smear) or followup care, and
- an encounter for an unscheduled reason (commonly, issues with a  
medication) which may have nothing to do with the scheduled appointment

Additionally, it is not all that unusual for the clinicians in a  
multi-clinician praxis to have partial specialization where patients  
may get care for a special thing from one doctor in the praxis while  
getting the remainder of their care from their usual doctor. A  
variation on this is in low population areas where a specialist may  
visit weekly or monthly and whose entries, when the care was on-site,  
should be made in the same GNUmed EMR. In these situations as well,  
it could make sense to decouple the encounters yet the decision about  
relatedness would be unable to be made until the clinician knew  
enough about the reason(s) for the unexpired encounter, as well as  
the reason(s) for the new activity.

If a specific example is still desired, let us say that during the  
morning, a patient ran out of a medication, and a pharmacy phoned the  
praxis to obtain approval for renewal. Clinician 1 approved the  
renewal, being the patient's usual doctor, or because the usual  
doctor was unavailable that morning, and the patient needed the  
approval without delay. We now have an encounter active...
... One or two hours later, the patient arrives to see clinician 2  
for any number of reasons such as a URTI or a pre-scheduled  
papanicolau smear or any number of reasons which may be unrelated to  
the unexpired encounter. Clinician 2 activates the record and is  
prompted whether or not to begin a new encounter. Unless Clinician 2  
would wait until the patient is in the room and then ask *them* the  
reason GNUmed had been open earlier that day (which would strike the  
patient as extremely odd to be asked) then clinician 2 will be unable  
to determine the relevance of the unexpired encounter to the business  
at hand. Moreover unless clinician 2 happened to be the individual  
who had arranged the current visit, clinician 2 may not even know the  
purpose of the *current* visit, until after consulting the electronic  
record to remind themselves.

Perhaps if the user was provided with the RFE from the as-yet  
unexpired encounter, the user could choose to start a new one as soon  
as they could decide this was appropriate however -- if they were  
unsure -- they might have to postpone until they ask the patient or  
(in absence of the patient) check existing progress notes or the as- 
yet unwritten GNUmed appointment planner.

When an office assistant would activate a patient with an open  
unexpired encounter, is the office assistant given the option or  
requirement to choose to extend the current encounter or to begin a  
new one? I would not want RFEs exposed to every office staff who  
would be accessing a patient record.

When an importer script has added data (e.g. lab results) into the  
backend... do we have different expiration threshold settings on a  
per-encounter basis with the result that some types of encounters are  
not left to the user to decide whether or not to extend?