ORU to MDM

[Mike Wilson]

Can anyone tell me the best way to convert an ORU message into an MDM type message?  Or the easiest way, lol.  the Xlate I am trying keeps giving me tons of errors.  Thanks in advance!

Topic

[Jim Kosloskey]

Mike,

I don’t think there is any basic reason you should not be able to convert an ORU to an MDM. Of course, that depends on the specifics.

What kind of errors are you receiving?

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Wilson]

I got rid of the errors I was receiving but none of the pathcopy functions seem to work beyond the MSH segment.  the PID, PV1, etc.. won’t copy over.  On the Source side I have ORU^R01 2.2 and the destination is  MDM^T02 2.3.  All I get is

0(0).MSH(0)  :  >|^~&|XCELERA|ECHOBROKER|RAPPLICATION|RFACILITY|20080528145630.0000-0400||MDM^T02|1212000990854421|P|2.2< 0(0).EVN(0)  :  >|T02|20080528145630.0000-0400< 0(0).PID(0)  :  >< 0(0).TXA(0)  :  >< 0(0).OBX(0)  :  >< Thanks, Mike

[Jim Kosloskey]

Mike,

Well I don’t use PATHCOPY much but in looking in general at the message definitions for a 2.2 ORU and a 2.3 MDM^T02 I don’t see anything that should prevent building the MDM from the ORU.

Are you sure you have your address pathing correct (both Source and Destination) in your PATHCOPY Actions?

Try COPYing tthe PID-3 field alone and see if you get that COPY’d.

By the way your MSH in the outbound sample you gave has a version of 2.2 not 2.3 – maybe as a result of the PATHCOPY. If I did use PATHCOPY, I don;t think I would use it for the MSH segment.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Tom Rioux]

Mike,

I’ve used Pathcopy a bit and have only seen this type of behavior once.  The sending system sent us specs and we built our translation according to their specs.  However, when they actually started testing, they were sending the UB2 segment out of order.  This caused all of the segments below it to be blank, just as you show on your post.   I’m not sure if this is your issue, but hope it helps.

Thanks….

Tom Rioux

Baylor Health Care System

[Mike Wilson]

I have tried both version 2.2 and 2.3 to test and same result.

I did try to copy just one field and it worked however it gave me an M when there were multiple numbers in the field.

source was 1(0).0(0).PID.00106(0) destination was 0(0).PID.00106(0)

What method would you reccomend to copy the entire segment?

Thanks.

[Jim Kosloskey]

Mike,

Have you run the source message through the HL/7 tester tool using the same variant as the Xlate? Did the message look OK?

What release of Cloverleaf(R)?

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Wilson]

Jim,  I had not done that yet.  I just ran it through and I get a boatload of errors like the one below.

[0:TEST] [mid:0x376bd0] unknown segment ‘

PI’ — ignored.

This file was provided to me by the vendor.  hmm.

Thanks for your help.

[Jim Kosloskey]

Mike,

Did the vendor give you a specification of the message layout?

The 2.2 variant does not have an ORU^R01 natively which means someone needed to build that Message description. Hopefully it was built based on specifications from the vendor.

If it was built based on specifications from the vendor then it appears the vendor has his wires crossed and they need to rectify the situation. Either their structure definition is bogus or their message(s) doesn’t/don’t match their defiinition.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Wilson]

Jim,  Thanks for all of your help.  I emailed the vendor and am waiting for a reply.  I have run several other ORU’s through and they are converting.

[Mike Wilson]

One more problem.  I can get individual fields in the OBX segment to transfer if I define it that way but can not get the entire OBX segment to copy using PATHCOPY Source 1(0).1(0).1(0).OBX and Destination of      0(0).OBX(0) .  My MSH and PID segments went over just fine with the same pathcopy.  Any ideas?  The source is 2.3 ORU^R01 and Destination is 2.3 MDM^T02

[John Hamilton]

What versions of OS and cloverleaf are you using ?

[Levy Lazarre]

Mike,

[0:TEST] [mid:0x376bd0] unknown segment ‘

PI’ — ignored.

I have seen this kind of errors when the sample HL7 messages were saved in DOS format, causing the segments to be terminated by a CR-LF combination instead of just CR.

Can you verify that your sample is good? I strongly suspect that this is where your problem is. Instead of the first three characters of the PID segment (PID), the Xlate is seeing LPI (where L is a linefeed), which is an unknown segment.

My feeling is that your Xlate will work properly if you get a different sample.

[Mike Wilson]

I have cleared up the errors above by using a different test file.  However the OBX segment is still not coming over.  All of the other segments I want have come over just fine.  Weird.  I am on cloverleaf 5.3P_REV3.  I can’t understand why I get nothing at all for the OBX segment as a whole but I can copy over individual fields from it.

[Levy Lazarre]

Mike,

I think that there may be a problem with the path for the OBX segment. Can you post a sample message for us to try?

[Mike Wilson]

here is the file i am testing

[Levy Lazarre]

Mike,

Strange things may happen when you do a PATHCOPY across two different message structures.

When you do the PATHCOPY from MSH to MSH, the message type (ORU^R01) is carried over to the output side in MSH-9. So the output now is looking for the OBX segment in the path 1(0).1(0).1(0).OBX because this is what it is for ORU^R01. However, the real path for the OBX on the output side is 0(0).OBX so the PATHCOPY fails because the OBX segment is not at the expected location.

In order to resolve this issue, you have to redefine the structure of the ORU^R01 message. This is what I did as a workaround:

1. I created a new HL7 2.3 variant named Test.

2. I created an ORU^R01 message with a flat structure similar to the MDM^T02 (so that the paths for the OBX segments will match!)

MSH

[EVN]

PID

PV1

[TXA]

[ORC]

[OBR]

{OBX}

Note that I have included as optional some segments that actually belong to the MDM^T02 message in order to avoid “segment out of order” error messages. Now the input and output paths match, because all the segments are at the 0(0) level. The PATHCOPY 0(0).OBX(%s1) to 0(0). OBX(%s1) now works as expected with your sample!

I am including the sample Xlate. You just need to fill the TXA segment with COPY statements. (Please change .txt to .xlt)

Hope this helps!

[Jim Kosloskey]

Or… maybe don’t PATHCOPY the MSH.

Many (I think all of the required) MSH fields are populated by the Xlate from the variant information. The other fields you can copy individually.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Wilson]

Thanks everybody for your help.  Levy, using your idea of creating a new variant worked great for me.  Except I had to do the reverse of what you had.  It would not work by me creating a new ORU structure.  I had to edit the MDM to match the path.  The only problem / issue I am having though is that the system I am sending the file to rejects it and says that T02 must have OBX segments, even though there are multiple OBX segments in the message.  I will update the post if/when I find the resolution.  Thanks again guys.

[Author]

Replies