Median system

Medical instruments and laboratory information management system median communication software.

The problem when designing LIMS

When designing a laboratory information management system, for a certain medical lab, or a hospital laboratory
facility, the software developer (and by developer I mean either a single developer or a team) usually deals with
certain data traffic and management problems with usual user interfaces, however, when dealing with the problem of
automating the medical instrument and processing the data transmitted and queries required by instruments, the
developer has to learn to use protocols and program low level sockets and port management, with threading and
timing protocols. Also, developer has to learn medical communication standard protocols. This problem could waste
time and effort of developer.
A typical software developer will either build software to be a web based to ease the installation and using process, or
make it central desktop based software that work on one device or several devices, in either case the software will
have to store, manage, process data passed through the system, therefore the system will use database or file storage
system mechanism. And when the need comes to access this storage system it has to be through application interface
server or direct communication with database server.
Whether it is a direct communication with database or using and application interface there is a server handles
requests through given links or though programmatic functions.
The solution to the medical instrument to LIMS communication problem is to make an easy programmatic solution or
ready software that handles the communication between the LIMS and the medical instruments, where this software
communicate with LIMS system through an API, which make it easy for developer to include instrument automation
to the LIMS system, and this median system could hold a separate backup of the results for each instrument specified
as a light database system or storage system, indicated with specimen barcode and specified test. This will provide
many advantages in case of major server corruption. And the median system could include an ability to check if a
certain test for certain specimen is uploaded or not to the LIMS server, and if it is not, it will automatically upload the
attempt to upload the results, even if a network failure occurs, then it will hold and will attempt to upload back again
after certain period or when a result is received.

The Approach for designing a medical laboratory median communication

software
Based on the communication methods that every instrument follows, we need to design a handling system that handles
the request from these instrument based on; the communication approach followed, watch for queries or transmitted
data out of the instrument by building a server or threading system, respond properly based on the instrument protocol
used by the instrument, check for validity of this data, decode the data based on the protocol used on the instrument,
save the data on a local storage system, contact the main LIMS system and transfer the data on the main system and
check each result is sent or not, if not a retrying is need to be done every specified time or based on certain trigger like
when receiving new result, a user interface for each instrument should be prepared and should contain the capability to
modify any of the properties specified.

Communication approach
Since must instrument communicate whether on serial communication, or on TCP/IP network communication, we can
design two separate handling system for each approach, the two methods are handled too much differently, therefore,
it should be the greatest priority to make this as the base of the intended software.

Serial connection
If the communication was serial based then, we should physically connect that serial connection of the instrument to
the hosting computer that contain our median system, make sure that it is recognized by the operating system, and list
the available serial ports on the interface and letting the user chose which port is used on the computer by the
1
instrument, and then establishing a connection by opening the serial port, after opening a serial port and since there is
no repetitive handling system watch for request from the other side that we can easily find and include in our system,
we need to design our own handling system for serial communication which will check if there is a data waiting to be
read on the port.

Listing serial ports and trigger user action.

In order to give the user the choice to chose what port exactly the instrument is connected to, the median software will
list all the serial ports available on the hosting computer and then when the user want to connect to the instrument, the
software checks what is the chosen port and tries to establish connection on it.
In order to list and use serial ports on the software on whatever programming language is being used, a helper library
or method and functions must be used to help ease the task of designing and handling the serial ports connection.
Using these helper methods there could be capability to list the available serial ports and their details on the host. And
reorganize these details and give them to the user in order to choose from them.
If an error occurs while trying to get the ports an error is displayed on the user interface indicate that an error
happened while trying to access the serial ports.

Opening port
In order to open a port, you need to have the appropriate system permissions, which usually is granted automatically
by the operating system and should not be of any concern.
When trying to open serial port first thing is needed to be done is to check if the port is in use or available, if not in
use, then the software should try to establish connection with that port, then checks if the established connection
opened the port automatically or not, if connection not opened, then the software will attempt to open the port, if
success then a state of connection is established that indicate that a connection is established and the port is opened.
The state of connection could be of any kind, it could be a flag variable, or a already given state of serial object that is
created priorly.
After opening the port, the software will check the state of connection and will continue for the repetitive threading
system.
In case of any error while establishing the connection then the software will cancel the attempts and will a error
message on the user interface that shows a connection establishing error.

Repetitive checking
To check whether there is a message or not on the serial port there should be a method that is triggered every specified
(less than a second) time interval, and once the method knows that there is data waiting on the port then, it will call a
continuous reading method that will read every byte of the incoming message and checks for it and then respond with
the appropriate response. And when the message ends, it is handled properly, after that the loop continues to read a
new message.
The need of Threaded reading system is to allow the handling and reading process to take place in the background
quietly without interrupting the user interface.

Continuous reading loop

Once a message is detected on the port a reading loop is established, that reads every byte individually and check if a
appropriate response is needed, this loop will continue while there is something to read from the instrument.
While reading from the instrument a protocol syntax should be followed to indicate whether that is a valid message or
not, and to check for the checksum of that message.
The fully completed, decoded, saved message should be shown to the user. Any error occurs will disconnect from the
instrument and will close the port and then shows an error message.

2
Network connection (TCP/IP)
If the communication method was network based then it much easier to watch for messages coming from the
instrument, since the handshake, verifying, and repetitive check is done automatically on the TCP/IP protocol all
needed is to start a socket or server and making sure that the hosting computer has a constant IP on the local area
network and that the established server is listening on intended port. In some cases the socket server is the instrument
itself, and this irregular case is found on the Mindray BC20/30S instruments. Where the host computer works as
client.

Specifying IP and port number

A typical personal hosting computer usually has several network adapters, WIFI, Ethernet, …etc. and each adapter has
an IP address when connected to a local area network, usually there is only one local area network and therefore only
one Adapter is connected to the local network and has a valid IP address, there for in order to specify the correct IP for
the host on the local area network it is necessary to check which adapter has access for the HTTP protocol through a
software check and getting the IP address for that adapter, and also the interface should give the user the ability to
insert another IP address if not that one is used. The network port number on the other hand must be specified by the
user, and should match the network port number on the instrument communication settings.

Establishing a connection on the given IP and port number

After specifying the IP and port numbers, socket is should be created and bonded to the IP and port given. After
checking the validity of the established connection, the socket should be returned for a server handler and listener to
check for any client requests (and by client request I mean the medical instrument request for query or result
submission, or only to establish a permanent connection).
Note that the term socket and server are used interchangeably but both means TCP connection listener and handler.
If the instrument takes the rule of server, then the hosting computer has to be the client and has to ask for connection
to the specified Instrument IP and Port, therefore, the IP on the interface of that kind of medical instruments is
specified to be the IP of the instrument itself, the reading and handling process is similar to the server process.

Listening for clients

After bonding the connection of the socket, a listener is established and it wait for only one connection request, and
the reason of letting the socket listen for only one request is to make this socket only for one instrument clearly.
If the instrument connection is established, an infinite receiving loop should be created, and make the server listen for
messages coming from the instrument.
As mentioned, while the server is handling one connection it cannot receive any other connection request, since we
specified only one request allowed.

Receiving message on a connection

After establishing a connection and accepting a request from the medical instrument, the server should listen for
messages coming from the instrument, and when a socket listens a maximum message size should be specified and in
this case since must instruments use a permanent connection the size should be quite large to receive the entire
message. A typical size could be around 8KByte to 10Kbyte.
When a message is received it should be handled properly, by looking into the message type and then transferred to
the corresponding handling method.
Must of typical medical instruments that use the Network based connection run on the HL7 protocol. And usually
there is two types of messages, either a query which basically the instrument is asking about the required tests for a
given sample barcode. The other type is a result submission for a given sample.
And in each case a proper response should be sent from the server to the instrument.
In TCP when the other side send you an empty message which is a new line ascii character, it means that the remote
side is asking to close the connection properly.

3
Local storage system
After decoding and preparing received results a local copy should be saved before transmitted to the main LIMS
system, therefore, a storage system should be created to save each sample barcode its parameters and the time stamps
related to that sample. The storage system should be light and doesn’t take a much of resources, also, it should be
secure and finally it should be practical to use.

Choosing storage system

A several storage systems are available to chose from starting from saving the data on a raw file system, like saving
results on text files and opening and closing several files, but also more practical is to choose a database system.
A several database techniques is available but the must important condition is that the system must be light and not
require a lot of resources, therefore it should not require a server on its own or something like that. Also for
practicality it should support SQL syntax. And that doesn’t leave only one choice out there satisfies these conditions
which is SQLITE3 system.
SQL refers to Sequel Query Language, is a domain-specific language used in programming and designed for
managing data held in a relational database management system (RDBMS), or for stream processing in a relational
data stream management system (RDSMS). It is particularly useful in handling structured data, i.e. data incorporating
relations among entities and variables.[ CITATION wik \l 1033 ]
SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL
database engine. SQLite is the most used database engine in the world. SQLite is built into all mobile phones and most
computers and comes bundled inside countless other applications that people use every day.
The SQLite file format is stable, cross-platform, and backwards compatible and the developers pledge to keep it that
way through at least the year 2050. SQLite database files are commonly used as containers to transfer rich content
between systems and as a long-term archival format for data. There are over 1 trillion (1e12) SQLite databases in
active use. SQLite source code is in the public-domain and is free to everyone to use for any purpose.
The code space used by the SQLite library depends on the target platform, the compiler, and optimization settings.
These variables also affect performance. 35% Faster Than Filesystem, SQLite reads and writes small blobs (for
example, thumbnail images) 35% faster¹ than the same blobs can be read from or written to individual files on disk
using file read or file write. Furthermore, a single SQLite database holding 10-kilobyte blobs uses about 20% less disk
space than storing the blobs in individual files. The performance difference arises (we believe) because when working
from an SQLite database, the open and close system calls are invoked only once, whereas open and close are invoked
once for each blob when using blobs stored in individual files. It appears that the overhead of calling open and close is
greater than the overhead of using the database. The size reduction arises from the fact that individual files are padded
out to the next multiple of the filesystem block size, whereas the blobs are packed more tightly into an SQLite
database.[ CITATION Sql \l 1033 ]

Brief explanation on SQL syntax

In SQL database, data are stored in tables, and each table contain several columns, where one of these columns is a
primary key for that table where it should be unique and never repeated since it distinguishes each row on the table,
also, a row could relate to other row on other table through a foreign key column on the first table, there are three
main types of relations; one-to-one, one-to-many, many-to-many.
You can insert to, delete from, update on, any table by using the right syntax, also you can pick a specific row by
using conditions that a column value should be equal or not equal to a given value, or maybe less then or greater then
if the column in question is numerical.
Any new inserted value should have a distinguishable primary key which mostly called the Id column and in must
SQL systems this id can be generated automatically and can take auto incremental value starting from 1, however
sometimes the system in question doesn’t support this feature so its important to keep track of the length of the table
and increase from zero that value, or create a counter table that holds one unsigned long integer value that increases
with each insertion process to the table in question.

4
The picking or getting process is know as selecting, where you can select all column from a given table, or just select
one or more columns on specific and the selecting can be conditioned as mentioned. The same for the update, insert,
and delete processes.
A keywords and details are illustrated in the table below. Note that all commands should be capitalized for tradition
sake.

Table 1 SQL syntax.

NO. Keyword Explanation Example

1 SELECT Selects a all or some of the columns in a given table, with SELECT * FROM <table name> WHERE
<condition>;
or without a condition that each selected row must satisfy.
SELECT <columns separated with comma>
FROM <table name> WHERE <condition>
2 * Is used as the word all -
3 INSERT Inserts values into table, and should have a primary key. INSERT INTO <table name>(<columns separated
by comma>) VALUES(<values for each
Generated automatically or inserted manually. corresponding column separated by comma>);
4 UPDAT Used to update a column value on a table, note that a UPDATE <table name>
SET <column1> = <value1>, <column2>=
E condition is necessary, if condition is not given then all <value2>
row on that column will be updated to the given value. WHERE <condition>;
5 Delete Removed a specified row from table, also, note that its DELETE FROM <table name> WHERE
<condition>;
very important to specify a condition for the rows going to
be deleted or all the row on that table are going to be
deleted
Note that sentences inside the <> brackets are used for explaining purpose.

User interface
The user interface should be accessible remotely and combines the ability to access all instruments from one interface,
also, should not require any installation to access it remotely. This will make it easy to access the median system
interface and the LIMS system on the same front end. The user interface should make it easy to access any instrument
and disable or enable its connection, also it should be easy to access any sample coming from any instrument, the
sample should not hold the patient name and other personal data, but holds the sample data, which are the barcode
which will be the most and only requirement to save a sample, and other optional data if found, on the other hand, the
sample is not related to the instrument, what related to the instrument is the tests that applied on the sample.
Therefore, each test is related to a sample and instrument, and holds the important data such as the results itself, the
abnormality, the bitmap for graphs, …etc.
Also, the text and status messages that each instrument communication protocols sends to the median system, and
each event record, should be saved as messages related to the instrument in question, and should be accessible on the
interface, also the messages should hold time stamps for farther filtering purposes.
The interface should hold the ability to add instruments, and when adding instrument, you can give the instrument
nick name and should be able to chose the type of the instrument from a predefined set of choices, and based on the
instrument chosen a medical communication protocol is chosen (whether an ASTM or HL7), also, you need to give
the connection parameters related to that instrument, like the port number if serial, or the IP and port if network based.

Choosing the interface development base

For an interface to be accessed remotely from any place on most devices, it should be web based, therefor a web
developed interface is required.
A web-based application can be installed on one host, and that host can be applied as server which will provide the
access for the application, of course the access can be done through a web browser.

5
Specifying how should the sample results and information be saved
Each instrument median software should have its own database, and within this database it should hold a value that
specify each sample, and each sample could have several test results and information.
Therefore, what really distinguishes a sample on a LIMS and an instrument is the Barcode of the sample. Therefore
each sample should be save based on it barcode, and its results can be referenced through that barcode.
Therefore, there should be a table holds the samples barcode and a table that hold the barcode as nonprimary value
along with the results for given test. The id for a given test is given using a counter table that tracks the length of the
results table.
A relation is not required here, but an initial insertion of the sample barcode into the sample table is required, and the
checking of the validity of that barcode is required before writing any test value into the results table as manner of
security and error prevention.
An error prevention here means that if a barcode is reinitialized on the LIMS main system or an old sample is retested
then the value won’t be accepted, since inserting already existing barcode will fetch all the old and new tests for the
barcode in question. Therefore, a prevention method as a primary sample table is required.
A sample won’t be stored on query case, it will only be stored on result submission for that sample.
In the table that holds the test results, there should be a column that specify the state of a given test, whether it’s
uploaded or not, and if the LIMS specified that the sample in question is not recognized to wrong barcode entry or
other reasons, which should show and error message on the user interface,
The following tables illustrates each table and it corresponding columns that should be created.