gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] More lab test result considerations: groupings


From: lkcl
Subject: Re: [Gnumed-devel] More lab test result considerations: groupings
Date: Wed, 25 Aug 2010 14:46:40 -0700 (PDT)



Elizabeth Dodd wrote:
> 
> On Thu, 26 Aug 2010, lkcl wrote:
>> from a technical perspective, one of the implications are that two
>> different labs are responsible for the exact same test result.  two labs
>> provide the exact same test result.  two labs, each of which has their
>> own
>> independent numbering system, provided the exact same test result.
> 
> 
> Yes!
> Lab A collects sample and sends to Lab B for analysis.
> Lab B sends result to Gnumed and to Lab A
> Lab A now renumbers the test result and sends it to Gnumed
> 
> usually I only get Lab A result electronically but often get the paper
> from 
> both.
> 
> 
> 
> -- 
> You've been leading a dog's life.  Stay off the furniture.
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel
> 
> 

so - tell me, what would you like to happen, in the following scenario:

* lab A sends test result to lab B 
* lab B performs work and sends results to lab A
* lab B also sends same results to gnumed.
* lab A also sends same results to gnumed.
* lab A then decides to do an update (on its own, without lab B)
* lab A sends updated results.

my head is spinning just from the nightmare task of keeping track of, and
identifying the data as being cross-referenced and being from the same lab.

under HL7, the problem is solved very very simply: in the case where the two
labs send you the exact same-looking results, the fact that the OBX fields
are identical is utterly, utterly irrelevant.  however, it just so happens
that one of the ORC fields is the "upstream lab", and if push came to shove,
this field could be used to de-duplicate electronic records.

but... actually trying to get gnumed to represent this scenario, when one or
either of the two labs could send updates, and you end up "competing"
between the two labs for the "correctness"??  absolute nightmare that's gone
wrong _way_ before the data gets to gnumed, and at least with duplicated
data - an accurate record of what came from which lab - you stand a chance
of spotting the situation and slapping both labs' wrists.

if you try to do data-merging in gnumed, you run into some nasty
decision-making about whose updates (from A or B) "take precedence".

classic garbage-in, garbage-out scenario.

l.
-- 
View this message in context: 
http://old.nabble.com/More-lab-test-result-considerations%3A-groupings-tp15399784p29536844.html
Sent from the GnuMed - Dev mailing list archive at Nabble.com.




reply via email to

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