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

[lkcl]

Karsten Hilbert wrote:
> 
>> > Hm, like, clin.lnk_result2lab_req ?
>> 
>> :) yes i didn't realise that table existed - it's exactly what i need.
> 
> Good.
> 
> I wonder why I initially favoured a link table over a
> nullable foreign key.
> 
> Can anyone see a rationale for expecting the case of
> *multiple* lab requests having to be linked to one and the
> same test result ?
> 
> 

not in the context of HL7, that's for sure.

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.

which sounds like a complete nightmare, to me.

the other implication is that the same lab, under different numbering,
provided and is providing and is going to continue to provide, the exact
same test result.  this is impossible to even express in HL7 (because OBXs
are associated exclusively with the ORCs.  there simply _is_ no way to
separate any given OBX from its ORC, period).

even if it were possible, the implications - that a test result has _two_
lab_request codes from the same lab - are again, a complete nightmare.

if ever a lab even remotely tried to do that, i'd recommend finding a
different lab, as it would mean that they'd completely lost control over the
integrity of their data.

soo... yah. it's spelling it out, somewhat, but i'd say no, there's no safe
scenario for having that, and i'd say that a fk_lab_request (nullable) in
test_result was a much safer idea.

l.

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