Persistent Warning from HL7 Inbound TCP Adapter

[Marc Lang]

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]

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]

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]

Thanks folks.

 

Changing to MLLP - will that need a production restart?