- This topic has 18 replies, 5 voices, and was last updated 16 years, 3 months ago by
.
-
Topic
-
-
Replies
-
-
-
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
-
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.
-
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
-
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.
-
-
-
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.
-
-
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 -
-
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.
-
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. -
-
-
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!
-
-
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.
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
