tpsGenHL7Reply

[Doug Essner]

We are trying to use  _HCI_static_route_ to allow messages to just pass through Cloverleaf.  But it appears that tpsGenHL7Reply is erroring on the messages that are not standard HL7.  Do we have an option other than building a HL7 variant to make this work?

Topic

[Michael Hertel]

A couple of things here:

tpsGenHL7RReply is for:

Generating ACKs for HL7 messages that are received in an inbound thread and should be placed in the inbound tps stack.

You have described this interface as:

1) outbound? and

2) non HL7

So you really don’t want to use this proc.

_HCI_static_route_ is used for routing messages between interfaces only and has nothing to do with ACKing or NAKing either inbound or outbound.

What you need to do is find out what the receiving or sending system needs in the way of acknowledgement messages and configure your inbound/outbound interface accordingly.

It could be that a standard ACK/NAK pdl will do the trick and you won’t need a tclproc at all.

[Doug Essner]

The interface is between McKesson HMM and HCI Carelink and the messages are HL7.  The ERROR messages that we are seeing in the process log are “Invalid message type RGV^O01” and “Invalid message type “RDE^O01”.  I made the assumption that since _HCI_static_route_ doesn’t care about the message type that these errors were generated by the HL7 reply proc.  Do I need the HL7 replay proc?

[Michael Hertel]

Your trxID is probably set up with an HL7 variant that doesn’t have RGV_O01 and RDE_O01 defined.

Check the variant and make sure it has those.

You may need to use a later HL7 version variant.

I suppose you could change the TrxID to FRL 0 instead of HL7.

[Charlie Bursell]

Not familiar with tpsGenReply.   Does it use GRM (ugh!)? If so the error could come from there based on the version/variant used.  We recently uploaded the gen ack (hl7RawAck) and recover_33 procs that we recommend.

Anytime you are using Static Route it is better, especially in older versions to use FRL as type.

FWIW, the newer versions do not as for version/variant when routing HL7. It was always rather dumb since regardless of version or variant the message type is always in the same place.

[Doug Essner]

You’ve comfirmed what we thought was the solution.  We were hoping to get around the building of new message formats.  Thanks for you advice.

[Doug Essner]

Charlie,

Thanks for pointing out the hl7RawAck – that is what we want – minimal message checking.

[Author]

Replies