Laboratory information management systems (LIMS) are a powerful tool for capturing and managing your laboratory data. Once you’ve started generating and cataloging data in your LIMS, how do you get it out in a meaningful way? This LIMS Success Tips post discusses six ways to make your data actionable.
During requirements gathering, we often hear a request that the LIMS alert certain people when a specific condition occurs. Generally, it’s around sample lifecycle (e.g., sample analysis is finished) or system status (e.g., system outage).
I cringe when a customer asks for these alerts to be sent via email. In most cases, an email inbox is not sustainable for this type of alert. The problem is that these alerts can get lost in the noise of a busy inbox. It’s akin to “alarm fatigue” that is pervasive in healthcare. You’ll be familiar with this if you’ve spent time visiting a loved one in the hospital. Inevitably, some machine is incessantly beeping and flashing, yet nobody pays any attention to it. The recommended solutions for healthcare are to tune the alarm parameters to a specific patient and disable unnecessary alarms. Using this same philosophy, email alerting should be kept to a bare minimum and only delivered to a small audience.
Some customers use messaging platforms such as Slack and Teams to alert specific groups of users. For example, server monitoring tools such as New Relic can feed alerts into a Slack channel. When system administrators and lab managers are subscribed to such a channel, a production alert can start a real-time discussion leading to the issue’s resolution. You can use a similar approach to alert sample handlers when a specimen is ready for storage or shipping. Somebody on the team would respond to let the others know it’s being handled.
Short message service (SMS) alerting with a utility such as Twilio, Telnyx, and MessageBird can be handy for urgent system status alerts. Many customers find this low-frequency, high-impact alerting useful to keep their system downtime to a minimum. Remember that since a crashed LIMS server may not be able to tell you it’s down, this alerting typically requires an external watchdog utility to trigger the alarm.
This is the most traditional type of LIMS report. Report templates are typically pre-configured by a system administrator. An end-user invokes a report from a specific LIMS object (e.g., a batch) or a toolbar, and the system responds by retrieving data and populating the template. From there, the user can print, save, or email the report.
The rigid nature of LIMS reporting templates is a double-edged sword. On the one hand, it produces consistently formatted reports. On the other hand, users who want subtly different information will need to either design their own report or request help from a system administrator to design it for them.
Some LIMS offer ad-hoc reporting to provide more flexibility where a user can develop a report template on the fly. This can be a boon for a savvy user who understands the LIMS data structure, but it can be a frustrating experience for non-technical users. While there is essentially zero risk of LIMS data corruption from ad-hoc reporting, knowledgeable LIMS administrative staff should review the report query to ensure the desired information is being reported.
In most cases, a reporting tool is supplied with your LIMS. Depending on the database engine and the LIMS architecture, the underlying data may also be available for the external tool of your choosing. Many customers use Oracle SQL Developer or Toad to write ad-hoc SQL queries to generate one-off data sets. Advanced customers have hooked their LIMS to third-party analytical tools such as Tableau, Spotfire, Northwest Analytics, and Crystal Reports.
These are pre-configured metric-centric reports that are automatically run on a specific day. They are generally automatically emailed to a small number of recipients. For example, a supervisor may want to track daily, weekly, or monthly lab productivity. The report template might include the number of samples completed by each lab technician. Another example is a list of equipment due for calibration or maintenance within the next 60 days.
Dashboards have become a popular way to visualize LIMS data in recent years. Only your imagination limits the types of information dashboards show.
Tailored role-specific dashboards as a LIMS landing page are in high demand. For example, a manager may see key performance indicators (KPIs) for samples currently in the lab (e.g., how many samples are at each process step). Similarly, a lab technician may see a list of samples ready for processing at their bench. A QA manager’s dashboard can show compliance statistics for stock preparation, equipment calibration, and personnel training.
A common challenge with dashboards is how data-intense they can be. When the data behind a dashboard is derived from many complex records (e.g., statistical analysis of turnaround time over the last 52 weeks), it is generally better to use materialized views to generate the record set. In these cases, the data won’t be real-time. Instead, they will reflect a snapshot of the data when the view was last refreshed.
LIMS at larger companies tend to be connected to other IT systems such as customer relationship management (CRM) and enterprise resource planning (ERP). When the LIMS is the lab’s source of truth, data must emanate from LIMS to these other systems. For example, a clinical lab may use Salesforce or Microsoft Dynamics 365 to separate customer-facing tasks from data-heavy back-end tasks. In that case, as a sample progresses through its lifecycle, LIMS needs to invoke calls to external application programming interfaces (APIs) to supply status updates.
While calling external APIs is the most common method for system-to-system interfacing, message queuing is another way. Oracle Advanced Queuing and Apache Kafka are highly configurable ways to share LIMS data with external consumers reliably.
LIMS may be one part of a much larger data picture. Creating “data lakes” that include LIMS data has become a fashionable way to disrupt the concept of “data silos.” Contribution to these data lakes can be either via “push” (initiated by LIMS) or “pull” (initiated by the external system).
A push from LIMS would be essentially identical to the system-to-system interfacing mentioned above. The structure of the API call’s payload would control the information exchange.
Making flattened LIMS data available for external systems to query via materialized database views is the most common way we’ve seen incorporation into data warehouses. For performance reasons, materialized views are preferred over real-time queries of production data. Since real-time data aren’t typically needed in data warehouses, materialized views can be refreshed during off-hours. Alternatively, depending on the underlying LIMS database technology, a replica could also be used to avoid performance impacts.
Getting more from LIMS data
In summary, there are many ways to extract meaningful data from your LIMS. Choose reporting mechanisms that allow your users to consume the data in a palatable way. No matter if you are using a commercial off-the-shelf (COTS) reporting tool or mining your LIMS via SQL, having a solid understanding of the underlying database schema is the key to successful reporting. Tools like the Data Analytics Solution in SampleManager LIMS software provide a practical way for laboratories across all industries to get more from their data. Want to learn more about the data visualization capabilities available in SampleManager LIMS software? Watch our advancing data visualization in the lab webinar on-demand or read more about the powerful preconfigured dashboards in SampleManager LIMS.
 Lewandowska K, Weisbrot M, Cieloszyk A, Mędrzycka-Dąbrowska W, Krupa S, Ozga D. Impact of Alarm Fatigue on the Work of Nurses in an Intensive Care Environment-A Systematic Review. Int J Environ Res Public Health. 2020 Nov 13;17(22):8409. doi: 10.3390/ijerph17228409. PMID: 33202907; PMCID: PMC7697990.
Leave a Reply