[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: |
Thu, 14 Feb 2008 02:58:40 +0100 |
> 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.
Unless the hl7 data contains anything making it possible to find out
which OBXs the OBR change relates to no software can automate that.
One can, however, invalidate *all* OBXs connected to the revoked OBR
which, by all means, revoking the root node of child nodes can
sensibly only mean. The OBX-to-OBR relationship would be captured in
the test_result to test_panel (to be created) link. We may indeed
have to create a clin.test_panel table in which to capture OBR instances.
If we make the foreign key nullable we can leave out OBRs where they
aren't used (as in Germany) or at a later time derive them at order
entry time if labs don't (re-)provide them.
> 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.
We cannot unless requests are uniquely identifiable (even
if only temporarily).
> 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.
- internally, yes
- clinically useful, yes
- but not as in "panel"
test_type_unified serves to group
GLUC
GLU
BS (blood sugar)
which all report the same physiological value but are named differently
by different labs or the same lab over time.
Personally I would NOT group
SGLUC (serum glucose)
UGLUC (urine glucose)
via test_type_unified for obvious clinical reasons.
*Such* a grouping would be achieved via test_types_profile -- locally,
user-defined, lab-independant groupings of independant but clinically
related lab tests, say:
liver enzymes
diab screening
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.
Correct. There's three groupings we eventually want:
test_panel
- groups ordered tests and returned results
test_profile
- groups different tests clinically
test_type_unified
- groups the same test received under different names
The first iteration will only support test_panel as OBR vs OBX requires
that. The others are convenience for now.
Karsten
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
- [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/10
- Re: [Gnumed-devel] More lab test result considerations: groupings, Karsten Hilbert, 2008/02/11
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/12
- Re: [Gnumed-devel] More lab test result considerations: groupings,
Karsten Hilbert <=
- 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
- Re: [Gnumed-devel] More lab test result considerations: groupings, Karsten Hilbert, 2008/02/19
- Re: [Gnumed-devel] More lab test result considerations: groupings, James Busser, 2008/02/19