Introduction
Duplex communication between LIS and the laboratory machines (e.g., BS 800) is required to complete a POC for demoing to the clients. This document describes the initial basic version which will be responsible for communication between the laboratory machines (e.g., BS 800) and the lab information system. Error scenarios, scalability and robustness are currently out of scope. This system will be enhanced after the initial POC is working reliably and the concepts are clear. The LIS-communicator system is currently under heavy development, and will need a couple of iterations to achieve the desired results.
In this initial version, we try to keep things as simple as possible.
Architecture
Components
Mirth connect is the central component which is responsible for receiving and sending HL7 messages to and from the laboratory machines.
The problem (which is yet unresolved) is that we do not know how to open duplex channels using mirth connect. Duplex channels in mirth enable the sending and receiving of HL7 messages from the laboratory machines, and they use the same open port between mirth connect and the machine.
Therefore, we solve this problem by developing two small components which will allow the LIS to send and receive HL7 messages in real time.
mirth connect relay
The mirth connect relay is a simple TCP server written in Typescript. It opens 3 ports:
- relay – lab machine
- relay – mirth connect for LIS2machine messages
- relay – mirth connect for machine2LIS messages
The relay will simple pass on messages between mirth connect and the laboratory machines. In this way, we enable our system to handle duplex communication between mirth connect and the lab machine. This software will reside in the communicator proxy.
LIS2machine message: messages coming from the LIS and going to the lab machine
machine2LIS message: messages coming from the lab machine and going to the LIS
LIS DB listener
The LIS DB listener is a simple server, also written in typescript and residing in the communicator proxy. It will listen to the database table changes using Supabase realtime.
Let us consider a simple example to understand the working of this component.
Simplified Supabase Realtime table (example‚)
| ID | message | from | to | state |
|---|---|---|---|---|
| 1 | msg#1 | BS800 | LIS | processed |
| 2 | msg#2 | LIS | BS800 | new |
| 3 | msg#3 | BS800 | LIS | new |
The table below shows three messages:
- msg#1: BS800 has sent a message to the LIS and it has been processed (marked by the column named state)
- msg#2: the LIS has sent a message to our machine (BS800) and it is new (i.e., not processed)
- msg#3: BS800 has sent another message to the LIS and it is unprocessed
In this simple case, the LIS DB listener will be triggered twice (because of msg#2 and msg#3). It will first filter the messages which are still unprocessed (state = new). Thereafter, the messages will be filtered again and only the relevant messages (i.e., LIS2machine) will be extracted and sent to mirth connect.
Sequence diagram
sequenceDiagram
BS800 ->> mirth connect relay: machine2LIS message
mirth connect relay ->> mirth connect: machine2LIS message
mirth connect ->> logger: store machine2LIS locally to disc
mirth connect ->> supabase: store message to supabase
Note over supabase, LIS: Supabase realtime
supabase ->> LIS: inform LIS using supabase realtime
LIS ->> supabase: LIS2machine message
supabase ->> LIS DB listener: LIS DB listener trigger and filtering
Note over supabase, LIS DB listener: Supabase realtime
LIS DB listener ->> mirth connect: send LIS2machine message to mirth
mirth connect ->> logger: store LIS2machine message to disc
mirth connect ->> mirth connect relay: forward LIS2machine
mirth connect relay ->> BS800: LIS2machine message
Logging
Mirth connect will store all the logs to a text file in raw format to the disc on the communicator proxy (locally).
If mirth connect stores a lot of messages to disc, we can run out of disc space.