[Top][All Lists]

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

Re: [Gnumed-devel] basic test types

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] basic test types
Date: Wed, 29 Sep 2004 08:26:22 +0200
User-agent: Mutt/

> If we go back to the example of fasting glucoses where in the
> table test_type have 2 different labs  test_org_pk 6 and 7
> (here I represent the lab's test_org_pk -- as it is called in the
> source table with the name of the foreign key as it exists in the
> test_type table i.e. fk_test_org)
>  fk_test_org/ BASIC_UNIT / CODE    / CODING_SYSTEM / NAME
>    6        /   mg/dL    / 14769-4 / LOINC         / GLUCOSE, FASTING
>    7        /   mg/dL    / 14769-4 / LOINC         / GLUCOSE, FASTING

> Now lab 6 changes to mmol/L, so we either have to over-write 
> basic_unit for this lab or we have to create an extra row for lab 6 
> which is identical except for basic_unit
No, why ? The basic_unit is what WE declare the basic unit
(eg. conversion dimension) of this lab test to be -- not what
the lab thinks. The row doesn't even care what unit the lab
attaches to the actual results flowing in. Those units are
stored with the value in test_result anyways. I improved the
comment to that effect.

> If we need in test_type to hold onto every value that a lab (for the 
> same code) has used for its units, the unique (is it a rule, or a 
> constraint?)
a constraint

> needs to incorporate basic_unit. Also is it possible 
> that a lab may keep the same code despite at a later date it changes 
> coding systems?
Sure. Perhaps not very likely, though. So we'd probably need
the constraint unique(fk_test_org, code, coding_system) right ?

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]