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

[James Busser]

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
> >
> >         fk_lab_section
> >         fk_test_profile
> 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
        fk_test_profile

Where / how would we manage
        fk_lab_section
?