[Gnumed-devel] Redundant (duplicate) results -- was Re: access to review audits

[James Busser]

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?