[Gnumed-devel] Clinician call of judgement

[Karsten Hilbert]

On Thu, Apr 03, 2008 at 09:47:07PM -0700, James Busser wrote:

>> No problem. Each physician can have their own review.
>
> But I would make the case against preserving *multiple* reviews per test 
> result (even if it is only one per user) and, for each result, would 
> instead obsolete all but the most recent review.

I am open to reconsidering this. I may have fallen prey to
over-engineering this part. My main rationale was to prevent
the following scenario:

Benevolent/knowledgeable user comes along and flags
result as abnormal and significant.

Malevolent/factually impaired (see, politically correct ;-)
user comes along and decides: no good, let's do away with
those flags and thereby reduce work.

This would be preventable by the malevolent user having to
spend considerable amounts of criminal energy to actually
erase previous flags.

However, it now seems to me that a) the previous information
isn't really lost (of course) due to auditing (and could
thus potentially still participate in informing on-screen)
and, b) we could *notify* the previously-signing clinician
when a change was done to the flags ;-)  Social control, eh?

************+
Adrian, Liz, Richard, Horst, Jim, Sebastian ...

What's your vote:

- track one pair of flags abnormal/significant per result or

- track one possible pair of the flags *per user* per result

Now it is still fairly easy to change things either way. We
will still optionally store regardless:

- a comment by the lab
- a comment on the result itself by a clinician
- a comment on the/each review
- the lab's abnormality indicator

*************

> I am now wondering how this is framed 
> for the document archive items.
One review per document per reviewer.

> I think clinical relevance should be 
> managed under the same approach across all three.
At least between documents and results.

> 1. say an in-praxis colleague (of a patient's usual doctor) orders  
> tests, and becomes (by default) the intended reviewer. If this ordering 
> doctor is the first to sign, they could (as part of signing) "refer" 
> responsibility to the usual doctor, who would become the new intended 
> reviewer.
I'd suggest they send a notification to the usual doctor who
then *claims* responsibility. Seems the same but is
technically a lot easier given this requirement:

> Any required action on these results would remain with the 
> ordering doctor, until other arrangements are (in the meantime) made or 
> another doctor in the group (e.g. the usual doctor) intercepted and took 
> action.

> The intended reviewer should have to remain the ordering doctor 
> until they had been able to sign. Therefore instead of users "taking" 
> responsibility for results, it should be the intended reviewer who, if it 
> would be the agreed procedure within a praxis (as part of signing), can 
> redirect the role of "intended reviewer" to the patient's usual doctor.
Well, I would expect users to only "take" responsibility
when they have to, no ?

> Technically_abnormal will most often already be correct as supplied by 
> the test org. The first review by any clinician can confirm what was 
> received, or can compensate for situations where test abnormalities had 
> been unaccompanied by flags. A second review, for example by the ordering 
> clinician, could carry-forward everything that was correct from the first 
> signing as well as fixing any disagreement or failure in what the lab had 
> provided. But we are really here talking about carrying forward into a 
> new state the most-correct picture of technical abnormality. There is no 
> question of merit... we are not aiming to weigh the first clinician's 
> judgement against the second. It is not a question of opinion. Therefore 
> any new reviewed value for technically_abnormal should deprecate the  
> previous.
That about sums it up. There may be differences in hospital
settings where junior and senior doctors may both need/want
a "currently valid" review state but that's likely of no
concern to even a multi-GP practice.

> BTW clin.reviewed_test_results needs a foreign key "dem.identity.pk"  
> defined for fk_reviewer
Sure enough. Or rather to dem.staff(pk). Same for
blobs.reviewed_doc_objs.

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