How to choose a lab resource scheduling tool: useful technological tips

How to choose a lab resource scheduling tool: useful technological tips

768 432 Optima Team

A good project preparation, the buy-in from the users, the right solution for your specific needs, a smooth implementation, those are the key factors for the success of a laboratory informatic system implementation .
Yet those are not the only assets to be considered when engaged in a paperless project.
There are several factors that most of the times are not considered.  Because they operate behind the scene they tend to be taken for granted. Technology is definitely one of those critical success factors too often overlooked.

In the 21st century, the available modern and innovative technologies are not only at the forefront of exciting new breakthroughs in the fields of medicine, pharmaceuticals and many other sectors, but they have also helped to streamline existing practices and optimise efficiency in the laboratory.

What’s behind a performing lab resource scheduling tool?

In the area of laboratory resource scheduling, the chosen technology plays a crucial role on two major aspects of the implementation: Connectivity and DataBase.

Connectivity refers to the ability of the system to interact with other systems in the smoothest way possible.
DataBase refers to the underlying infrastructure where the data is to be stored.


For most of the end users, these aspects are typically transparent to them and as such not appreciated as it should be. The system connects to other platforms, data are retrieved, supposedly quickly and correctly, and they are stored in an apparently safe place. The data flow into the resource scheduling system from which they are extracted through reporting systems for the elaboration of dashboards. Meaning then that the data are flowing, system works and does the job.

The end-user’s approach is pragmatic and comprehensible. Evaluating the system for what it’s able to offer and how it actually offers it, is the primary objective when choosing a system to be implemented. However, there is the other side of the medal, which, in this case, is the Technology used.

Which technological aspects are key in the choice?

Technological decisions may largely impact the lab daily activities. This is even more relevant for the IT organization that has to support the business operations.

From the Connectivity point of view: a good lab resource scheduling tool should offer web services to connect with any other system (i.e. LIMS, ERP, etc.).

An API library should also be offered to allow the external systems to interrogate the lab scheduling system itself. The combination of those technologies guarantee reliability, quality, security, portability, just to mention a few advantages.
A system which is not designed with the right approaches may not offer all these capabilities. Too many systems are still relying on Excel files transferred between systems (or CSV files, which are simply Excel files converted to text). Optima offers web services and API libraries.  Yet it also allows end users to use Excel or CSV file. Even if considered less reliable, too many legacy systems are still using only this type of communication.

When looking for a laboratory resource scheduling system, make sure that standards like web services and API are available. If not, you may run the risk to get caught up in troubles in very near future because of poor communication between systems, too much information to be uploaded and managed, to the extent that data may be altered or even lost.

From the DataBase point of view: the database is the repository where data are to be stored permanently. Too many lab managers are still using Excel files as a home-made lab resource scheduling tool. The compilation of those multiple Excel files stored in a shared folder happen to be the current repository of the data related to lab scheduling. It may even happen that the Excel files are only stored on the computer of the lab supervisor. The risk of risk of data manipulation and loss is definitely too high.

 Moving to a more sophisticated system for lab resource management implies the use of a database, removing a large amount of risk in terms of security and reliability.
Hence, it is key, when selecting a resource scheduling system, to consider the database technology it has been developed on.

Optima has been designed on Oracle, the #1 database for critical business transactions.
Its level of reliability, scalability and security are far beyond any other databases available today. It allows Optima to support multi-lab and multi-site implementation without disruptions, losses and risks of data manipulation. Not to mention that, thanks to the technology it is based on, Optima can easily and securely store millions of records and maintain an excellent response time while using it.

From the Reporting point of view: the decision to build Optima on Oracle has opened to a large variety of options and huge flexibility for our customers. As Oracle is the most used database, numerous companies offer the opportunity to connect to their database, benefit of their capabilities and build the best tools for creating dashboards, charts, run advanced analytics and more.
It comes without saying, that in order to do so carefree, a solid and robust database is a fundamental asset.

Have you ever heard of system failures due to database corruptions or downtime? If so, that is unfortunately the time when technology becomes familiar to end-users and when the IT department invests urgently hours, or even days, trying to recover a desperate situation. A downtime would affect largely a lab resource scheduling system that should be available 99.9% of the time. To put this percentage into perspective, a 0.01% failure equate to about 9 hours of downtime per year, in a 24/7 working environment. This is definitely something to think about…

All in all, technologies used should play an important role in the decision making to purchase a business-critical system like lab resource scheduling. The right technology will make the difference during the implementation and the daily use of the system.