Re: [Gnumed-devel] need assessment from fellow clinicians

[Karsten Hilbert]

> Front desk staff receive a request for an appointment. 
If by eg. phone outside an existing encounter there's several
options:

- full-fledged encounter, may or may not have RFE all by
  itself ("request for appointment") - IMHO overkill
- assigned to most-recent encounter (if there is one)
- new encounter created which is then to *become* the
  encounter for which the appointment is scheduled

The exact handling is up to the application/user. All three
to the best of my knowledge should be afforded by the current
schema.

> Makes sense to have the staff ask what it concerns (RFE) 
> Patient will either 
> - provide a specific answer, or 
> - indicate it's a "private matter", or 
eg. put in "undisclosed" - can be changed by the attending doc

> - indicate "the doctor wanted me to come back in followup" 
Eg. RFE for the actual scheduled encounter might be "followup
for *" where * is to be replaced by the previous encounter's
RFE.

> The RFE presumably now exists, irrespective of whether there exist any
> active episodes,
Once an RFE exists there MUST be a health issue, an episode
and an encounter. The health issue may default to
"xxxDEFAULTxxx", likewise the episode. The encounter will
default to at least "auto-created then and then" with the type
"chart review". Front desk staff may or may not go to the
trouble to fix all that to more meaningful values but there
ARE defaults. One hard-and-fast rule: NO clinical item without
patient, health issue, episode and encounter. Actually, I
expect the health issue to be default in quite a few cases.

> Now that I think about it, the process really begins with a REQUEST for 
> an encounter.
Precisely.

> Presumably, receipt of the request (for example, the 
> phone call or correspondence seeking the service) *is* an encounter.
Yes, but we can decide to attribute it to another encounter
logically belonging together.

> Is the receipt of information concerning a patient (say unsolicited or 
> solicited correspondence) an encounter 'about" a patient? How about a 
> phone call from a family member, or from some other doctor involved in 
> the patient's care? 
It is. Unless I decide that calling the consultant belongs to
Mr.Smith's yesterday encounter.

> Is it agreed an encounter will not always involve a visit?
Yes.

> We may at some point support a "task list" of things that need to be 
> done concerning a patient. Some of these tasks include "needs followup 
> appointment"; "needs tests or referrals"; "I need to review/read up on 
> condition X". have we already established / agreed on the need for a 
> "staging area", by which the desk staff and/or doctors assure that the 
> tasks are covered off? I expect that anything in the scratch pad that 
> warrants action in advance of the next visit would, if not actioned 
> immediately, have to be copied/moved into such a staging area. 
> 
> Is there overlap then between the RFE records and Task list items?
Not really. Or at least I would strive to not make them
overlap where possible. The RFE should strictly be a *Reason*
for *Encounter* voiced in conjunction with an encounter (need
not be at the same time though).

> Are 
> they records in the same table, simply that when originated by the 
> patient or other outside entity they are immediately an encounter (a 
> communication of an issue or a need) whereas when they originate from 
> within the office, they are not considered an encounter until a patient 
> contact occurs e.g. the phone call in which the tasked followup 
> appointment is pursued, or the mailing of a from letter advising a 
> patient that they are due or overdue for a PAP test? 
Yep, no encounter - no RFE. Surely prospective RFEs may be
stored alongside with appointments for re-use when the
appointment is attended. But they aren't true RFEs right away
and should IMO not be stored as such.

I have years ago marvelled at the concept of a generic
request-event framework to be incorporated into GnuMed.
Unfortunately I can't find the posts anymore (they were still
on the old sourceforge list I believe). This is still
lingering in the back of my mind but I haven't put enough
thought into it yet.

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