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

[lkcl]

Karsten Hilbert wrote:
> 
>> i have catered for this in business/GMHL7.py by creating one patient
>> "encounter" per OBR,
> 
> What if there is more than one OBR per patient ? (Is that possible ?)
> 

precisely. frequently.

about 80% of the test HL7 message i have been using contain multiple OBRs
per message.


Karsten Hilbert wrote:
> 
> Does it create several encounters during one import ? That I would
> not agree with.
> 

then it will be necessary to destroy the hierarchical inter-relationship
between the multiple OBRs and their associated OBXs, and consequently it
will become impossible to correctly retrieve and update OBX data when an
"update" message is received.

... or, a *separate* double-fk table is created which preserves the
hierarchy (pk, fk_lab_request, fk_test_result).  or, clin.test_result has a
fk_lab_request added to it.  both of these would be sufficient to preserve
the OBR-OBX hierarchy which at present is served by creating new encounters.



Karsten Hilbert wrote:
> 
>> the only thing is: at any time where messages (updates) are received
>> which
>> do NOT match up with prior ones (missing OBRs), the hierarchy WILL be
>> destroyed.  so, jim, karsten, sebastien, anyone: have you actually seen
>> any
>> HL7 data where HL7 updates do NOT contain the exact same OBR-OBX
>> hierarchy? 
>> it's important to know.
> 
> Saying "yes" will not prove anything. Only if some spec says "this is
> illegal" should we reject this...
> 

given the nature of the OBR-OBX hierarchy, i would be incredibly surprised
if a lab was daft enough to send an HL7 message purely with OBX data,
because OBX data just.... doesn't contain order codes *at all*.  let me take
a look through mirthcorp's XML spec files...

ok, there's too many occurrences of "OBX" to check them all, let's cut them
down by description including the word "observation":

$ grep -il observation */message* | xargs grep OBX
21/messageORF.xml:                    <segment minOccurs="0">OBX</segment>
21/messageORUR01.xml:                    <segment
minOccurs="0">OBX</segment>
22/messageORUR01.xml:                    <segment
minOccurs="0">OBX</segment>
231/messageORFR04.xml:                    <segment
minOccurs="0">OBX</segment>
231/messageORUR01.xml:                    <segment
minOccurs="0">OBX</segment>
23/messageORFR04.xml:                    <segment
minOccurs="0">OBX</segment>
23/messageORUR01.xml:                    <segment
minOccurs="0">OBX</segment>
24/messageORFR04.xml:                    <segment
minOccurs="0">OBX</segment>
24/messageORUR01.xml:                    <segment
minOccurs="0">OBX</segment>
24/messageOULR21.xml:                <segment minOccurs="0"
maxOccurs="unbounded">OBX</segment>
24/messageOULR21.xml:                <segment minOccurs="0">OBX</segment>
25/messageORFR04.xml:                    <segment
minOccurs="0">OBX</segment>
25/messageORUR30.xml:            <segment>OBX</segment>
25/messageORUR31.xml:            <segment>OBX</segment>
25/messageORUR32.xml:            <segment>OBX</segment>
25/messageOULR21.xml:                <segment minOccurs="0">OBX</segment>
25/messageOULR22.xml:            <segment minOccurs="0"
maxOccurs="unbounded">OBX</segment>
25/messageOULR22.xml:                    <segment>OBX</segment>
25/messageOULR23.xml:            <segment minOccurs="0"
maxOccurs="unbounded">OBX</segment>
25/messageOULR23.xml:                        <segment>OBX</segment>
25/messageOULR24.xml:                <segment minOccurs="0"
maxOccurs="unbounded">OBX</segment>
25/messageOULR24.xml:                <segment>OBX</segment>

ok, revision 2.4 and 2.5 is where it seems to get complicated: revisions
2.1, 2.2, 2.3 and 2.31 all have OBR->OBX hierarchy, no problem.

2.4 you start to see MessageFormat="OULR24":
    <description>Unsolicited Order Oriented Observation
Message</description>

in this, the OBR-OBX hierarchy is ... ahh wait:
           <segment minOccurs="0">ORC</segment>

that means that there can only be one ORC per OBR.... the OBRs _are_ a
group... having difficulty interpreting mirth's XML files, i  _think_ even
in this case we're still in the clear, because the <group> </group> thing is
around the OBR-OBX.

so, without going through absolutely absolutely painstakingly through every
single one of these revisions of different message types, i believe it's
safe to say that the OBR-OBX hierarchy is the "norm", i.e. you simply cannot
get, for the purposes of observational reports, an OBX without an associated
OBR.

l.

-- 
View this message in context: 
http://old.nabble.com/More-lab-test-result-considerations%3A-groupings-tp15399784p29396486.html
Sent from the GnuMed - Dev mailing list archive at Nabble.com.