[Top][All Lists]
[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 10:28:51 -0700 |
At 11:23 AM +0200 9/29/04, Karsten Hilbert wrote:
> unless it is felt that (code, coding
system, basic_unit) should be
> unique across multiple test_orgs using the same (code, coding
system).
IMO no
Is it so that for each of 2 labs, which report the same test
result differently but using the same code_system, we can maintain a
key (I think we are talking about a key) by which to calculate a
conversion for each?
Let us say we prefer mmol/dL, and test_org 6 reports in mmol/L,
but test_orgs 7 and 8 report in mg/dL:
TEST_RESULT (recalling that this table
does not directly identify the lab, only its tests)
> FK_TYPE / VAL_NUM /
VAL_UNIT
> 1
/ 6.1 / mmol/L
> 2
/ 108 / mg/dL
> 3
/ 123 / mg/dL
Let us say that, based on the original importer values, we have
in test_type:
TEST_TYPE:
> FK_TEST_ORG/ CONVERSION_UNIT /
CODE / CODING_SYSTEM / NAME
>
6 /
mmol/L / 14769-4 /
LOINC / GLUCOSE,
FASTING
>
7 /
mg/dL / 14769-4 /
LOINC / GLUCOSE,
FASTING
>
8 /
mg/dL / 14769-4 /
LOINC / GLUCOSE,
FASTING
So here a user would decide "for fk_test_org (lab) 7, code
14769-4, LOINC" I want that expressed in mmol/L. And let us do
the same for lab 8. So yes, we can update the two values in conversion
unit and in doing this task, a widget might helpfully offer you all
rows having (code 14769-4, coding_system LOINC) so that all can be
assigned a consistent conversion_unit.
But is it not redundant to have mmol/L in all three rows, and to
have to repeat this manually when a new lab should make its results
available to you but in mg/dL? It might really make sense to normalize
out conversion_unit, moving it into a test_conversion table so that
conversion_unit is needed only once for any one (code, coding system).
It could be in a test_conversion table where the standard name could
reside - but now I am wondering does this overlap test_type_local and
should the conversion be absorbed there?
The only proviso here is whether we can trust that two different
labs will never send us two results where each has the same (code,
coding system) but in fact the records represent two *different*
entities. I don't think this is possible unless the value in
coding_system is neither a standard (like LOINC) nor lab_specific
(like using the value in the FK_TEST_ORG key or the org name) but
instead something lax like "custom" or "local"
which *could conceivably* be input manually by somebody.
- Re: [Gnumed-devel] basic test types, (continued)
Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/25
Re: [Gnumed-devel] basic test types, J Busser, 2004/09/26
- Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/28
- Re: [Gnumed-devel] basic test types, J Busser, 2004/09/28
- Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/29
- Re: [Gnumed-devel] basic test types, J Busser, 2004/09/29
- Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/29
- Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/29
- Re: [Gnumed-devel] basic test types,
J Busser <=
- Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/30
- Re: [Gnumed-devel] basic test types, J Busser, 2004/09/30
- Re: [Gnumed-devel] basic test types, J Busser, 2004/09/30
Re: [Gnumed-devel] basic test types, J Busser, 2004/09/29
Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/29
Re: [Gnumed-devel] test importer, J Busser, 2004/09/29
Re: [Gnumed-devel] test importer, Karsten Hilbert, 2004/09/29
Re: [Gnumed-devel] basic test types, Karsten Hilbert, 2004/09/28
Re: [Gnumed-devel] basic test types, J Busser, 2004/09/29