Persistent Warning from HL7 Inbound TCP Adapter

113 views
Skip to first unread message

Marc Lang

unread,
May 1, 2012, 4:22:57 PM5/1/12
to InterSystems: Ensemble in Healthcare
I have recently set up a TCP Inbound Adapter to listen to HL7 lab results from a 3rd party system (iSoft Telepath)
 
The messages are coming across OK, although Ensemble reports a warning, and the 3rd party system reports a timeout.
 
 1
 32802
 2012-05-01
21:19:08.572
 Warning
 4888
 
 From_Live_RHSC_Telepath
 EnsLib.HL7.Parser:ParseIOStream()
 Returning unused unexpected 0-char segment '' interpreted as End-of-Message for current message
 2
 32801
 2012-05-01
21:19:08.572
 Warning
 4888
 
 From_Live_RHSC_Telepath
 EnsLib.HL7.Parser
:ParseFramedIOStream()
 Discarding received non-HL7 data(2) 'er'

 

That is the warning I get.
a "Discarding received non-HL7 data(2) 'er'"
followed by a:
Returning unused unexpected 0-char segment '' interpreted as End-of-Message for current message
 
Any ideas why this may be, and how to resolve?
As I say, the messages do come across ok and process, but obviously not great for production.
 
Wireshark shows the 3rd party system is sending the HL7 over multiple frames. I don't know if this is the cause?
 

Ricardo Santos

unread,
May 1, 2012, 4:45:48 PM5/1/12
to ensemble-in...@googlegroups.com

Hi Marc,

I recently came across a similar instance, funnily enough with a Telepath system also.
After much time spent debugging the HL7 parser, I identified this was Ensemble's "Flexible" handling of message framing causing it to assume that a CR followed by an empty "segment" (such as a couple of empty CR lines on a pathology report OBX segment) were causing the adapter to interpret it the empty line as an end of message.

In my case, the message was framed by MLLP, and although Ensemble's adapter did recognise the start block, it did not switch itself to MLLP and continued processing the message as "flexible" framing, thus aborting parsing at the empty result line. I did raise this with WRC but was told this was by design?

Changing the service's framing to MLLP in the production settings corrected it for me. Should work for you if your message happens to be MLLP framed too.  
Long messages will usually be sent across several TCP datagrams, and I don't think this would affect Ensemble at all.

HTH,
Ricardo


--
You received this message because you are subscribed to the Google Groups "InterSystems: Ensemble in Healthcare Community" group.
To post to this group, send email to Ensemble-in...@googlegroups.com
To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Ensemble-in-Healthcare?hl=en

Ted Peck

unread,
May 1, 2012, 4:53:06 PM5/1/12
to ensemble-in...@googlegroups.com, Marc Lang
The 'er' is the standard MLLP end block, the "End" character (Ascii 28) and the "Return" character (Ascii 13).

The fact that the parser is calling them "non-HL7 data" means it thinks the HL7 data is already complete.  It appears to think so because it has gotten an empty segment, i.e. 2  Ascii 13 characters in a row before the Ascii 28 character.

That's my guess. You could also try changing the Framing setting to explicit MLLP instead of Flexible if you haven't already.

Ted

Marc Lang

unread,
May 1, 2012, 4:55:02 PM5/1/12
to InterSystems: Ensemble in Healthcare
Thanks folks.
 
Changing to MLLP - will that need a production restart?

Reply all
Reply to author
Forward
0 new messages