Re: [Gnumed-devel] Results tracking (was: gnumed ideas 0.1 and post-0.1)

[Karsten Hilbert]

> >Ian, were you thinking that incoming communications like letters, 
> >consultation reports would also go here (i.e. not just the results of
> Yes, all external ("asynchronous") communications, which then need to be 
> followed up.
That makes sense.

> The idea is a single Inbox tab which looks like an E-mail client, showing 
> all path results/written reports/letters etc. (so it *is* an e-mail client,
> but "clinically-aware" so it can match automatically to patient records, and
> display "special" formats like PIT and HL7.)
> The idea is once your Inbox is empty, you *know* nothing has slipped through 
> the cracks.
Well, there's three ways how this can be achieved:

1) in the backend unify tracking data in *one* tracking table
   - there will be more types of data to be tracked than we
     think of initially, hence it seems prudent to link to a
     tracking table instead of trying to make tracked data
     fit into one tracking table
   - or sounds like another application of inheritance much like
     auditing or clin_root_item
   - hard to do across database boundaries (blob/clinical...)

2) unify tracking data from various tables into one view
   - seems slightly more fragile than 1) but can also offer
     somewhat greater versality
   - appears a bit easier across db boundaries

3) unify tracking data in the client
   - no difference to 1) and 2) as far as the user is concerned
   - puts more burden on the programmers by not *presenting*
     unified tracking data to them (they have to unify it
     themselves)
   - hence every new client can get it wrong once again

Either 1) or at least 2) is what we eventually aim for. 3) is
doable even now.

Tracking the "reviewed" status of "results" is only part of
what an Inbox would contain.

> It may be useful to allow secretarial staff etc. to put simple messages into 
> ones inbox
That's another part of the above.

> Whether this should be SOAP or not I'm not sure.
No, not SOAPed. Except for, say, "CAVE: ..." notes to docs
seeing the EMR in the future.

> Also you should be able to "handball"
> messages to other users (locum covering for other doc, etc.)
For such inter-user messaging I believe standard e-mail is
just fine.

> It would also be good for the checking of results to be placed in a 
> clin_root_item table, so it appears in the SOAP notes narrative.
I am not sure I comprehend ?

I think there should be a *patient* inbox inside GnuMed which
works like this:

Doctor is about to leave on a weekend vacation. Some (as yet
unknown) locum is going to cover. Doctor thinks Mr Smith might
turn up over the weekend due to having phoned in about a bad
flu on Thursday. Doctor knows that Mr Smith had a bout of
leucopenia recently. Hence doctor wants to alert (as yet
unknown) locum of this fact so WBC might be considered even if
normally not necessary. Hence doctor sends note to *patient*
inbox: "recently had leucopenia, consider WBC". Now, whoever
opens that patient's EMR sees that note. Later on doctor may
remove that note again.

Another one: lab fetcher gets lab data for Mr Smith. It sends
a note to the *patient* inbox: "unreviewed lab results". It
also sends standard e-mail to doctor to review Mr Smith
results. That way one can be fairly certain that nothing slips
through.

IOW, *untargetted* messages need to be handled inside GnuMed.
Others can be handled with stock email.

That said, a "doctor inbox" inside a GnuMed client can
certainly display an amalgamation of that doctor's clinical
email folder PLUS the messages in the currently active
patient's GnuMed-internal inbox.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346