- This topic has 16 replies, 3 voices, and was last updated 7 months ago by
.
-
Topic
-
So I’m working with the following structure (modified ORU_RO1 2.5.1):
MSH
PID
[{NTE}]
[{NK1}]
[PV1]
{
[ORC]
OBR
[{NTE}]
[TQ1]
[{
OBX
[{NTE}]
}]
[{
SPM
[{OBX}]
}]
}
The issue I’m having is when I hit the first OBX subgroup. For some reason I cannot get it to copy to the output during testing. The basic translate I have here is:Iterate (Group 1 basis, %g1)
Pathcopy 1(%g1).0(0).ORC > ORC (same basis)
Pathcopy 1(%g1).0(0).OBR > OBR (same basis)
Iterate (Segment 1(%g1).0(0)NTE, %s2)
Pathcopy 1(%g1).0(0).NTE(%s2)
Iterate ( Group 1(%g1).1, %g2 )
Pathcopy 1(%g1).1(%g2).OBX(0)
That OBX copy does not work, and yes there is valid data in the OBX segment. Am I just completely missing something here?
This may be unrelated (then again it may not be), but I am hard copying some data into some OBX segments prior to that, to add a header to the data. Essentially it’s:
Copy =Preformatted Facility name > 1(%g1).1(0).OBX(0).#5(0)
Copy =Preformatted Secondary Name > 1(%g1).1(1).OBX(0).#5(0)
Copy =Address > 1(%g1).1(2).OBX(0).#5(0)
Copy =City, State, Zip > 1(%g1).1(3).OBX(0).#5(0)
And it outputs to the following:
1(0).1(0).OBX(0) : >|1|||| Facility Name<
1(0).2(0).OBX(0) : >|2||||Secondary<
1(0).2(0).OBX(1) : >|3||||Address<
1(0).2(0).OBX(2) : >|4||||Shouldn’t those be outputting to 1(0).2(0) and 2(1), and 2(2) etc, not in the OBX repetition? It looks like it’s trying to put them in the OBX segments following the SPM, not in the 1.1 group of OBX and NTE.
-
Replies
-
-
First, when you do get this working, if you do not manage your own iteration counter for the OB OBX, the incoming OBX data will overwrite your fixed ‘headers’.
One question I have regards the OB message structure – is it the same as the IB structure?
Make sure you have your repetition counts properly placed for the OB structure.
Are there any errors thrown in the Xlate Testing tool?
Did you try running this with the Xlate Debugger (that can help point out issues immensely)?
If you would like to do a desktop sharing session with me, I will help you debug this. My email is in my signature, just email me.
Jim
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
I have this happen with our Cerner feeds — the Cerner segment organization doesn’t always follow the groupings that Cloverleaf variants default to.
I end up running the input message through the HL7 testing tool to verify which group Cloverleaf is pulling segments into. In particular segments like NTE and OBX which may appear in a number of different groups.
-
So I did a bulkcopy and cloverleaf is definitely not pulling the correct grouping. It looks like I have to make the OBX segment repeating within that group, even though it should be a single OBX with repeating NTEs following. Prior to switching
[{
OBX
[{NTE}]
}]to
[{
[{OBX}]
[{NTE}]
}]The bulkcopy would show the grouping as the following:
1(0).2(0).OBX(0)
1(0).2(0).OBX(1)
1(0).2(0).OBX(2)
etc
which is the wrong group (It should be 1(0).1.(0).OBX(0). Adding the OBX as repeating at least gives me
1(0).1(0).OBX(0)
1(0).1(0).OBX(1)
1(0).1(0).OBX(2)
which is still not what I am expecting, but /more correct/.
-
There is a disparity between what is being sent and how you have the structure.
Without revealing patient information, show us the actual message. It is possible the Source system is sending things out of order? Does the inbound message/event actually contain ORU_R01 and 2.5.1?
Really, email me and I will try to help via desktop share so I can see everything you see and ask to see what is needed to resolve.
I think there is at least a mis-match between message and variant.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
They were in correct order:
MSH PID NTE NK1 PV1 ORC OBR TQ1 OBX OBX OBX OBX OBX OBX OBX OBX OBX OBX OBX OBX OBX OBX SPM
I would have expected all of those OBX’s in 1.1 not in 1.2. However, as explained earlier, when doing the bulkcopy, they were in 1.2, and the SPM I think was in the second iteration of it, so cloverleaf (in my opinion) completely fumbled it.
-
-
Jason,
Just answer one more question for me then I will try on 2209 and see if I observe the same result. I will let you know what I find out.
What is the actual message/event type in the IB MSH and also the version?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
-
I have set up on 2209 as close as I think I can to what you describe and all works fine here. But I want to confirm the IB and OB variants are the same and what is in MSH-9 of the IB message before I can proclaim the issue is not in 2209 by my testing.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
OK the reason I asked about the MSH-9 is to see if a mis-match there might cause the Xlate to use a default 2.3.1 Variant instead of the Variant you specified in your Xlate.
I have attempted to simulate your situation and I see correct mapping in 2209.
Would you consent to email me your Xlate so I can do a more precise test?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
So here is an amusing little side note. I was attempting to show some coworkers the issue at hand, I changed the structure back to the way it was previous (with the OBX required for it’s group), and it worked correctly. Same ‘test’ file, same code (with the bulkcopy). So I’m kind of baffled as to why it was working like it was, and cannot reproduce it.
-
Jason,
Although you cannot cause the issue again, I suspect it was a mismatch between the structure used for the Xlate and the one used for the actual test. I guess it is possible, the variant was changed between Xlate build and Xlate test so that the build saw one structure for parsing/mapping, then the Variant got altered, then testing occurred.
By the way, I once had the above scenario happen to me as a colleague changed the wrong variant while I was building an Xlate. So, when I tested, things did not work correctly. Took some head scratching/banging before we found out what was happening. I think (this was a while ago), I used the HL/7 Testing tool against the message and that pointed me in the right direction.
The bottom line is it is now working as designed. The frustrating thing is not knowing why it did not function so the situation can be avoided in the future.
Thanks for following up.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Out of curiosity, I went back to see what the default structure was:
MSH
[{ SFT }]
{[
PID
[PD1]
[{NTE}]
[{NK1}]
[
PV1
[PV2]
]
]
{
[ORC]
OBR
{[NTE]}
[{
TQ1
[{TQ2}]
}]
[CTD]
[{
OBX
{[NTE]}
}]
[{FT1}]
{[CTI]}
[{
SPM
[{OBX}]
}]
}
}
[DSC]Even if it were using the default (there are no other variants in this site), it still shouldn’t have parsed it like it did, which I find odd.
However, rather than dwell on it, I’ll note it for future issues (I’m sure they’ll come), and move on. Thank you all for your help!
-
- You must be logged in to reply to this topic.
