[Top][All Lists]

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

Re: [Gnumed-devel] More lab test result considerations: groupings

From: James Busser
Subject: Re: [Gnumed-devel] More lab test result considerations: groupings
Date: Wed, 13 Feb 2008 08:18:54 -0800

On 11-Feb-08, at 3:12 AM, Karsten Hilbert wrote:

Correct. Liz did some work on (clinical) profiles back in the days.
Even though I understand it will take some time for the display
widgets to catch up with the potential display options, I am
reluctant to "lose" data that [may be] ... impossible to repopulate.
That is the single best argument you could have made for inclusion
of test_panel :-)

Maybe this means we need, in clin.test_type

Will put it on the TODO even for the first iteration.

Just realized we have no table in which to keep the above... we have clin.test_org however that is meant to hold single records per organization whereas each test_org will have multiple lab sections (HAEM, MICRO, CHEM etc), and each section will offer multiple kinds of test_panel

I am thinking we should reserve the word/concept "profile" for internal GNUmed EMR concepts/usage and when working with test_org arbitrary sets of tests to work-in the term "test panel" which we could in fact maintain inside clin.test_type rather than as a foreign key (you hinted at this before). We would put this name of what *would* have been test_panel elsewhere, into the "code" column and then set the coding_system to be a property of the test_org... it could be the value from test_org.internal_name, which would be supplied by MSH 004 "Sending facility" (the reporting laboratory).

We would then have a situation in clin.test_type where some serve as "test panels" having arbitrary "code" supplied by the lab, whereas others would carry a code for a specific observation (result) that comes from the test panel, for example for a particular lab its "LYTE" panel could be associated with four observations (Na, K, Cl, HCO3) each with their own LOINC.

Am I correctly expecting we will need a one-to-many internal link table clin.lnk_ttype2ttype where part of the import process should autocreate any new values into clin.lnk_ttype2ttype where it did not already contain the combination of
        OBR 004 Universal Service ID 200 Test code^Test name
and each of the OBX LOINC codes

That would address what would have been

Where / how would we manage

reply via email to

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