[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)
                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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]