[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: Karsten Hilbert
Subject: Re: [Gnumed-devel] More lab test result considerations: groupings
Date: Mon, 11 Feb 2008 12:12:18 +0100

> The lab results in BC CA include the HL7 message segment OBR 004  
> "Universal Service ID" of the form "Test code^Test name" for example  
> "LYTE^Electrolytes".

As an aside: note how code isn't a code but rather an arbitrary
abbreviation. I'll consider adding a field "abbreviation" to
clin.test_type to differentiate codes from pseudocodes. The "code" field
can still be pre-set with the abbreviation if so desired.

Wait, actually, that's what "test_type_unified" is for.

> The thing to note is that a *single test code* can represent  
> *multiple results* that will be received.
That's the difference in meaning: test as in "one measurement" vs
test as in "a proceeding upon a material to establish data about it".

> IOW this OBR can be followed, in the same message, by multiple OBX  
> records for example
> I expect the test code would be useful for grouping the display of  
> results within GNUmed, think also "Liver ennzymes" or else  
> "Hematology Panel" which would include  Hemoglobin, White Blood cell  
> count, platelets and there are also related tests like the white  
> blood cell differential and peripheral blood film ("smear") which  
> could be usefully grouped together under the broader classifier which  
> is carried in the OBR 024 "Diagnostic Service Section" (Laboratory  
> Section Codes) for example "HAEM", "CHEM", "MICRO".
Correct. Liz did some work on (clinical) profiles back in the days.

> I gather there is already a recognition of this but maybe just not  
> yet provision in the schema, because under the schema specification  
> for the table clin.test_type_unified there is a disclaimer
>       this is not intended to be used for aggregating semantically  
> different test types into "profiles"
> So we are probably talking here about these same profiles.
We do.

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

One basic design paradigm in GNUmed is: Never lose patient data. No
release will happen in which we *know* about data loss issues.


GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung:

reply via email to

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