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

[Karsten Hilbert]

> 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