Re: [Gnumed-devel] basic test types

[Karsten Hilbert]

> We were going on the basis that when a test_org's test_type is first 
> imported into the test_type table (<deity> forbid we have to enter 
> all these by hand!)
ACK. German labs also provide a file called ELV -
Elektronisches LeistungsVerzeichnis listing these. But that's
rarely used these days.

> it may as well default its conversion_unit into 
> whatever the lab had provided, because there would be no 
> other/better/reliable way by which to guess or decide what it should 
> be
Absolutely ! So does our importer.

> - that is, unless we build an extra reference table in which to 
> store the desired conversion_unit per combination of (cod, 
> coding_system).
Ah ! Ok, that might make sense - except that for us over here
it would fall down with each new test since labs don't use
coding systems but rather name the tests entirely arbitrary.

> Next, precisely because, as you say,
> >for each and every row in test_type that represents the
> >same clinical test (eg. various types of blood glucose) the
> >conversion_unit should be the *same* !
> 
> then an extra user step may have to be taken to make conversion_unit 
> the same after an import caused them to be different:
Hence I would not - after the initial import - let subsequent
imports touch conversion_unit since no matter what comes in
next it got to be compatible with the conversion_unit that's
already there *somehow*. That *somehow* is what business
logic needs to bring into the equation.

> >> So here a user would decide "for fk_test_org (lab) 7, code 14769-4,
> > > LOINC" I want that expressed in mmol/L.
> 
> above, I did not mean that the actual result being 
> transferred/written/imported into test_result needs to have its value 
> altered, IMO you would never want to distort the original copy of the 
> raw data.
Understood.

> >No, I think the purpose of that field still isn't clear. It is
> >of no concern what unit the lab actually reports results in.
> >It also is of no concern which unit I want to eventually see.
> 
> but is not one of the functions of conversion_unit to assign this choice?
no

> Maybe you are just saying that the point is to provide a mechanism by 
mechanism, I like mechanism :-)

> which to get the results onto the same scale, (e.g.) feet, even 
> though it may be possible to let any user choose later DISPLAY the 
> result in (e.g.) cm WITHOUT having to change the conversion_unit?
Precisely !

Feel free to improve the SQL comment !

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