> I was thinking that the importer could identify the ordering (or cc) > doctor + patient combination for each test result If written that way it could.
>, check whether the > inbox for that doctor already has an inbox notification for that > patient that has not been viewed and, if so, does not bother to > create a new inbox record, because the doctor on checking their inbox > can already be aware that there is something to check for that > patient. That is how it should work. Also, you have a fairly good argument here against my idea of being lazy and using standard e-mail as the provider inbox (that is, it may be a bit hard to reliably check whether some notification is already there). > The inbox notification for that doctor / patient combination can have > a flag for whether or not any of the results that have come in are > abnormal. As soon as a result is imported that *is* abnormal, the > flag could be updated. Surely. > Let's say a doctor was out of the office for a day, they come back > they have in their (individual) inbox > > - 80 patients who have test results notification There would be (< 80) notifications in that providers inbox. > (these notify in > fact of 800 tests but there is not a need to put all 800 in the > inbox!) Even if - there would only be 10 entries per *patient inbox*. > and it could be included in the inbox that of those 80 > patients, 50 have abnormal tests and if we supported the ability to > store "critical" abnormal levels if that is what a lab provider can > notify, we could know that 7 are critically abnormal. sure > Optionally the > importer, as it was updating the status flag of whether any of the > tests were abnormal, could increment how many test there are to > review, Getting the count would be done by the inbox, not by the importer. The technique is to query the data, not keep a tally. > however would get out of sync of the doctor reviewed some but not all. Why ? > - when focusing on a single patient, it should be possible to see the > same notifications pooled across doctors (and pooled across > non-doctor office staff to whom tasks may have been delegated) but > filtered on that patient. These items could be subgrouped by the type > of item. yes Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
