Question
· Sep 16

HL7 Pass-through interface

For historic reasons we've got a mix of ADT feeds coming out of our PAS (TrakCare) to a wide range of downstream systems. In particular, there are some that are direct from TrakCare to the downstream systems, and many more that pass through Ensemble as our integration engine.

This is complicating management of the integrations, and so we'd like everything to go through the integration engine. In other words move from the flow in the top of the diagram to the flow in the bottom of the diagram:

So we want to build a couple of pass-through interfaces in Ensemble that respond identically to the current direct feeds - no transformations, and all ACK behaviour is transparent so that the only change visible to the TrakCare PAS is a change of IP/port for each of the currently direct feeds.

Should be easy, right? An HL7 TCP Service, possibly a routing process that simply passes everything on, and an HL7 TCP Operation that is connected to the downstream...

But what is happening is that the Router Process is generating an ACK and sending it back to the Service before the ACK comes back from the downstream. (I've faked a downstream, manually populated the ACK its sending back so I can definitely identify it. I can see it arriving in Ensemble - but after an ACK is sent to the upstream via the Service.) See the annotated message trace below:

Any pointers to what to be looking at?

I'm aware of Important HL7 Scenarios | Routing HL7 Version 2 Messages in Productions | InterSystems IRIS for Health 2025.1 and the Settings for HL7 Services, linked from there, but not seeing what we might have set wrong...

Thanks, Colin

Product version: Ensemble 2018.1
$ZV: Cache for Windows (x86-64) 2018.1 (Build 184U) Wed Sep 19 2018 09:09:22 EDT
Discussion (5)2
Log in or sign up to continue

To address the issue where ACKs are generated prematurely by the Router Process before receiving ACKs from downstream systems in an HL7 Pass-through interface, the following approaches can be considered:

  1. Application ACK Mode in HL7 Services:

    • Configure the HL7 Service to use "Application ACK mode." This setting ensures that the business service does not send an ACK or NACK to the source application until it receives an ACK or NACK from the target application through the integration engine's operation. The service forwards the received ACK or NACK back to the upstream system, thus avoiding the generation of premature ACKs [1].
  2. DTL Transformation for Custom ACKs:

    • Use a Data Transformation Language (DTL) class to create custom ACK messages based on the original HL7 message. When configuring the response logic, swap the Sending and Receiving facility/application fields in the MSH segment and preserve the original Message Control ID (MSH:10). This guarantees that the ACK matches the original message's ID [2][3].
  3. Reply Code Actions Configuration:

    • In HL7 operations, the handling of ACK responses can be further controlled using Reply Code Actions such as E=D (disable the component on errors) or E=S (suspend the message flow on errors). These configurations can influence how errors or acknowledgments are processed without disrupting the interface [4].
  4. Deferred Response Functionality:

    • Utilize deferred response mechanisms. This functionality allows the interface to send back ACKs as responses to upstream systems only after obtaining suitable ACKs from downstream systems. This ensures synchronization of messages with their corresponding responses [5][6].

If these measures are insufficient, subclassing or creating custom services and operations using ObjectScript might be necessary to meet unmet requirements [6][2].

Sources:

Thanks @Eduard Lebedyuk for replying - we've already got ACK Mode set to Application.

Further investigation has revealed that:

  • an "AA" (successful) ACK is passed back from the downstream to the pass-through interface and from the pass-through to the upstream when the business service (HL7 TCP) is connected directly to the business operation (HL7 TCP). This is (successful message) behaviour we want.
  • an "AE" (unsuccessful) ACK from the downstream causes the business operation in the pass-through to suspend the message under default Reply Code Actions, and no ACK is send back from pass-through to the upstream. We want the AE ACK to be passed back through the pass-through to the upstream. 
  • When a Message Router business process sits between the business service and the business process in the pass-through interface then (with current settings) then an ACK is generated by the Message Router and sent back to the upstream before any ACK (AA or AE) is received back from the downstream.

So our questions:

  1. What Reply Code Actions applied to the business operation in the pass-through will not suspend messages which result in an AE (error) ACK, but pass that ACK back to the upstream? (We are continuing to experiment/read to see if we can do this.)
  2. Is it possible to force an HL7 Message Router to be synchronous and wait for the ACK from the business operation, rather than defaulting to be asynchronous?

A basic pass-through can be achieved by:

  • HL7 TCP Service with Ack Mode set to Application
  • no message router/business process
  • HL7 TCP Operation, with Reply Code Actions set to :?R=C,:?E=C,:~=C,:?A=C,:*=C,:I?=W,:T?=C
  • this basically says that the pass-through interface will treat every message which receives an ACK (of any kind) from the downstream as Completed (C), and so pass the received ACK back to the upstream.