Failed messages in thread – not failing at recipient system

[Gregg Price]

I’m building a new DFT interface, and all messages are showing up as Failed in the outbound thread.  The admin of the recipient system says they’re not rejecting them.

Here’s the message in the thread log:

(resend_ob_msg/epic_sub_charge_out_s) : Received Invalid response

Message to Error Database

Reply is:

MSH|^~&|EnsembleHL7|ISC|SBR|RMH|201112121404||ACK^P03|20111212091330|P|2.3

MSA|CA|20111212091330

Message is:

MSH|^~&|SBR|RMH|EPIC|CCHS|20111212091330||DFT^P03|20111212091330|P|2.3

PID||1126644|79000088|79000088|DOE^JOHN||19121212|M||||||||||1750

PV1|||||||||||||||||||1750

FT1|1|||201112091349||CH|58000339^^BILL|*CT BRAIN wo CONTRAST||1|||||||||||||||58000339^^BILL

Another thread to the same system uses the same settings in the thread, the ACK looks very similar, and the thread does not show the messages as Failed.

Here’s a good ACK from a similar thread:

MSH|^~&|EnsembleHL7|ISC|CENTRICITY|RMH|201112120914||ACK^R01|RMS|P|2.3

MSA|CA|RMS

Any suggestions on where to look next or why a good ACK is generating a failed message?

Thanks

Gregg Price

Rice Memorial Hospital

Topic

[Keith McLeod]

Check the inbound tab to see if ‘Outbound Only’ is checked.

[James Cobane]

Gregg,

You need to look at the reply proc to see what it’s looking at to determine what is an ‘Invalid Response’.  Because the reply proc is interpreting the response as an ‘Invalid Response’, it is writing the outbound message to the error database (after sending it).  So, the message is getting delivered to the downstream, but because the reply proc doesn’t like the reply message, it’s writing the outbound transaction to the error database.

I suspect that the reply proc is NOT expecting an ‘ACK^P03’, but does expect an ‘ACK^R01’ (or other, i.e. ACK^O01, ACK^A01, etc).  Just a theory.

Jim Cobane

Henry Ford Health

[Charlie Bursell]

My suggestion would be to use the standard reply procs provided by us.

[Gregg Price]

Keith McLeod wrote:

Check the inbound tab to see if ‘Outbound Only’ is checked.

It is NOT checked, and that’s similar to my other OB threads.

[Gregg Price]

Charlie Bursell wrote:

My suggestion would be to use the standard reply procs provided by us.

The TPS Inbound reply is check_ack, and that’s not one we’ve written.  It must be one of yours.  Does the error indicate otherwise?

[Gregg Price]

Charlie Bursell wrote:

My suggestion would be to use the standard reply procs provided by us.

i found where the check_ack proc resides.  It’s under recover_33.tcl.  It looks like it’s expecting an AA and not a CA for a good ACK.

I’ll see if the sending system can respond with an AA.  That will probably fix the issue.

[Charlie Bursell]

resend_ob_msg/epic_sub_charge_out_s) : Received Invalid response

Would indicate otherwise

If I were you I would *ALWAYS* check Outbound Only.  It make it more ergonomic in that the process does not waste time checking for IB messages.

I don’t think this is your problem however becsuse if the messages were coming in after the await reply flag was cleared it would be data and not a reply.

I can only guess there is a configuration problem somewhere.  Hard to tell without looking.

I note you are receiving CA (Conditional ACK).  The check_ack proc will handle that.  I know cause I wrote it 🙂

[Charlie Bursell]

What version of Cloverleaf?  If 5.6 or greater you should not be using the recover_33 procs.  There should be recover.tcl in the root with cl_check_ack

However, unless someone is messing with my proc the check_ack proc in recover_33.tcl will handle CA/CR/CE

[Gregg Price]

BTW, my other ‘good’ interface was also failing the messages.  I was so busy checking the actual OB messages I never looked closely at its status_report.  Because the people on the other side said the messages looked good, I didn’t verify it on my end.

Live and learn.

[Gregg Price]

Charlie Bursell wrote:

What version of Cloverleaf?

[Author]

Replies