> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
