Re: [Gnumed-devel] Challenges in lab test aggregation

[Karsten Hilbert]

On Fri, Aug 30, 2013 at 11:15:07PM +0000, Jim Busser wrote:

> 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

I fail to see how this is a problem.

> 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

That's right.

> 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

Correct.

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

Correct.

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

Doing so would not allow for defining a conversion unit for
a single, unaggregated run of test types.

I agree, however, that a clin.meta_test_type.conversion_unit
ALSO makes sense.

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

That seems right.

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

For such things UCUM (et alii) exist.

> 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

What is the use thereof ?

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

GNUmed allows any of those scenarios. It is up to the user.

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

Exactly.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346