gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] feature rquest: inbox


From: Jim Busser
Subject: Re: [Gnumed-devel] feature rquest: inbox
Date: Mon, 21 Feb 2011 10:06:45 -0800

On 2011-02-21, at 3:47 AM, Karsten Hilbert wrote:

> On Sun, Feb 06, 2011 at 03:02:18PM +0100, Hilbert, Sebastian wrote:
> 
>> https://bugs.launchpad.net/gnumed/+bug/714076
> 
> Done :-)
> 
> Karsten

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

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

If they do the same thing, they would be redundant. Maybe what distinguishes 
the Inbox is (in part) the function of 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

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).

The Inbox could serve to make an assignee aware that something had been newly 
assigned to them in the waitlist. Acknowledging such an item could be 
equivalent to signing the lab test result… the item would disappear from the 
inbox but would continue to exist in the lab or waitlist area.

Suggest also:
- this may need a column "acknowledged" default true (or null) in the waitlist
- when the user who creates the waitlist item is the same person who needs to 
action the item, then no notification is needed
- does it maybe need an extra column "assignee" which defaults to null or 
current_user
- upon setting the value to some other user, "acknowleged" gets set as FALSE 
and appears in that user's inbox
- perhaps not every user (not every staff) wants everything that is newly 
assigned to them in the inbox, especially when the thing is future-oriented, so 
maybe more sane for such things to only appear there when either
        no date was set
or
        where a date was set, on the date they are due

The above would be a way to co-ordinate knowledge of something which needs to 
be done. 

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

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?
        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"



-- Jim




reply via email to

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