- This topic has 2 replies, 2 voices, and was last updated 11 years, 4 months ago by
.
-
Topic
-
I have a tcp/ip thread set up to receive result messages (ORU^R01) from our enterprise imaging software. When a message is received from the source system and passes through the translate routine, the message is getting truncated. The MSH segment is mapped fully, but the PID segment maps only PID-1, PID-2, and part of PID-3. Nothing else gets mapped. I log the inbound messages. When I take the logged message and resend it to the inbound thread, the message translates perfectly. When I run the logged message through the testing tool, either for xlt or route, it works perfectly.
I have rebuilt both the inbound thread and the translation from scratch. Both the original and the rebuilt versions have this issue. It sounds like something is missing in the message from the source system that is corrected when CL logs the message. Does this sound familiar? Any thoughts on what is needed to fix it? None of our other numerous translations experience this.
Brian Lubkeman
Technical Analyst III - Integrations
McFarland Clinic, Ames, Iowa
-
Replies
-
-
Brian,
Try any of these steps:
– turn the EO config up so you can see the inbound message in the PDL before Cloverleaf gets it. You will see the message in hex. Check the hex values around where the truncation is occurring and make sure all looks OK.
– Stop your cloverleaf thread then using hcitcptest frtom the command line act like the Cloverleaf thread using the -f switch to save off what is received or redirect stdin to a file.
Then use either hcihd or hcihexdump to view the file of the message just received in hex (on unix I pipe that to less or more so I can search, scroll, etc.).
I am guessing you might find a hex 00 where the truncation is occurring or some other unwanted value. In any case you will be able to validate the data you are reciving is or is not correct.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Jim,
Thank you for your reply. I believe the vendor whose interface is creating the message has inverted their segment and message delimiters. The message contains a newline character at the end of every segment and a carriage return at the end of every message. If I understand the HL7 standard correctly, it should be the other way around. Assuming this gets corrected the message should start working.
Brian Lubkeman
Technical Analyst III - Integrations
McFarland Clinic, Ames, Iowa
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
