[Top][All Lists]

[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:56:48 -0700 (PDT)

Elizabeth Dodd wrote:
> On Thu, 26 Aug 2010, lkcl wrote:
> 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

 ok - as long as _only_ Lab A sends you the electronic copy, and you _only_
store the electronic copy from A, you're fine, yes?  if the electronic copy
(via HL7) happens to mention "Lab B's" code in it (in that extra ORC field)
that's great, yes?

 the problem with trying to store the results using the many-to-many table
is that the table doesn't also specify the purpose / reason for which the
multi-linking was needed.

 so if you really really really wanted to store the cross-reference between
Lab A and Lab B results being the same thing, it would be better to add an
extra field to clin.lab_request, pointing to another clin.lab_request (the
copy which the other lab sent), dedicated to that specific purpose.

 if Lab A sends in the results first (mentioning that Lab B actually did the
work), then you create _two_ clin.lab_requests: one for Lab A and
referencing Lab B's clin.lab_request; you place the test results under *A*'s
clin.lab_request and leave B's blank; then if B happens to send in the
duplicate, the code i've written will go "oh look, there's a
clin.lab_request here already ready-made with the correct code, i'll just
add this test result to it".

 this would _correctly_ preserve all the information.

 if you tried to use the many-to-many table to store the exact same
information (two clin.lab_requests, and only one test_result) you can't
distinguish who sent what ... it's just.... no.  don't even think about it


View this message in context:
Sent from the GnuMed - Dev mailing list archive at

reply via email to

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