Re: Inbox improvement (was Re: [Gnumed-devel] Notes on patient episode)

[Karsten Hilbert]

On Wed, Jul 01, 2009 at 08:40:54AM -0700, Jim Busser wrote:

>> That's on the TODO: a patient-specific, provider-independent
>> inbox. Not a big deal but requires getting coded :-)
>
> I am still making a clearer picture of best-use between the inbox and  
> waitlist.

Well, let's see. I won't speculate on the most creative
abuse of those tools here. I'll just relate what led me to
their current design -- thus their "intended" purpose.

Provider Inbox:

In certain situations a notice about something must be given
to a specific provider (or group of providers). There's a
million ways to do that: print a letter and post it, email
it, text it, phone it, chat it, page it. While it isn't
reasonable to expect GNUmed to support all of these
notification types soon there surely is a need to solve one
problem: "make sure a provider can learn of things she needs
to know next time she 'uses GNUmed'". Thus the need for a
generic inbox so that the GNUmed system *itself* has a
known-good way to flag something to a provider -- perhaps
even all by itself. How things get there and which things
get in there doesn't matter (read: is up for creativity).

A next step could be to add configurable external
notifications for incoming messages. GNUmed would then call
an external script to signal a provider using external tools
(exactly how we do printing/faxing/emailing of document
parts ;-)

The inbox is like your mailbox where there's a pile of
highly interesting pharmaceutical ads patiently waiting for
your return and their retrieval.

Waiting List:

Assume a typical day at my clinic: Starting at about 7am
people decide that today they are sick. So they flock in
droves to our outpatient care unit. Reception staff got
nothing better to do than register their showing up (and -
if so - a first short hint on why == the seedling of the
RFE) into the waiting list as fast as they can to get people
off their backs. Thus they all end up in just on large
waiting list "zone", namely, "patients who are 'here'
today".

At about 10am I slump myself into an exam room chair for a
nice little 24h shift. I open the waiting list and go "o mi
god, 35 people waiting to be seen" (ne'er fear, there's been
someone else taking care of them between 7 and 10). Then I
go:

        ah, wait, this guy's seen Dr.Striegler for the last 
        year or so,

        oh, and he's coming for perianal vein thrombosis so
        let's make him see Dr. Steger,

        now, what, she's back again with that sore thumb ?? -
        must have been that LCU lesion as previously suspected,
        so let's involve Dr.Hammer, the hand and foot surgeon

        and what have we got here -- a scheduled re-X-ray for
        checking on that fracture, send im straight off to the
        X-Ray dept

        that guy can go see the nurse right away for bloodletting

        phew, much better :-)))

By that time I re-zoned a whole slew of patients. Then I
start working on what's left top to bottom in order of
urgency and waiting time. And suddenly its 9pm and I get the
first call from the pediatric department ...

Now, of course, the waiting list can even be used as a
primitive appointment cheat sheet - just create a zone for
the day you want to schedule someone and put them onto the
list under that zone. Put the time of the appointment into
the comment, et voila ! :-)

I'm sure there's many more creative uses.

> I am thinking of the inbox more for items that require attention by  
> individual clinicians, however it is possible that medical office  
> assistants (can I use the abbreviation MOAs?) might also have items  
> needing individual attention.

"individual" is the key, thus: individual Individuals (using
German-style capitalization to clarify my point)

> As far as communication, are we thinking that communication that  
> pertains to individual patients would be communicated within GNUmed but 
> that communication that is not relatable (and storable) to individual 
> patients would be communicated outside of gnumed.

Not really, if the office manager on Tuesday wanted to let
Dr. X know that there's, say, no more appointments left for
Friday she could leave behind a message in Dr. X's inbox
which Dr. X will see on Wednesday when se returns back to
work. Thus the Inbox is like a Post-It note.

> The waitlist I tend to think of as a list to be attended to by the MOAs 
> with the advantage that "zones" can be used to represent roles and 
> whichever (more than one or alternating) MOAs who would share in that 
> role can take care of that part of the waitlist. Of course, there is no 
> reason that a clinician could not place, in the waitlist, things that 
> they must, themselves, take care of.

Absolutely.

> Coming back to the possibility of a provider-independent inbox... I was 
> wondering about the possibility of a "role" here. Certainly among a group 
> of general internists (who may provide comprehensive care by way of 
> overlap with the GP care for complex patients) there is a function they 
> share when new referrals come in and some prioritization among these 
> referrals needs to be done. Presently, if an import assistant would 
> attach documents to a patient, the document must be assigned to an 
> individual intended reviewer. I am wondering if it could be assignable to 
> "null". The inbox would need an adjustment, to enable a filter on 
> "unowned" items. "Unowned" could help the situation when there exists a 
> new patient who will be coming to the praxis but it may not be determined 
> until the actual visit which doctor will "attend" them.

This would also be solvable by the third inbox-like tool
that's in the dream pipeline: the patient-specific inbox.
That, of course, is shamelessly stolen (but gracefully
enhanced) from Richard's design -- here one would anchor
things that pertain to that one patient but should be seen
and perhaps taken care of by whoever next sees that patient.

BTW, a first glimpse of "care plan(s)" ;-)

> It also helps the 
> situation when new documents would be added while a doctor is away... the 
> import assistants could assign these to reviewer "null" (shall we make 
> this an acceptable default?) and that way any of the other doctors could  
> look at it and if they were satisfied it can wait for the return of the 
> colleague simply assign it to that colleague.

This can be made to work by

a) enhancing the provider inbox with an explicit fk_patient field
b) making *either/or* fk_patient and fk_provider nullable

> We would still need some way, when a doctor is absent (on vacation), for 
> new auto-assigned items that would go into their inbox to be able to be 
> reviewed by another doctor.

Oh, technically that's no problem even now. It is just that
there's no UI-supported way of notifying that covering
doctor yet. The easiest way to achieve this is to allow
users to send provider inbox messages to each other which
should be a todo item.

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