[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] feature rquest: inbox

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] feature rquest: inbox
Date: Mon, 21 Feb 2011 20:18:28 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Feb 21, 2011 at 10:06:45AM -0800, Jim Busser wrote:

> What would be the relationship between Inbox and Waitlist items, IOW


        deals with messages

        those typically have a life over time

        they have a *receiver*

Waiting list

        deals with patients waiting to be seen

        those typically have a rather limited life span

        they have a *grouping*

Of course, there's overlap.

Time will tell whether they really should be merged.

>       - what should be the advantage of one over the other?
>       - would there be a purpose to transferability between them?

Yes, TODO (inbox) items may usefully be turned into waiting
list entries, say, when the corresponding patient shows up ...

> If they do the same thing, they would be redundant. Maybe what distinguishes 
> the Inbox is (in part) the function of notification.

To date the inbox does not yet offer notification.

>       Lab results get imported
>       --> evidence of this appears in the inbox
>       … but not all users are notified, only the responsible clinician
>       … but in spite of not *all* users being notified, the other clinicians
>               (when selecting *Patient's* inbox items) can see them

That's right.

> So I am wondering whether in the case of tasks that need to be done, the 
> tasks are actually created somewhere else (like in the waitlist).

Why ?

The current state is that tasks can be created manually from within the inbox.

> The Inbox could serve to make an assignee aware that
> something had been newly assigned to them in the waitlist.

Sure, if a new inbox item is created and assigned to a given
provider that provider will see a new item appear in her
inbox. That will also effect a "Request User Attention"
system event.

> Acknowledging such an item could be equivalent to signing
> the lab test result…

Hm, while this is surely possible it is not implemented
right now. Also, the current implementation of the new-lab
inbox notification does not offer sufficient new-lab detail
to enable clinically relevant inspection from there.

What currently *is* implemented: double-clicking the new-lab
inbox item of any patient activates that patient and shows
the lab grid from which signing can be effected.

Once all lab items are signed that patient's new-lab inbox
item will auto-disappear.

> Of course, there is still value to create and communicate, within the inbox, 
> information that does not require action, to some other user.

That would mean duplicating other types of messaging way
better suited to their purpose. Unless either of Inbox and
Waiting List do *more* than email/IM (something EMR
specific, that is) they are better left out of GNUmed.

> So I suppose some thinking may still be needed where to keep action items…
>       do we keep the name Waitlist on Waitlist, or generalize it to a ToDo 
> list?

No. The Inbox would be better suited to that. But even that:
Not yet.

>       or do we suggest to use Waitlist only as a waitlist
>               and keep action items elsewhere
>               like in the Inbox? But that's not a great "system"

Why not ?

The waiting list *can*, however, be used for TODO items (or
whatever): create a waiting zone "todo" and put patients on
that list.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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