[Gnumed-devel] intended recipient (was schema changes requested)

[J Busser]

During the requesting of anything that may prompt incoming information:

GNUmed identifies patient's "default" doctor (advise new thread if 
concept in dispute)
        intended recipient is set to that doctor
        else intended recipient = logged-in / approving doctor
        --> means some tables will also require "approved_by_clinician" field

when result comes back, if intended recipient is away
        office workflow could identify which doctor would sign the result
        if signer is not intended recipient
                intended recipient will want to see on their return

Sebastian was asking about how I might like to use results. I would 
point out that, when results come in, there is a question the comes 
after signing, and that is  whether more action on the result is 
needed. If I am covering for a groupmate's absence, I will look at 
their patients' results, which will fit into the following:
- normal, or not clinically_important (implies no action needed)
- abnormal AND clinically_important + action needed prior to return 
of intended_recipient
- abnormal AND clinically_important *but* action can wait until 
return of intended_recipient

Actioned results are sure to have some chart entry (request to "call 
patient"). So my question is what about results that are (perhaps) 
clinically_important, but which we don't action because it is 
George's patient and George will be back tomorrow? Now if we think it 
can wait until tomorrow, then George can check all results for which 
he is the intended recipient, those will be a mix of new results and 
those already seen by someone. The fact that someone had marked a 
result as clinically_important will probably stand out. And if the 
intended recipient gets stuck out of town an extra 2 days, whoever is 
filling in needs to look at those results that remain unviewed by 
George AND were marked  clinically_important to determine whether any 
had better not wait for George's return.

Below just some extra thinking around info requests & incoming info

- information entered by us (doctors)
   - recognizable as ours based on our login credentials
      - may "end" without further action
      - may spawn action for staff that never leaves the surgery yet
         could still require to report back to the requesting doc
      - may spawn activity that leaves the surgery
         and/or may require staff to indicate the doc for which they're acting
         and/or incoming response may require closure of loop to original doc

- incoming information
   - may be the "return" response to requests we had made
      if so, may be possible to "match" items
   - no matter which of us requested it, we may not (within our group)
      be the "usual" (primary) gp... it may be one of us covered in another's
      absence. So we may not always need the requestor to sign-off a
      result if the patient's "usual doc" has in the meantime signed it off
   - may *not* be a response to our request i.e. may be pushed to one of us
      from outside, e.g. other doctor/specialist from the hospital
   - info may not arrive "directed" at an identifiable doctor for example the
      patient may ask their result be directed to their clinic, this may be
      possible electronically without a doctor being specified & it would
      fall to the clinic to route it to someone within.


At 5:45 PM +0100 12/1/05, Karsten Hilbert wrote:
>  > Let me re-iterate why I keep on banging on about this: all information
> >  that comes into an EHR must be in two categories: either information
> >  entered by a clinician, or information that has been "signed off" by
> >  a clinician to take responsiblity for it
> I think you have an excellent point here. Let me slightly paraphrase:
>
> ... information either *generated* by the entering clinician
> (or directly on behalf of such by immediate staff) or
> imported and signed off ...
>
> Reason being that anything imported under my account (say,
> lab data) will appear to be entered and thus generated by
> me. Hence we should cater for signing off items that are
> typically entered by staff who legally can't take
> responsibility for it. Which we already do.