[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: Tue, 12 Feb 2008 12:45:43 -0800

No in-line comments in this post.

I am realizing a problem GNUmed will suffer in BC, CA (very possibly elsewhere as well) where, until all parts of the request had become finalized, it is possible that one or more tests could get cancelled or recoded or deleted, communicated only in the more-general level OBR without the detail of the specific OBX that we would have already imported being re-provided.

One example would be a value that was originally reported as a random glucose, becoming reclassified as a fasting glucose. While the lab will re-issue an OBR for the original test code "random glucose" indicating that it had been X-revoked, the lab does not re-issue the OBX detail. It only supplies a new OBR and OBX for the seemingly-new fasting glucose.

It leaves me unsure how we would relate the already-imported test_result to the new message that its parent test_code was re- received and is communicating that it (the "child" result) was to be considered invalid or cancelled.

The problem originates IMO from a bad design... the labs could potentially, but are not, reissuing an OBX with an OBX 011 of "X".

However, as the inheritor of this problem, it will take a bit of thinking. :-/

PS just making sure we have the same view that test_type_unified has the purpose of what we, in GNUmed, develop internally as a clinically useful internal scheme. It should be separate from any capture of how local labs group and label their various tests into test_codes or test_panels or test_profiles whatever we use to store this, because these labs all call them different things.




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

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

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

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:

Gnumed-devel mailing list

reply via email to

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