ORU Messages and Continuation Segments

[Mike Shoemaker]

Hi,

I am working on an interface from Cerner Copath to Seimens LCR that involves continuation segments for messages over a certain file size. The handling of the DSC segment is causing me a little pain.

I am hoping someone can clarify the logic behind these continuation scenarios.  From previous interfaces, the continued messages contain a DSC segment with an ID. The message that continues the message contains the same ID in the MSH:14 field. The continuation message is a full blown ORU, meaning it has an MSH followed by a PID followed by a PV1.  The lack of an additional DSC segment indicates the report is complete.  

MSH|||||||ORU^R01||P|2.2|

PID|||

PV1|||

OBR||||

OBX|1

OBX|2

OBX|3

DSC|1

MSH|||||||ORU^R01||P|2.2|||1

PID|||||

PV1||||

OBR||||

OBX|1

OBX|2

This works perfectly for me in the past, but now,  in the Cerner continuation logic, the message being continued has an ADD segment (that is empty by the way) and then a DSC segment with an ID.  I was under the impression The continuation message then contains an MSH:14 with the appropriate ID but they also include an ADD segment which is apparently the last OBX from the previous message, followed by the next sequence OBX segment.  Therefore, I receive this:

MSH|||||||ORU^R01||P|2.2|

PID|||

PV1|||

OBR||||

OBX|1

OBX|2

OBX|3

ADD

DSC|1

MSH|||||||ORU^R01||P|2.2|||1

ADD (rest of OBX3)

OBX|4

OBX|5

So the continuation message in this case, fails in cloverleaf because it doesn’t fit the definition of an ORU message (no PID).

Cerner told me that they are right and everyone else is wrong and all the money in the world can not change this, which is good because we don’t have all the money in the world anyway.

THANKS!

Topic

[Kevin Kinnell]

I have not had to deal with this ever; my first reaction is to define a variant

that doesn’t care about the PID.  I’ll be very interested to see what the

solution(s) is(are).

What REALLY gets me is the vendor’s attitude–if I had a nickel for every

time I’ve had to deal with the “we’re right and all y’all are wrong” vendor

hubris I’d retire.

I feel your pain.

[Mike Shoemaker]

In their defense, they were nice about it and are willing to assist me by showing me how wrong i am 😉

[James Cobane]

Mike,

Technically, if you look at the 2.2 definition for an ORU message the whole PID/NTE/PV1 group is optional, but if a segment within the group is valued, then a PID is required – it sounds like your ORU^R01 definition has the PID as required, irrespective of the optional group.

[Kevin Kinnell]

I’m looking in the HL7 configurator for CL 5.3, and I don’t see an ADD

segment in the base variant.  In the example, the continuation starts with

an ADD which would be an aid to matching the preceding piece (I guess),

but what I don’t get is why the continuation message fails in Cloverleaf

because of a missing PID.   If the ADD is working, then the variant is

allowing it, so it must be requiring the PID, which is not what the base

variant does.  You could just restore the way the base variant treats the

PID/NTE/PV1 group.

If Cerner is right and Seimens is wrong, then Seimens should be fixing

something (and vice versa, if you can convince them.)  But it doesn’t look

to me like the ADD should be required–you could just strip it out.  Unless

Siemens has to have the PID…then maybe you could talk Cerner into

replicating the PID in the ADD instead of the last OBX in the preceding message.

heh.

Any way you look at it, shouldn’t one or the other or both of them be fixing

something?  Or are we moving into an era of “store, reconstruct, and forward

when whole” message passing?  That’s not a can of worms, that’s a can of

fingers pointing at The Interface People.

–kevin (I’m telling you, it’s not my fault!) kinnell

[Robert Kersemakers]

Hi Mike,

I must confess: Cerner is right. This is a legal use of the ADD segment. Have a look at the HL7 2.4 definition chapter 2 (paragraph 2.15.2.3 to be exact).

I once had one big message that was split by the sending application into several messages using the DSC segment. I made my own tcl-proc to join these messages into one big message. I noticed the ADD segment also, but didn’t need to process them.

My thought on this: just get rid of the ADD when joining the separate messages.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Kevin Kinnell]

Robert Kersemakers wrote:

… Have a look at the HL7 2.4 definition …

Yeah, but he’s using 2.2!

Quote:

…just get rid of the ADD when joining the separate messages.

I’d do that in the translate for sure, but I’d resist doing the vendor’s job(s) for them and

writing a proc to join those messages.  If I was putting them together for some

in-house app, okay–you do what you gotta do.  But if your vendor won’t fix a

non-compliance issue it’s time to renegotiate your contract.

_________________

Kevin Kinnell

EDI/Database Analyst

Cloverleaf Analyst

Hattiesburg Clinic

(Don’t get me started!  Too late.)

[Author]

Replies