[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.
Karsten
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
- [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/10
- Re: [Gnumed-devel] More lab test result considerations: groupings,
Karsten Hilbert <=
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/12
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/13
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/13
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/13
- Re: [Gnumed-devel] More lab test result considerations: groupings, Karsten Hilbert, 2008/02/14
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/14
- Re: [Gnumed-devel] More lab test result considerations: groupings, Karsten Hilbert, 2008/02/15
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/17
- Re: [Gnumed-devel] More lab test result considerations: groupings, Dave Cramer, 2008/02/19