Bi-directional TCP/IP Thread Configuration

[Hai Nguyen]

Hello Clovertech,
I am looking to configure an inbound bidirectional TCP/IP thread where both orders and results flow through the same TCP/IP connection, like the attached image.

The intended message flow is:

A remote application connects to the bidirectional thread and sends result messages inbound. Those results are then routed to the Lab system via the result_ob outbound thread.
The order_ib inbound thread forwards orders to the bidirectional thread, which then sends those orders back out to the remote application over the same connection.
Has anyone implemented this pattern before? Please share if you have done one.
Thank you,
– hai

Attachments:

You must be logged in to view attached files.

Topic

[David Barr]

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.

[Hai Nguyen]

The vendor for analyzer insists their instrument can do only this pattern over TCP/IP. They initiate the connection, then exchange order/result messages thru the same connection.

[Jason Russell]

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.

[Jason Russell]

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).

[Hai Nguyen]

Hi Jason,

It’s an instrument interface, ImmuLINK, not lab. Here are more details with more complex, the ACK and NAK are handle by developing a Low-level Protocol with a PDL, like following flow:

TCP Connected

│

▼

Establishment Phase

│

▼

Analyzer → ENQ

│

LIS → ACK

│

▼

Transfer Phase

│

▼

STX Frame 1 ETB

│

▼

ACK

│

▼

STX Frame 2 ETB

│

▼

ACK

│

▼

STX Frame N ETX

│

▼

ACK

│

▼

Send EOT

│

▼

Neutral State

 

My plan maybe not possible to develop on CLV. I just try to see if anyone has done this. Otherwise, we will see their other option working with files.

Thank you,

-hai

[Jim Kosloskey]

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.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Hai Nguyen]

Hello Jim,

The ImmuLINK is client and Cloverleaf is the server.

The ImmuLINK has this reason, so we can’t set the pairs of threads. ImmuLINK act as the client initiating connections to the LIS, rather than the LIS acting as the client, to avoid CPU performance issues observed in previous deployments when ImmuLINK was configured as the host.

We’re on CLV version cis2022.09. I’m not sure if TCP/IP ‘Encapsulated Options’ can meet the several interaction exchange ENQ, STX, ETB, etc. before and after data transfer, e.g.  handshake, ACK, etc. So, I plan to develop a PDL for this work.

Example:

ImmuLINK → ENQ
CLV      → ACK
ImmuLINK → frames (data segments)
CLV      → ACK (per frame)
ImmuLINK → EOT
CLV      → (done)

I’d like to learn if how to configure ib thread “order_ib” sending data to thread ‘bidirection’, then ‘bidirection’ forwarding to ImmuLINK, like returning ACK message to the sender Application.

Thank you,

-hai

 

 

 

[Author]

Replies