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

 

 

 

[Jason Russell]

I’m super curious about this now, as it seems they’re mixing terminology a bit. Things like ‘frames’ are a TCP term and are transport layer items that we don’t particularly care about. I’m also curious about the client/host configuration, a lot of things just seem ‘off’ with the way they’re being described. I can’t immediately pull specs since we don’t use the system.

What data type is this (HL7, FHIR, etc)? What is ENQ, STX (I’m assuming start transmission), ETB (end block?). Are they trying to run on the transport level with TCP/IP or in the application level, in which case they shouldn’t be worrying about the TCP/IP.

Secondly, unless you have data waiting, ImmuLink can’t be the initiator to ‘get data’. If there is a result, they should just send the result, you send an acknowledgement (standard) and send the result to the LIS.  If they are expecting data (getting orders, etc) they need to be the server to be available to get a message when it gets sent.

I may  be missing specific experience here, but the request isn’t making a lot of sense.

What is the high level data flow? Is there an order or a message TO them to get some sort of message back (Order and Result), or are they sending a message and expecting a status (Message and ACK)?

The CLV > ACK sounds suspiciously like TCP/IP work that should already be standardized and in this day and age shouldn’t be modified. This is why I’m a bit confused as to what they’re actual request is.

[Hai Nguyen]

Hello Jason,

it’s ASTM, I attached the spec , hope it can answer your questions. Due to the complexity of this interface, I’m thinking about developing a process outside of Cloverleaf, e.g.  daemon.

Thanks for checking,

-hai

Attachments:

You must be logged in to view attached files.

[Jason Russell]

Thanks for that. That helps a lot. That’s definitely not a communication method I’ve seen nor is very common anymore. I almost thought it was DICOM, but that’s not the case here. I’ll leave it to the more experienced (Jim), and hope we never have to cross that bridge as it looks convoluted and written on levels we shouldn’t have to be thinking about anymore (looking at their split between Low Level and High Level Protocol). I’ll follow this thread, good luck!

[Jim Kosloskey]

One thing to do is to check with the vendor to see if they have any customers using Cloverleaf to integrate. If they do, get a contact person at that customer site and pick their brains.

Given the spec, I still think this can be done in Cloverleaf which will provide management and monitoring benefits if it is accomplished. I think PDL will be needed, however.

A challenge may be defining the message structure as it is not a standard. You may need a combination of HRL with VRL.

I would not get thrown by the vendor wanting to be the Server when initiating transactions, that is not a showstopper – I have done that many times within Cloverleaf without issue (if everybody plays the game right).

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

[Hai Nguyen]

Thank you, Jason and Jim,
I will check with ImmuLINK to confirm whether they have worked with CLV.
I initially developed separate PDLs for inbound and outbound processing, though neither is fully complete. Since the vendor requires bidirectional data exchange, it became quite complex to consolidate everything into a single PDL.
As a result, I shifted to developing a standalone program as the front end to ImmuLINK and CLV as the backend for integration with other applications.
Thanks again for looking into this.

• This reply was modified 2 weeks, 3 days ago by Hai Nguyen.

[Author]

Replies