- This topic has 10 replies, 5 voices, and was last updated 16 years, 11 months ago by
.
-
Topic
-
-
Replies
-
-
Carole, I assuming HL/7 messages.
Does your Receiving System send an HL/7 Acknowledgment for each message?
Do you have Clovereaf(R) configured to Await Replies for the Receiving System thread?
Do you have acknowledgment handling implemented (Recover33 procs)?
Have you turned up the Engine ‘Noise’ level (EO Config) so that you can see in the log what Cloverleaf(R) is sending (and maybe what is coming back)?
Give us as much detail as you can.
Jim Kosloskey
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
HL/7 messages Answer: Yes
Does your Receiving System send an HL/7 Acknowledgment for each message?
A: Yes
Do you have Clovereaf(R) configured to Await Replies for the Receiving System thread?
A: Yes
Do you have acknowledgment handling implemented (Recover33 procs)?
A: I am unfamiliar with the Recover33 procs, the thread is set up to await replies.
Have you turned up the Engine ‘Noise’ level (EO Config) so that you can see in the log what Cloverleaf(R) is sending (and maybe what is coming back)?
A: (which is a question) Is this something other than viewing the output from the thread?
Addl Question: If my xlate is calcing the number of OBX segments, could I possible have a variable that is not getting reinitialized, could this confuse Cloverleaf as to where msg begins and ends?
-
Is this a new system/new vendor? We had a problem with similar symptons on a feed from a new vendor. They were placing multiple HL7 messages within a single MLP envelope. Instead of sending x0b HL7message x1c x0dthey were sending
x0b HL7message HL7message HL7message HL7message x1c x0dCloverleaf kept reporting segments out of sequence. You would have to turn up the Engine Output to see the individual bytes coming in.
-
Carole. We had a similar issue with a new vendor sending imaging (text) results. We didn’t receive a full explanation, but it appeared to be an issue between the applications message ‘generator’ and message ‘communicator’. The ‘fix’ was to add a further segment terminator.
We now have no issue, BUT all message end with two ^M (x0d) rather than one!
-
I’ve also seen something like this, only with a little different scenario. I’ve seen the engine clump messages together whenever a vendor inadvertently sends some sort of control character in a free text field within the message. This usually happens due to some sort of user error. Usually when the message with the control character is run through the tester, you can notice it right away because it shows up as an abnormal character within the message, usually something like a small triangle or small box. Hope this helps….
Tom Rioux
-
I have re-sent my result (one order result) several times to my receiving system. When I cycle the message processor on that system and resend my results, it consistently ‘pops out’ of the message at OBX 33. When I have not cycled the processor, the results seem less consistent, it sends an ack mid-message and then tries to process the remainder of the msg as a new msg. Although I can see from my process log that the message is going to the receiving system as a complete message – I am wondering if THAT system is exiting the message due to some kind of control character.
Question: How/where exactly would I be able to see ‘control’ character in my OBX? The line in question has no text.
THX
-
Go to the particular thread, select EO Config and then select enable_all. This will put more information than you ever wanted to know into the log file for that process. Be warned that your log file will increase rapidly until you select disable_all. Part of what you will see in the log is a hex dump of the messages and replies. You will see all characters, including the non-printable ones, that are in the messages as well as the MLP envelope characters.
-
Carole, With the EO up sufficiently to see the PDL display of the message you should be able to detect if there is something other than normal ASCII characters or x0D in the segment in question.
The ASCII side of the display in the engine log will get you to the offending OBX, then if you see a . in the ASCII display before the end of the segment that is an indication of a non displayable hex set. Look at the corresponding location in the hex portion of the message display and see what the value is.
I would then look at the PDL display of the sending system message in the process log and see if the same character exists there (meaning it is coming from the sending system).
If there is an offending character and it is in the inbound message, then you have 2 choices.
1. Get the sending system to send ‘clean’ messages. That is not always easy to do.
2. Use a Tcl proc to try and surgically remove the offending character. I would tend to think of doing this on the Inbound Data Tps.
Be aware if this is coming from the sending system, then it islikely there could be other non-display characters coming from the sending system – since I doubt they are ‘cleaning’ anything. So your Tcl solution should take into account all of the potential offending patterns.Otherwise, you will have this one fixed and suddenly later on another will appear.
By the way, if the sending system still wants the offending characters to exist there is a mechanism defined within the HL/7 standard to accomplish that.
It is unlikely the vendor will know that mechanism exists much less understand it or be willing to deploy it.
Good luck,
Jim Kosloskey
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
From your last post, it almost sounds as if the recieving systems has a limitation on the size of the inbound messages. It may be that the message is too large for the recieving system and you may have to split it into multiple messages. I’ve seen this before and have built interfaces to handle this. Thanks….
Tom Rioux
-
Our Radiology dept in their testing, put TEST**** in their transcription. Our vendor had some old legacy code in their listener for x12 messages. In x12, ST* denotes the END of a message (news to me). Thanks to all for your help and suggestions, I am much wiser now and it helped considerably in proving to vendor that the issue was on their end.
TGIF!
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
