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

reply via email to

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