[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] state of test results handling
From: |
James Busser |
Subject: |
Re: [Gnumed-devel] state of test results handling |
Date: |
Thu, 03 Apr 2008 21:47:07 -0700 |
On 1-Apr-08, at 1:28 AM, Karsten Hilbert wrote:
- they *may* (in some jurisdictions) need to be signed by the
ordering
physician, even if already signed by someone else
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.
The associated table clin.reviewed_test_results has been designed to
record, for each test, one or multiple rows each of which includes
all of the following:
- acknowledgment that each has been "reviewed" i.e. the "signing"
function
- agreeing or correcting whether results had been correctly
identified by the test_org as technically_abnormal
- interpreting whether each is noteworthy (clinically significant)
As far as signing, even in a multi-clinician practice, there will be
cases where a single signing "row", when the signing was done by the
clinician who ordered of the test, will be enough. In a circumstance
where --- in the absence of the ordering doctor --- results were
signed by a colleague, then at most only two signings may be
required. The second signing would be by the doctor who ordered the
test. This would complete any statutory or jurisdictional
requirement, where this existed, and could (in fact) obsolete a
signing row that had been created by the previous doctor (a copy
would exist in the audit table).
I am still trying to understand the rationale behind maintaining more
than one non-obsolete signing row per test. Presently, health issues
carry an attribute as to whether or not they are clinical significant
and for each item there exists only a *single* active value
reflecting the decision of whichever clinician last defined or
changed it. There is no provision for each of multiple reviewers
deciding and keeping active in the EMR whether the individually (and
differently) believe it to be clinically significant therefore I
don't understand the reasoning behind supporting multiple different
judgments by different clinicians whether a lab test is clinically
significant. I am now wondering how this is framed for the document
archive items. I think clinical relevance should be managed under the
same approach across all three.
Working through some test result use cases:
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. The requirement for the ordering doctor to have
signed the results would have already been satisfied, and would be
verifiable from the audit log. 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.
2. next suppose the ordering and patient's usual doctors (whether or
not they are the same person) have "both" signed and a colleague sees
the patient and, in examining the already-signed results, notices one
or more that warrant editing of their test_abn and clin signif
values. Altering these values could only be done as part of signing,
making evaluable and identifiable any results that are the
responsibility (based on fk_intended_reviewer) of, yet not currently
(re)signed by, the current user
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. I cannot understand why different clinicians should want to
re-examine results through the lens of "personal definitions of
technically_abnormal".
It seems to me that for any test result, the newest signing should
obsolete not only the current user's row but any user's row.
BTW clin.reviewed_test_results needs a foreign key "dem.identity.pk"
defined for fk_reviewer
Re: [Gnumed-devel] state of test results handling,
James Busser <=
- [Gnumed-devel] Clinician call of judgement, Karsten Hilbert, 2008/04/04
- Re: [Gnumed-devel] Clinician call of judgement, James Busser, 2008/04/04
- Re: [Gnumed-devel] Clinician call of judgement, Karsten Hilbert, 2008/04/08
- Re: [Gnumed-devel] Clinician call of judgement, Elizabeth Dodd, 2008/04/08
- Re: [Gnumed-devel] Clinician call of judgement, Karsten Hilbert, 2008/04/08
[Gnumed-devel] another vista at abnormality/relevance flags, Karsten Hilbert, 2008/04/09
Re: [Gnumed-devel] another vista at abnormality/relevance flags, James Busser, 2008/04/09
Re: [Gnumed-devel] another vista at abnormality/relevance flags, Karsten Hilbert, 2008/04/11
Re: [Gnumed-devel] another vista at abnormality/relevance flags, Karsten Hilbert, 2008/04/11
Re: [Gnumed-devel] state of test results handling, Karsten Hilbert, 2008/04/15