New post
Question
· Jul 20, 2023

Non-Standard HL7 Interface Assistance Needed

#HL7 #Interoperability #Health Connect #InterSystems IRIS for Health

Hi

We've been asked to develop a HL7 interface, but the end system has very different needs than any we've ever interfaced with before. We need assistance to determine if these needs are things HealthShare can support that we're just not aware of, or whether we'll need to develop some custom code to accomplish this.

This end system wants us to send HL7 messages completely asynchronously, one after the other without waiting for any form of ACK or NAK. My first thought was that we could have an outbound HL7 operation which set the session to deferred, with a separate inbound listener service on a separate port that brought the ACKs and NAKs back in. We could then write a custom process that would link the ACKs/NAKs back to the original deferred session. Is there an out of the box option for that sort of deferred HL7 sending operation?

However, there's an additional complication. The end system supplier isn't sure they can send the ACKs and NAKs back on a separate port. They want to receive all messages asynchronously, but also ideally they'd want to send the ACKs and NAKs back on the same port the original messages were sent out from. We know that, at least in all the synchronous interfaces we've configured before, that HealthShare sends a message, waits for a response and moves onto the next message once it's received a response. If a message comes back when there isn't an active session listening for, that ACK gets purged as "unexpected data in buffer" when the next message is sent.

If a message comes back when there's a different active session listening for a response, it gets processed as if it were in response to the current session (depending on the :I? reply code action config). When we asked them how the ACKs or NAKs should be linked back to the correct original message if it was all asynchronous, they believed the Message Control ID should suffice. Is there an out of the box option for a HL7 sending operation to operate in that way, i.e. where messages are sent out without waiting for a response and responses can come back on that same port at any time? (The end system supplier are going to investigate if they can send ACKs and NAKs on a separate port to support my first idea above, but they're not sure they can accommodate that, so we need to explore both scenarios on our side).

Thirdly, as above, they believe the Message Control ID should be sufficient to match ACKs/NAKs to original messages, but I pointed out that would fail in the event of any message resends. I explained how HealthShare can be configured resend a message multiple times, e.g. in a synchronous interface if there was a timeout, or in either sync or async if there was an AE NAK for example. The end system supplier was perplexed. Their assertion is that the HL7 standard dictates that a Message Control ID should never be repeated. If a message is resent, it should be resent with a unique ID. I explained that to the best of my knowledge, the out of the box HL7 sending operations don't have any facility coded for amending the content of the message in any way. Am I right about that, or is there an out of the box option to support that? (e.g. perhaps appending a _1, _2, etc to the end of the message control ID that increments up on each send?)

Any advice would be much appreciated.

Product version: IRIS 2023.1
$ZV: IRIS for Windows (x86-64) 2023.1 (Build 229U) Fri Apr 14 2023 17:17:41 EDT
Discussion (4)2
Log in or sign up to continue
Jeffrey Drumm · Jul 20, 2023

I've worked with a number of integration solutions over the last few decades and not a single one of them would work with this vendor's perverse interpretation of HL7 communications out-of-the-box.

Health Connect / HealthShare can accommodate pretty much anything if you're willing to dip your toes into ObjectScript and write custom services and operations. But the OOB classes won't handle the vendor's requirements without subclassing/extending.

Acknowledgements

There are certainly variances in the types of acknowledgements received and even cases where acknowledgements are received out-of-band (Sunrise Clinical Manager, I'm looking at you). I've even seen implementations where multiple HL7 messages are sent, streamed in a batch, with envelope characters wrapped around the whole batch rather than the individual messages. In that case no ACK was expected. I wrote a custom service to handle that one.

Fundamentally, Health Connect is a request/response messaging system and violating that design presents some interesting challenges. Receiving the ACKs back asynchronously over the same connection is theoretically possible, but I wouldn't encourage the vendor to work that way ... every single future customer will be problematic for them.

Message Control IDs

I've never seen an engine that increments the message control ID automatically, although it's something that can be coded/customized in multiple solutions. The message control ID is defined by the sending application, not the middleware; setting the MSH:10 in the engine is usually an extraordinary measure.

HL7.org defines it as such:

This field contains a number or other identifier that uniquely identifies the message.

If the same message was re-sent with a different MSH:10 value, it would not be uniquely identified. In my opinion, at least.

1 0
Robert Barbiaux · Jul 21, 2023

Hi,

Using out-of-the-box classes in the EnsLib.HL7 package, you can either completely ignore responses, either process them synchronously. More complex scenarios involving multiple responses (ack/nack) are supported (see Important HL7 Scenarios | Routing HL7 Version 2 Messages in Productions | InterSystems IRIS for Health 2023.1
), but I think they do not match your supplier requirements.

According to the standard, when sending multiple HL7 v2.x messages over MLLP/TCP, the sender (initiating module) must wait for a response before sending the next message. This is described in  "Health Level Seven Implementation Support Guide", Appendix C, section  C.6.4, item 5. : 

It is assumed that an initiating module may connect and perform more than one message transaction before disconnecting, but it may not have more than one outstanding message waiting for a response.  In other words, the initiating task must wait for the response to a given message before sending another message.

This vendor requirement to receive multiple messages before sending responses is thus non-standard. It would require the sender to keep track of sent messages with a pending response, handle asynchronous replies and retry errored messages.

While this is possible by writing custom adapter/operation extending the out-of-the-box classes in EnsLib.HL7 package, it would add a lot of complexity and has IMHO, little added value compared to the usual synchronous implementation.

1 0