Re: [Gnumed-devel] basic test types

[J Busser]

>  Might it therefore be useful for basic_unit to be overwritten /
>  updated at each import by whatever is the most recent unit used by
>  the lab whose results are being imported?
At 3:06 PM +0200 9/28/04, Karsten Hilbert wrote:
> No. Think of a length coming in as centimeters first, as
> feet/inches later. You will want to have something defined as
> the basic unit so comparison logic can go and find out what to
> convert each value to in order do compare things meaningfully.

Hmm...

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

 fk_test_org/ BASIC_UNIT / CODE   / CODING_SYSTEM / NAME
          6        /     mg/dL    / 14769-4 / LOINC / GLUCOSE, FASTING
          6        /    mmol/L    / 14769-4 / LOINC / GLUCOSE, FASTING
          7        /     mg/dL    / 14769-4 / LOINC / GLUCOSE, FASTING

Now we are in violation of unique (fk_test_org, code).

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?) 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?