[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: Karsten Hilbert
Subject: Re: [Gnumed-devel] More lab test result considerations: groupings
Date: Wed, 25 Aug 2010 23:14:27 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Aug 25, 2010 at 02:11:45PM -0700, lkcl wrote:

> > 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.

Will do for 0.9.

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]