[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Redundant (duplicate) results -- was Re: access to review
From: |
James Busser |
Subject: |
[Gnumed-devel] Redundant (duplicate) results -- was Re: access to review audits |
Date: |
Sun, 17 Aug 2008 21:59:19 -0700 |
On 17-Aug-08, at 10:43 AM, Karsten Hilbert wrote:
"test result modified, existing review (abnormal - not significant)
auto-deleted"
This would end up as a standard SOAP row and be displayed
with other parts of the progress notes, NOT as part of any
future review.
Whether or not THAT is wanted/needed is the question at hand...
It is one thing to see and accept occasional "wrong entries" from
human error, but how do we handle frequent duplicate / triplicate
copies of lab tests?
I am not even talking about the hopefully-rare re-importing of a
file. More commonly, at least in Canada, we can receive the same
information multiple times by a lab in two circumstances:
1) two doctors in the same praxis each receive a copy
2) the lab sends incremental "sets" of messages as a consequence of
tests from any one request being "resulted" asynchronously. Some
tests generate an immediate result while others remain "pending"
because these others are less quickly (or less often) performed by
the lab.
The first could intend the requesting ("ordering") clinician, as well
as the clinician who customarily provides the patient's care, to each
get notification in their inbox.
The second is a consequence of the lab "partial results" with
"incremental re-send" illustrated (for simplicity) thus: Every time
that you requested a complete blood count and differential, the lab
would send three sets of messages:
Hb with result
Hct with result
WBC with result
Plt - pending
Differential - pending
and later a second set of messages:
Hb with result (a duplicate result)
Hct with result (a duplicate result)
WBC with result (a duplicate result)
Plt with result
Differential - pending
and later a third set
Hb with result (a triplicate result)
Hct with result (a triplicate result)
WBC with result (a triplicate result)
Plt with result (a duplicate result)
Differential
Neutrophils
Lymphocytes
Eosinophils
Monocytes
Basophils
Comment: <comment>
Special lab tests can be done as seldom as once a week, or one or
twice a month, which means that if a clinician chose a sometimes-
available option to receive *only* the final set of results, they
would see nothing of all of the other tests in the panel until after
everything became available. In the meantime, the understandable
patient impatience about all of the other results could erode our own
patience..
For this reason, I don't know any clinicians who choose this. We all
(mostly?) suffer to get the redundant results, however truly we:
- don't want to have to re-sign them multiple times and we
- don't want to be presented multiple copies of the same test result
when viewing
Options in GNUmed:
1. do not write the redundant copy into the back end
2. write the redundant copy but
auto-tag as a duplicate
devise a trigger to auto-delete it --> into audit table?
3. write the redundant copy but
facilitate user-actioned labelling as duplicate
if a duplicate
- permit "deletion" --> into audit table or
- do not delete, but filter on the view
It may be difficult for importer scripts (especially if external) to
decide whether an incoming result is a duplicate of what already
exists and so the importer may just add a row for what it had no way
of making sure was new vs redundant. In Canada there is no support
yet for any request_id from the clinician at either the overall
request or individual test level. Even though redundancy could be
suspected from the incoming messages carrying a previously-
encountered request_id as assigned by the lab, GNUmed does not
currently auto-generate a GNUmed-side "lab request" from the
messages, and there would also be the possibility of multiple
specimens bearing the same reuest_id and datetime stamp... a patient
might present the lab with three stool specimens for occult blood
that might have been collected on 3 different days but were logged in
together. (Very possibly though the comment might differentiate them
like OB#1, OB#2, OB#3).
This also begs the question of how we would handle a result
modification when the lab sends a correction, if this would appear in
a new row as a result of an import. The original could be manually
(user) corrected and maybe then the correction deprecated? Or the
original deprecated, with the now-corrected previous one serving as
the permanent record?
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), (continued)
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), James Busser, 2008/08/16
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Karsten Hilbert, 2008/08/17
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Rogerio Luz, 2008/08/17
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Karsten Hilbert, 2008/08/17
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Rogerio Luz, 2008/08/17
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Karsten Hilbert, 2008/08/17
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Rogerio Luz, 2008/08/17
- [Gnumed-devel] Redundant (duplicate) results -- was Re: access to review audits,
James Busser <=
- Re: [Gnumed-devel] Redundant (duplicate) results -- was Re: access to review audits, Karsten Hilbert, 2008/08/21
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/12
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/12
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/12
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/12