Instrument automation

Architecture for Host Computer Interfacing of Clinical Laboratory Instruments:

In a secure production environment, applications usually need to interact with instruments that transmit and receive data. These instruments can be of multiple types with varying nature. Communicating with these instruments requires a proper architecture which being secure and efficient provides a complete solution for user interaction with the instrument, communication between instrument and a job that controls the data flow from and to instrument, communication between the Instrument Job and Production database on a secure channel and a proper error-free mechanism for switching off and on the job so that it does not keep on executing and consuming job server resources even when instrument is idle.

This document presents a complete architecture for this activity and considers the following points:

• Instruments send data on serial port whereas the serial data needs to be converted in network streams in order to process it on Job servers.• A dedicated machine can be spared for each instrument with serial port connected to instrument and that machine sends data on network.o Increased cost, maintenance issues.• A dedicated machine reads data from the instrument through serial port and files that data on Production database processing it through the job locally running.o Security Issues.o Version Maintenance.• A UDS device which converts serial data to network streams and sends it over network which is read by an instrument job on some Job Server which then processes the text streamo Will that job run continuously?o If not how will the users interact with the job with no access to job server?o What will be the centralized mechanism for job initiation and termination?• A proposed framework for the whole interfacing scenario.• Generalization for any device that needs to controlled on similar environment.

General Outline

User interacts with

Instrument Job Desk• Initiate start, stop and terminate requests.• Writes each request in Job desk queue.

Instrument Job Desk Queue:• Has entry for each request generated and is processed by Instrument Controller with a specific ID.• Request Type is the basis on which Instrument Controller reads the request and updates request status.• START, TERMINATE and CHECK requests are processed by controller.• STOP request is processed by instrument job.

Instrument Controller• Each controller has a specific ID which it uses to track the requests generated for it.• Processes requests of type START, TERMINATE and CHECK.• Initiates Instrument Job.• Terminates running job forcefully.• Check whether a job is already stopped or is already started.

Instrument Jobs• Actual Instrument data Processing is done through instrument jobs.• When started updates instrument job desk to mark itself as started.• Processes data streams from instrument.• Reads results and sends query response back to instrument.• Processes stop request generated through Instrument Job desk controller.

Job Architecture

• Controller initiates a job.• Job connects itself with a particular device to listen to raw streams of data.• If connected, it marks itself as started.• After some time interval, it checks itself for the request to stop processing.• If a stop request is found and the job is not in Critical Section, it immediately exists, otherwise waits for critical section to terminate.• If data arrives, job begins a Critical Section, starts processing raw streams of data.• If the raw stream is of a result, then results are filed on the specimen whose ID is sent by the instrument.• If the raw stream is query for tests, generated by the instrument after reading a barcode, the ID sent is processed and a message is generated in the standard followed by the instrument.