gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Measurements (was: New developer searching for a task


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Measurements (was: New developer searching for a task)
Date: Fri, 20 Dec 2002 23:35:02 +0100
User-agent: Mutt/1.3.22.1i

> - there should be no difference whether a value is checked in a lab or
>   directly at a clinical encounter
This is the idea, yes.

> - there may be devices (measurement equipment/biosensors) or methods
>   that are not specific to some lab, so it might make sense to have
>   the information "HB measured with equipment X" (but probably your
Well,
 "measured by" (id_lab)
plus
 "measured at" clinical_transaction.timestamp
plus
 "labelled as" (sample_id)
*should* be sufficient to backtrack. For in-house measurements
we may need additional tables to store more information. I am
in contact with yet another guy who is writing a lab system
for his father's lab (wxPython + PostgreSQL :-))  with whom I
hope to set up a collaboration on this part of GnuMed.

> - I do not know about the "ELV", but something like 'range_male' seems
>   suspucious to me, since a lot of parameters are (at least!)
>   age-dependent.  
ELV is the acronym for Elektronisches Leistungsverzeichnis. It
is a text format standard used in data exchange between labs
and GP practices here in Germany. It is a way of telling the
practice what tests the lab offers and what they consider
physiologically normal values in some roughly defined groups
(such as male/female). But the table lab_specific_test is
clearly sub-optimal in some aspects.

> - about the 'abnormal_flag': When the IFG is checked in Leipzig, a
>   SDS-value is returned, which might be stored in the 'abnormal_flag',
Shudder, no :-)

>   but of course you have to store that the value of the abnormal_flag
>   actually _is_ an SDS-value
IF you store the SDS in abnormal_flag you may just as well
decide to KNOW what abnormal_flag semantically means for
specific tests. I don't think that's a good idea.

> - I would perhaps allow an n:m relation between tests and clinical
>   episodes
Hm, yes, but that's handled at the level of
"clinical_transaction" with lab_result linking to
clinical_transactions.

> - My general intention would be to leave the decision what value is
>   normal and what not to the doctor, based on the avaliable information
>   on the patient (age, diagnosis, smoker etc) and published norms.
Changed to
 lab_abnormal_tag

Added
 doc_abnormal_flag
 doc_comment

>   I see that this is strongly against the intention of Labs, who
>   probably claim to be the only ones who know how to judge the things
>   they measured (and don't publish how they come to that judgement).
a) I don't care what their intention is.
b) They ARE the only ones able to judge whether a particular
value falls outside the range of what is to be expected
statistically for a healthy person of a particular age and gender
FOR A GIVEN METHOD of measuring.

> - Imagine a doctor changes Labs, and a value of a patient is marked
>   abnormal, when the very same value two weeks ago was judged
>   'normal'. This _might_ be because the first lab measured with a 
>   different method (which for example has a larger error, so the
>   slightly abnormal measurement was still marked normal) but
>   it also might be because the first Lab just used a different
>   norm.
Exactly. That's why I am tracking lab_id in lab_result and
also why lab_specific_test links into lab_test. Lest I am
mistaken this should allow re-identification of samples,
methods and labs.

>   centile, and the third gives his own coding scheme?) ... so, while
>   the judgement by the Lab is static, the judgement by availiable
>   norms is dynamic data calculated from the norms and the value and
>   should not be stored
Hm. Sort of true, indeed. But even if the once applied norm
isn't available anymore it can be helpful to have available the
ancient judgement by that first doctor back in the days. We
can _still_ apply our current norms to whatever values we
have. But it is usually good to know what the doc though back
then (the patient may long have died long since).

> - Why is the value of a measurement a Character, not a float/double?
Simple. Because the LDT (off of which I originally modelled the
tables) allows that. And you _will_ see results like ">10^5"
(note the ">"). Medicine isn't a clear-cut science.

>   (and why is the "unit"-_reference_ a "character"?)
Denormalization (speedup of the most common case: read access)
plus referential integrity (the rare case: input of new data).

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



reply via email to

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