[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Redundant (duplicate) results -- was Re: access to review audits
Date: Thu, 21 Aug 2008 22:42:09 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

I think all the points you raise about duplicates are valid.

I would suggest dealing with them when the duplicates turn
up in real life (I know they will) as we will then know
exactly what we need to deal with.


On Sun, Aug 17, 2008 at 09:59:19PM -0700, Jim Busser wrote:
> X-Mailer: Apple Mail (2.753.1)
> Subject: [Gnumed-devel] Redundant (duplicate) results -- was Re: access to
>       review audits
> 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?
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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