Creating a LIS Middleware Server for Linux

Recently, a client asked The RND Group to create a custom solution for integrating instrument software with Laboratory Information Systems (LIS). The instrument software has been developed by the client and is part of an FDA Class II medical device. When searching for a solution to connect its instrument software to LIS systems, the client tapped RND Group based on the LIS Connector software product offered by RND Group. The LIS Connector product has been successfully released in several FDA approved instrument software deployments, so the LIS Connector is a proven, verified product for integrating medical device software to LIS systems.


The client worked with RND Group’s consulting services staff to design a custom server implementation that embeds the RND Group’s LIS Connector product as part of a middleware “LIS server”. This custom server is deployed as a daemon (server) process on Ubuntu Linux. This server logical design is illustrated below.

The LIS server addresses the following key design considerations:

  1. Separation of concerns – allowing the instrument software to focus on business logic, instrument hardware control, and the user interface, with the LIS Server focusing on LIS Host communication and LIS protocol-specific logic and mapping
  2. Integration between software written in different programming languages. The instrument software is written in Java and the LIS Connector is written in C#
  3. Providing a high availability interface to LIS Hosts, in terms of re-establishing communication to either/both the instrument software and LIS Host, as necessary

Specific Development Challenges

To be a successful solution for RND Group’s client, the development process of the custom LIS server had to meet several key requirements. These include:

  • Porting the LIS Connector source code from Windows to Linux
  • Running the LIS server as a Unix daemon process
  • Implementing an HTTP REST interface to the instrument software to allow the LIS server to retrieve and update data in the instrument server database
  • Implementing an HTTP WebSockets interface for the LIS server to receive notifications of events from the instrument’s software – such as new test result(s) available to send to a LIS host system
  • Making the LIS server fault-tolerant to recover from being disconnected from either the instrument software or the LIS host system

Porting LIS Connector Source to Linux

The first challenge faced by RND Group was that the LIS Connector product had, previously to this project, only been released on Windows operating systems. For a little background, the LIS Connector source code is written in the C# language and consists of over 50 separate source projects, with each project being compiled into an executable program or a program library. The majority of the projects are libraries, with separate libraries for different communication transports, (TCP, serial, file), different LIS protocols (ASTM, HL7, POCT1A), and different client application programming language interfaces (C#, C++, NServiceBus). The rest of the projects consist of unit and integration tests, and a collection of testing programs and simulators. These various projects were “ported” to Linux by changing the version of the .Net framework used to compile the source – from a Windows-specific .Net framework to the cross-platform .Net Standard framework. .Net Standard can run on any platform supported by .Net Core (Windows, Linux, macOS, others). To test the results of porting the source code to Linux, the unit and integration testing projects were used to confirm that all tests still passed successfully when compiled and executed on Linux. During the porting effort, about 10% of the code had to be updated to use cross-platform system services instead of Windows-specific system services.

Running as a Linux Daemon Process

The .Net Core framework provides IHostedService, which is an interface and implementation that abstracts the differences between how the supported platforms like Windows, Linux, and macOS manage the interaction between the operating system and a service process. IHostedService provides two primary methods that a service process must implement – StartAsync and StopAsyncStartAsync is called by .Net Core when the operating system is starting up the service process, such as being started from the Linux “init” process startup, or from the Windows Service Manager startup. Similarly, the StopAsync method that .Net Core calls on a service process is connected to the different methods that can be used on each operating system to shut down a service process. The .Net Core run-time hides all the differences and complexities of how different operating systems manage services processes. This allows the service process that implements the .Net Core IHostedService interface to automatically be portable across all operating systems supported by .Net Core, which is a great advantage for developers in achieving “write once, run anywhere” code.

Implementing HTTP REST and WebSockets

The client requested the use of HTTP REST and HTTP WebSockets interfaces for communication between the instrument software and the LIS server. These technologies were chosen based on the existing architecture for the instrument software but, more importantly, the use of HTTP REST and WebSockets provided a proven method for communicating between software modules written in different programming languages. The basic workflow for communication is for the instrument software to send a WebSocket message to the LIS server indicating some event, either hardware or user-initiated, has occurred. The LIS server, upon receipt of this message, uses an HTTP REST API call back to the instrument software to retrieve or update data based on the WebSocket request received. Below is an example of handling a “new sample barcode scanned” message:

The implementation of HTTP REST and WebSockets was straight-forward and, again .Net Core provided a nice, cross-platform method of performing HTTP communication. The HttpClient class from .Net Core provides a high-level interface for performing HTTP REST calls, while the WebSocketClient class from .Net Core provides an easy-to-use interface for communicating with WebSockets.

Fault Tolerance

The client requested that the LIS server be able to recover from common error situations like loss of communication with the instrument software, loss of communication with the LIS Host, errors in reading/writing data, and any other potential recoverable error condition that the server process might encounter. The LIS server is required to run 24 hours a day, 7 days a week, so the need to recover from errors and be fault-tolerant is very critical. Taking these considerations into account, custom code was developed to monitor the status of the connections to the instrument software and the LIS Host on a regularly, using the .Net Core Timer class. Timer calls a custom function on a regular time interval and this custom function contains the logic to check the status of the connections to the two servers that the LIS server interacts with. If the logic discovers that either connection has failed, it re-initializes the connection so that normal processing can be resumed.

As a general recovery method and following software development best practices, exception handling has been implemented for the entire application and the LIS Connector library so that any error conditions can be caught, logged to a common location, and, if appropriate, error status can be returned to the code or external process that started the request that triggered an error.

As described above, the LIS server makes use of the IHostedService interface in .Net Core, so if the entire system were to be restarted, the LIS server process would shut down gracefully and be restarted automatically when the system comes back up – and, again, in a cross-platform manner, so this server code could be moved without change to other operating systems like Windows or macOS.

Final Results

As of the writing of this article, the client has taken delivery of the LIS server implementation and has integrated the source code into its overall suite of software. The LIS Connector product from RND Group is licensed as source code, so the client now has the option of maintaining the delivered product plus custom LIS server code, or they can call RND Group for maintenance or enhancement work on the delivered code. The expectation for this client is to submit a 510 (k) application for their instrument software, along with the LIS server component, to the FDA this year. An added benefit for this submission is that the LIS Connector is provided with unit and integration tests, full design documentation, and a requirements document, making it ready to use in any class of medical device software.

Authored by: Brad Graves, The RND Group, Inc.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top