gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Notifying clinicians' inboxes of lab results (and oth


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Notifying clinicians' inboxes of lab results (and other items...)
Date: Tue, 19 Feb 2008 16:15:25 +0100

>       dem.v_provider_inbox to be modified to include rows from  
> clin.test_result which are not in clin.reviewed_test_results thereby  
> auto-generating a notification as long as there are unreviewed results
> 
> Does the above mean that rows of data are being copied,
No.

> or is the  
> above simply a view of rows that exist in only one place?
Yes. In fact, it is (will be, just like unreviewed docs are now)
a view on the *existance* of rows, not on the content of the rows
themselves.

> I continue  
> to think about his question of notification and what I wondered was  
> whether the inbox notification should bother to show the user all of  
> the detail of what is new, or whether it should instead only notify  
> that new results exist,
The latter.

> perhaps extended to the date range like
> 
>       Unsigned lab results [62: Feb 12, 2008 - Feb 14, 2008]
>       Unsigned documents [17: Feb 9, 2008 - Feb 14, 2008]
Yes, later or if someone comes up with a patch for the view.

> and opening the item would take you to whichever work area best looks  
> after the kind of item.
That's how it works. Double-clicking "unsigned documents" takes you
to the document tree sorted by review status, unreviewed on top. The
item also says for which patient docs are available and activates the
patient if necessary.

> Part of what I have not yet gotten my head around is whether it is  
> necessary in every case to activate individual patient records one at  
> a time, or whether (for example in the case of lab results)  
> especially when results can be examined across multiple patients to  
> be normal, whether the user would be able to select a "sign all"  
> function that would save them time compared to waiting for each  
> patient to be updated in between.
That's surely something desirable but needs doing in some later iteration.

> I am also thinking that any patient may have both documents and labs  
> to sign but that this signing may be planned to be handled in two  
> different widgets.
Yes.

> Therefore if jumping back and forth between the  
> kinds of items it may be very helpful for what is there to be pre- 
> filtered to be limited to what pertains to the active patient.
Allowing the inbox to be filtered to the active patient vs all patients
is something I might actually consider for 0.2.9, seems easy enough.

> The other consideration is whether the inbox itself should be  
> filterable to limit what is viewed to the current or active patient  
> (as long as it is apparent to the user that such filtering or  
> limitation is active)
I'd make it a radiobox selection above the item list just like the
sort mode selector in the document tree. From that it's immediately
obvious.

Karsten
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail




reply via email to

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