[Gnumed-devel] Challenges in lab test aggregation

[Busser, Jim]

I was looking in the current schema at

        
http://publicdb.gnumed.de/~ncq/gnumed/schema/gnumed_v18/gnumed-schema.html#clin.table.meta-test-type
        
http://publicdb.gnumed.de/~ncq/gnumed/schema/gnumed_v18/gnumed-schema.html#clin.table.test-type

and stopped to consider the situation where an originating laboratory might, 
over time, change the units in which it reports a result.

I am not clear on two situations that we may need to provide for in order to 
avoid later breaking aggregation.

The first would be if a lab X keeps the same method (and the same LOINC) but 
simply decides to change its units as could eventually be possible if the USA 
should go Systeme Internationale.

The problem is that there is presently no way to record this as a property of 
the test originating from lab X, since the only column in

        clin.test_type

that bears on units is the text column

        clin.test_type.conversion_unit

relating not to the units in which the result had been reported but rather the 
unit we think these results need to be *converted to* in order to be comparable 
to OTHER results.

The *actual fact* of the units having changed would live with the results 
themselves, in

        clin.test_result.val_unit

where we could find, relating to a single patient, rows as follows
        range of dates
        same fk_type (this being an F-Key to clin.test_type.pk)
        a *shift* in a range of numeric or alpha values
        range of units
        no actual biological change

Further observations / suggestions:

1) just because a lab has changed its units does not mean that the LOINC has 
changed … the method might have remained the same

2) the column clin.test_type.conversion_unit seems orthogonal to the 
above-described changes in units

3) the column clin.test_type.conversion_unit might usefully reside instead in

        clin.meta_test_type

4) it would appear that

        SELECT DISTINCT (fk_type, val_unit)
        FROM clin.test_result
        ;

would define the extent of factorization needed to express the results for any 
one test type into an in-common unit.

A reference set of conversion factors would be important to cover this scenario 
and to allow the results from a single test type to be  expressed graphically 
even without having aggregated it with other test_types.

In other words, at any point where a change in units was observed within any 
one test_type, a remedy could be to add a row in clin.meta_test_type despite 
that it links only to this test_type, and no other. Whichever would be the unit 
preferred by the praxis could then serve as the 'base' to which the other unit 
(or units) existing for this test_type could be converted in the view or in the 
graph.

Still needed would be a table to hold the conversion factors. For all those 
test_types which shared the same

        clin.meta_test_type.pk

it may suffice to have

        fk_meta_type    unit_from       unit_to multiplier

except maybe multiplier is inadequate (maybe better 'conversion') because for 
temperature

        degrees F       degrees C       (x - 32) * 5 / 9

-- Jim

PS 1. the second case is where the lab changes the method employed in a test, 
which may or may not change its units. It is possible that the units could stay 
the same, but that the normal range could be wider or narrower, or upshifted or 
down shifted. The LOINC might, or might not, change. If it changes, probably it 
should be a new (different) test_type with a new LOINC instead of overwriting 
the old value for LOINC. If the LOINC remains the same, and only the units 
change, then the provisions above should take care of it.

PS 2. This still leaves the question of shifts in the normal ranges, however 
since these (val_normal_min, val_normal_max) will have been stored with the 
test_results themselves, it might be as simple as to run these through the same 
'converter' as the actual result to which they relate.

-- end