Re: [Gnumed-devel] basic test types

[Karsten Hilbert]

> How might records in test_type be most easily populated other than by 
> manual creation?

> - importer maps the source of the results to the correct test_org.pk, 
> probably it would always already exist unless the labs were received 
> through a service bureau to which a new lab had subscribed. If there 
> were difficulty verifying which test_org.pk a log alert would need to 
> be generated for a human user.
The German lab importer works exactly like that.

> - assuming the test_org.pk is identified, the test code that 
> accompanies each result must be matched to a code in test_type but 
> when first beginning to use electronic labs and later when any test 
> result is received back for the first time, a row must be created / 
> inserted to contain the "new" code.
That is precisely how our importer operates.

> I do not know if my lab provides 
> as part of each result a tag identifying the coding system (as 
> LOINC). If not, a default coding system that is stored in test_org 
> may be helpful.
Ah, true. Or it may just be left NULL as we do now.

> - test_result rows can then be inserted into the test_result table
Yes. That's how it works.

> while I am on the subject of the table test_type I will point out a 
> concern over basic_unit which, within the same lab organization and 
> for the same LOINC coded test, can change over time --- say from mg/L 
> to g/L
That is precisely the reason why basic_unit exists in the
first place. To define a base line against which to calculate
"exchange rates" for results of the same test coming in with
different units (which are stored per result).

> or from an absolute measurement to a percent
That is harder to handle for computation since one would need
to know "percentage of which" where which in most cases DOES
have a unit.

> However any one lab test_org is unlikely to switch back and forth so 
> that any time it changes units, it is likely to adhere to the changed 
> value for some time.
Sure.

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

> If yes, the value in even maintaining this field basic_unit is less 
> clear, but would it be mainly to help in the creation of new 
> measurements which are generated (and/or input) from within the 
> office for example blood pressure, weight etc so that the units are 
> automatically carried over into test_result?
They would surely be the default where appropriate.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346