· Oct 25, 2022

Extending EnsLib.HL7.Operation.TCPOperation for custom error handling

Hi all.

I have a scenario where I am receiving NACKs and I'd like to adjust the error handing of the operation based on the content of the NACK.

For example, I could receive the following and want to move onto the next message:

MSH| ^~\&|||||20221025083135.489+0100||ACK ^A02^ACK|9271|D|2.5.1
ERR|||207 ^Application internal error ^HL70357^^^^^^Cannot transfer patient, encounter is cancelled.|E

However, I could also receive the following and want to keep retrying:

MSH| ^~\&|||||20221014103828.043+0100||ACK^A03^ACK|1049|D|2.5.1
ERR|||207^Application internal error^HL70357^^^^^^ISPN000427: Timeout after 15 seconds waiting for acks. Id=114232207|E

As both of these are "AE" errors, I don't believe the reply code actions is sufficient for my needs.

I was thinking that I'd need to extend the Operation and overwrite the OnReplyDocument() method, but I'm not exactly sure if this is the correct approach.

Has anyone done something similar before and have an example they would be able to share?

Product version: IRIS 2022.1
Discussion (1)1
Log in or sign up to continue

I ended up extending EnsLib.HL7.Operation.TCPOperation and overwriting the OnGetReplyAction method.

From there, I coped the default methods content but prepended it with a check that does the following:

  • Check pResponse is an object
  • Loop through the HL7 message in hunt of an ERR segment
  • Checks value of ERR:3.9 against a lookup table

If any of the above fail, the response message is passed to the original ReplyCodeAction code logic, otherwise it quits with the result from the Lookup Table.

The use of the Lookup Table then makes adding/amending error actions accessible to the wider team rather than burying it within the ObjectScript, and having the failsafe of reverting to the original ReplyCodeAction logic keeps the operation from receiving an unexpected error and breaking as it has the robustness of the original method.