gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] basic test types


From: J Busser
Subject: Re: [Gnumed-devel] basic test types
Date: Wed, 29 Sep 2004 01:29:59 -0700

At 8:26 AM +0200 9/29/04, Karsten Hilbert wrote:
> 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 ?

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

Ah, so basic_unit is in fact *our* preferred, *local* base by which to express the results.
I now get it, but perhaps clearer to future developer/users in place of "basic_unit" might be
"prefer_units" or "express_as".

When the fetcher/importer compares an incoming data file to the test_type table, if GnuMed cannot find within the table a match on fk_test_org, code, coding system, GnuMed could create a the extra rows in test_type to hold the new values, and could be allowed to populate basic_unit with whatever has been provided by the lab, unless it is felt that (code, coding system, basic_unit) should be unique across multiple test_orgs using the same (code, coding system).

But I still cannot see how basic_unit is useful (well, adequate) for conversion purposes.  Sure it's possible for rows in test_result to be referenced against their test_type foreign key, and a string comparison made between (test_result.val_unit, test_result.basic_unit) but what would we do with a nonidentical outcome? We'd need a linked table by which to apply a conversion... I looked for info at http://www1.bipm.org/en/si/base_units but could not find info on any available conversion database.

Base_units remains useful to (potentially) be copied (or offer to be copied) into test_results for measurements performed within (or manually input within) the office. As it is possible that weight could be measured (or stated by the patient to be) in either kg or pounds, and height can be in inches or cm or m, it is maybe better that the units be offered and not assumed.

Is this thread shaping into enough value to link from the wiki?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]