gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Notifying clinicians' inboxes of lab results (and other i


From: James Busser
Subject: [Gnumed-devel] Notifying clinicians' inboxes of lab results (and other items...)
Date: Sun, 17 Feb 2008 11:52:47 -0800

Hi, on the wiki it  so far suggests

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, or is the above simply a view of rows that exist in only one place? 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, 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]

and opening the item would take you to whichever work area best looks after the kind of item.

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.

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

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)




reply via email to

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