LIMS in transition: from device connector to data center

blomesystem2

Demand for laboratory information and management systems(LIMS) is expected to almost double in the next five years. The main winners will be those providers whose LIMS can act as a data hub, is oriented toward holistic workflows and can be integrated with third-party systems - including external ones.

Laboratories are not islands

Markets and Markets researchers predict that the size of the global LIMS market will almost double within the next five years - from the equivalent of around €950 million ($1.1 billion) this year (2021) to around €1.8 billion ($2.1 billion) in 2026. The analysts cite the crucial role of LIMS in meeting stringent regulatory requirements, as well as technological innovations in LIMS offerings and, increasingly, the adoption of cloud-based LIMS solutions, as the main growth drivers.

However, in five years, a LIMS will differ in many aspects from today's solutions. The COVID 19 pandemic, for example, has once again underscored the fact that data management is playing an increasingly important role and that a LIMS must be able to map comprehensive workflows instead of focusing on individual functions.

In addition, LIMS systems no longer have a future as isolated solutions. Accordingly, it is not enough for the workflows to function within the respective LIMS and an individual laboratory; they must also be connectable to third-party systems and the solutions of external business partners. In concrete terms, what is needed are largely automated workflows and up-to-date, market-standard interfaces that enable such integration. This is currently one of the biggest challenges for LIMS providers.

First example: COVID (DEMIS)

Especially since sometimes things have to happen quickly. This was recently demonstrated by the "German Electronic Reporting and Information System for Infection Prevention" (DEMIS). Its aim is to process and transport health-related information digitally from end to end. This is also intended to reduce the workload for those who report cases, i.e., primarily physicians and laboratories, while the data will reach those responsible in the healthcare system - i.e., the health authorities, the respective state authorities and the RKI - more quickly. Although DEMIS has existed as an interface standard for some time, the COVID pandemic acted as a turbo that pushed many implementations and brought them to completion. The background to this was the amendment to the German Infection Protection Act last year and the widely discussed public requirement that communication between laboratories, public health departments and higher-level authorities should no longer take place by fax, but should be digitalized and automated via DEMIS.

During this changeover, many laboratories found out how (in)flexible their LIMS deals with external formats and the connection to third-party systems. All the more so because, beyond the pure data transfer, there were also further questions to be answered: Can the LIMS perform calculations and/or plausibility checks before the transfer to the DEMIS adapter takes place? Conversely, is it possible to evaluate the adapter's feedback and make it available to the various LIMS functions? In addition, the connection to the Corona warning app was often on the agenda.

On the part of Blomesystem's customers, for example, mainly the state investigation offices were affected. Due to the modularity of their LIMS LABbase, Blomesystem was able to equip their solution with the required interface within a short period of time and furthermore designed it in such a way that it can also work with any database and with any installation.

DEMIS
Figure 1: German electronic reporting and information system for infection control. © RKI

The COVID/DEMIS example underscores the fact that a traditional LIMS, which predominantly only connects and connects measuring devices and evaluates their data, is no longer sufficient. Rather, today's LIMS must be able to function as a central data hub for laboratories, integrating various third-party systems in the laboratory and also with external systems at a central point in such a way that continuous and automated workflows are created.

Second example: Food safety (AVV DatA)

Another example is the AVV DatA interface: The "General Administrative Regulation on the Exchange of Data in the Field of Food Safety and Consumer Protection" primarily regulates data traffic between the Federal Office of Consumer Protection and Food Safety (BVL) on the one hand and the state investigation offices on the other. The reports from the state offices to the federal government follow the structure of the AVV DatA catalogs, which must be implemented in their revised form by January 1, 2023 at the latest.

For the laboratories, which are assigned to the state offices, this means a clear cut: They have to work with lists, mono- and polyhierarchical classifications or classifications plus facets, which have changed considerably in some cases (see figure 2). Blomesystem has therefore not only converted its LIMS LABbase to the new data structures in the interfaces of its applications. To ensure that the data is always checked for consistency and quality, data pre-checks and feedback to the BVL are also added. Last but not least: In the transition phase from the old to the new world, the respective LIMS must be able to work with both the still current and the future AVV-DatA catalogs. LABbase builds these bridges.

AVV
Figure 2: The new structure of the AVV DatA catalogs. © Federal Office of Consumer Protection and Food Safety

How integration succeeds

Such a changeover can only be implemented economically and within the required time frame if the LIMS is structured independently of the manufacturer - not only so that in principle any laboratory device can be connected, but also different software from other manufacturers. In this way, integrated process control systems can be created that can differentiate: Is the information in question a single file, a web service, or simple data that is simply to be forwarded over the network? And how does the data get into the system? What is the definition of the respective data, what is to be done with it and where in the LIMS will it be placed? Finally, the output of the data processed by the LIMS: Should it be viewed again before the test report is generated? And in what form is this output and transferred - possibly even to an external system?

Since, in view of these challenges, a LIMS should be as flexibly adaptable as possible, the time of standardized, in the sense of fixed interfaces, is gradually running out. They are being replaced by systems that can be parameterized, on which the laboratories can partly set certain functions or data assignments themselves. And if, at a certain point, it is no longer possible without "real" programming, the developers of the respective manufacturer can make the necessary changes comparatively quickly and cost-effectively.

Process instead of function

The be-all and end-all of such a LIMS is open programming that does not only offer ready-to-use, but therefore rigid functions and connections. Rather, the solution should follow a modular approach that thinks in terms of comprehensive workflows instead of individual functions: process-oriented instead of primarily function-oriented. If the LIMS is really to assume the position of a data hub, it needs this adaptability. Even if it is only for data that is merely stored in the memory and not processed in the actual LIMS.

The importance of this orientation towards overarching workflows is again demonstrated by the example of COVID: At the beginning of 2021, with the emergence of new and more dangerous virus variants, sequencing of samples became increasingly important. As a result, many laboratories no longer had to report only positive or negative results. Rather, the RKI required a systematic search for mutants and corresponding secondary reports for numerous samples. This expanded the laboratories' workflow and required correspondingly expanded interfaces between laboratories, public health departments and the RKI.

Without a module- and process-oriented LIMS (see info boxes for the most important advantages), such rapid adaptations are hardly economically feasible today. Especially since a LIMS must ensure that the transfer of measurement data to other systems is fast and error-free, even if requirements change frequently and at short notice, with it as the central data hub.

Advantages of a workflow-oriented LIMS

  • Users are "guided" through the workflows that are relevant to them, so that many inputs and operating steps are self-explanatory
  • The required functions (but only these) are available at all important steps in the business processes
  • The resulting more efficient work performance saves significant time and costs
  • The effort required for user training is significantly reduced

Advantages of a module-based LIMS

  • Low initial acquisition costs: additional modules can be purchased later for expansions
  • Focus on real needs: Customers can purchase only those modules they really need.
  • Future-proof and quickly adaptable: Modules allow a LIMS to be quickly adapted to new requirements and expanded with new functions.

Contact us

You are currently viewing a placeholder content from HubSpot. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.

More Information

You are currently viewing a placeholder content from HubSpot. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.

More Information

GUS LAB Newsletter

Don't miss any more news and sign up for the GUS LAB newsletter. Here you will be regularly informed about our software and solutions.