[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 22:35:02 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Aug 25, 2010 at 09:52:39AM -0700, lkcl wrote:

> >> ... or, a *separate* double-fk table is created which preserves the
> >> hierarchy (pk, fk_lab_request, fk_test_result).  or, clin.test_result has
> >> a
> >> fk_lab_request added to it.  both of these would be sufficient to
> >> preserve
> >> the OBR-OBX hierarchy which at present is served by creating new
> >> encounters.
> > 
> > Hm, like, clin.lnk_result2lab_req ?
> :) yes i didn't realise that table existed - it's exactly what i need.


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 ?

> a merge procedure will also still be needed (for when two patients turn out
> to be same person and one import went to one of them and an "update" import
> went to the other) but i will deal with that later.

Sure, but that's quite a corner case.

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]