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

[James Busser]

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.

        Hb
        Hbg
        Hemog

        LFTs
        LENZ

        LYTE
        LYTE4
        LYTE6
        ELYTE


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
> > "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 mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel