Bi-directional TCP/IP Thread Configuration

That sounds very tricky. Normally that’s done with two pairs of threads: order_ib -> order_ob, result_ib -> result_ob. I wouldn’t recommend your pattern. Acknowledgements are going to be going over these interfaces as well, and it seems like they’re going to get mixed up with the messages.

I have to agree with David. HL7 in and of itself is not a bidirectional data type. You’re not routing acknowledgements, you’re routing actual messages. This creates a mess when you’re trying to acknowledge the incoming messages and not acknowledge the acknowledgements. It could probably be done the way you want, but you’re talking a complex setup where you have to investigate each message to see if it’s an acknowledgement or an actual message, and then send (or not send) an ACK back for the non-ACK messages. It makes things incredibly overly complex and difficult to troubleshoot.

You should (as David said) have two sets of interface groups. Orders and results. You send the orders to them, then when they’re done, they send results to wherever it needs to go on a different set of interfaces.

I’m seeing your reply, and quite frankly, that’s not how HL7 works as a whole. You don’t ‘exchange’ orders and results. From a very high level standpoint, the ordering system sends an order. This is a Dr, Tech, someone saying “I have this specimen, and I need someone to look at it and give me their findings”. This is sent to the lab system. This populates their system with basic patient data and specimen data. The specimen is then looked at by someone, and they record their findings. At this point, the lab system then sends a result. What they are saying sounds like a ‘synchronous’ feed where you send a message then wait for them to send a reply. This isn’t how Orders and Results work. This works in other situations (Pumps, certain queries, etc), but not here. You send them a message, then they send you a message.

From a more technical standpoint, HL7 has an “acknowledgement” system, much like TCP/IP but on a higher layer in the OSI model. System A sends System B a message. System B then responds with an ACK (acknowledgement) or NACK (non-acknowledgement) that says they got the message. In most situations (probably 90%+) the sending system will not send another message until they get some form of ACK (whether ACK or NACK). Some systems will send over and over. Some will error (Cloverleaf default), some will shut down. this prevents messages from going out of order.

The rare situations where you get a ‘response’ they’re not results. They’re different types of ACKS where you’re forwarding an immediate response back to the sending system. This is a messy rabbit hole I had to dive in to get some infusion pumps working correctly.

I would say if they were sending an immediate response to your order it could possibly work, however what they’re suggesting isn’t feasible. I just came off of eGate — It would be a hard “no” simply because the engine couldn’t do it.

I’m curious as to who this lab system is, and if they’re new to the game. None of the lab systems I’ve worked with would ever request this (Mako, LabCorp, Arup, there’s a few others).

I think this could be done. There will be challenges as pointed out by others. Since no HL/7 acknowledgments are being used, you might HAVE to use PDL but if you can figure out a way to do it without PDL I think you might be better off.

While not the same, I did something like this way back in an earlier release of CL. If you are on a later release (you do not mention the release), you may find the TCP/IP ‘Encapsulated Options’ in properties might be able to help.

Since each Cloverleaf thread has an inbound and outbound side, a thread can indeed be bi-directional.

Will the system in question be acting as a client or server?

A big challenge will be if they cannot reliably flip their connection from send to receive in synch with the arrival rates. It is possible you may see periodic (or consistent) pending messages but message flow still progressing. That would be a support issue in that someone may erroneously assume the thread is stuck. Consider how you will handle that situation so you can recognize the thread is definitely stuck and not simply obstructed by the other system’s handling of send/receive modes.