As laboratorians, we all encounter situations where we must undertake highly repetitive manual tasks—whether it be related to the accessioning process, specimen processing, data transfer between devices in a multidevice process, interpretation, quality monitoring, or report production.

Often, we can define our processes, but we don’t have a way to programmatically automate these tasks easily, so we resort to cutting and pasting data into a spreadsheet or manually extracting data and preparing the same report month after month. Another complication is that lab processes tend to be context and institution-specific; there is no off-the-shelf commercial software for our niche clinical environment.

In principle, we understand that software development for these tasks would be achievable if there were sufficient budget and time, but usually there isn’t. There is also the hassle of the back and forth with programmers to help them understand laboratory processes. Sometimes, it’s just easier to do it yourself, but most of us are only aware of Excel macros as a tool to achieving this end.

An Explosion in Open Source

Fortunately, in the last 10 years, there has been an explosion of open-source (i.e., free) data science and data analytics tools specifically designed to help users rapidly develop web-based applications to take care of their software needs, simple and complex alike.

At the present time, it’s fair to say that the most mature open-source tool for the development and deployment of a web-based custom software application is the Shiny package for the R programming environment. There are a number of excellent alternatives from the open-source community, such as Dash for the Python language or even leveraging a Jupyter notebook.

Institutions can achieve similar goals if they already have a Tableau or Microsoft BI license, but these commercial, closed-source software tools are expensive.

Don’t Fear the Jargon

To explain a bit more, Shiny is a tool in the R language that allows users to create an application that runs in the web browser without the installation of the R language on the computer of the end user.

Shiny takes the pain out of creating interactive, reactive websites, allowing the programming to happen directly from the R language so that any calculations or manipulations can be made on the data using R code. The interactive graphical output can likewise come from the same R code.

A user can then deploy the application on a single device, onto an on-premises server, onto a cloud-based server such as Amazon Web Services or Microsoft Azure, or even onto RStudio’s cloud. The choice of how to deploy an app depends on the number of users, where users will access the app, the computational power available, the sensitivity of the data, the need for password authentication, and other considerations.

In any case, these are details that can be worked out after building something that suits the lab’s needs.

What Can You Actually Do?

In my laboratory at St. Paul’s Hospital in Vancouver, British Columbia, Canada, we have used R applications (without a web interface) and R Shiny (with a web interface) to tackle our rapid software development needs.

For example, we have a quality control (QC) review app which taps a structured query language (SQL) database of our QC results for all instruments connected to our laboratory information system (LIS). This permits us to either produce PDF reports for all QC materials on all devices at once or to select which QC we want to see and view it onscreen interactively.

We have also undertaken several data automation tasks such as the connectivity of our liquid handlers, RNA/DNA extractors, thermocyclers, and the LIS to make interdevice data transfer and results review/release of our virology molecular tests free of human transcription. This software also handled and tracked SARS-CoV-2 samples that were pooled to increase our throughput in the fall of 2020 when there were reagent shortages for some of the high-volume automated systems.

We have also produced a color-coded dashboard that that displays which pending samples are nearing their target turnaround time and may need intervention on a core lab TV screen. Additionally, our outpatient requisition scanning and storage is run using R in combination with a number of other open-source tools that interpret requisition barcodes and store the PDFs in a retrievable manner.

Hazards and Pitfalls

A warning: When building software for others to use, the developer becomes the de facto fallback person when there is an unexpected problem—and there always is.

For example, power outages can occur, or the app may stop working when updating to a new version of R or Python, or if the formatting of the input data unexpectedly changes. If you are the code author, and your lab develops dependence on the tool, then it’s best to make sure that there are contingencies and fallback strategies when you are unavailable.

This is why, when there are larger user bases, it’s recommended that the app be maintained by a team of people who can troubleshoot if there is a problem.

The Final Product

The initial learning curve for learning a scripting language may be tough, but through practice and determination, you can become proficient and see opportunities to streamline workflows in your laboratory. And, as a bonus, people will thank you for getting rid of those repetitive, mundane, and error-prone tasks.

Daniel T. Holmes, MD, FRCPC, is a clinical professor in the department of pathology and laboratory medicine at the University of British Columbia and Head and Medical Director of Providence Health Department of Pathology and Laboratory Medicine in Vancouver, British Columbia, Canada. Email: [email protected]