Driving efficiency in lab workflow planning

In the first of a two-part interview, SmartLab Digital 2020 presenter Unjulie Bhanot, Solution Owner (Biologics Development) at IDBS, discusses the struggles of finding adaptable and multipurpose technology for the modern lab, the challenges raised by digitalization at scale and how software can help improve the working environment of a lab.

Pharma IQ: What major trend stood out to you in respect to digitalization at scale in 2019?

Unjulie Bhanot: Only a few years ago, people within the industry were looking to shift from the paper to the glass paradigm using tools such as ELNs. Now, the same community is moving beyond that shift toward transformational digital systems and are looking at software landscapes in a more holistic way. Through system integration, they are really starting to piece together the flow of the process and the flow of data, and they are no longer looking to simply replace like for like.

Pharma IQ: In respect to systems integration, a major complaint from within the industry is that nothing works as expected and systems fail to connect or talk to one another – what are your thoughts on the issue?

Bhanot: The pharma industry is behind other industries with respect to technology, as the technology we use in the lab was not designed with integration in mind – ­­instruments were standalone and created to serve the purpose they were built for.

We know that organizations can buy instruments and systems on a whim, because it works for their project or molecule, and it doesn’t always then serve a purpose afterwards. There is also the issue that when a drug has been filed and patented, the instruments used in its creation are referenced in the documentation, so changing those instruments to a newer version becomes more difficult. It’s a historical problem which people within the industry have been trying to solve by finding newer technologies.

Pharma IQ: What recommendations do you have to help unpick the problem?

Bhanot: When you look at it from an end-user perspective you need to think about deploying a platform that can bring together lots of parts of the daily life of a lab scientist, going beyond the recording of data and looking at the systems they are touching throughout the whole day.

As scientists complete their experiments, they need to consider things like whether they need to go to an inventory system, do they need to go to a sample management system, do they need to log reagent usage etc.  They need to consider how many instruments will be utilized and think about a platform that can bring all that data together. That is what will drive efficiency as it will ensure they’re not going to have to go back and forth between different systems to complete routine tasks.

Also, some of the newer labs are more open to trying new and different instruments – especially the labs more focused on R&D. If a large pharma has an R&D arm and they’re willing to spend on getting it right in R&D, it can translate across early and later development.

As with software, different groups within a large pharma will deploy solutions that work for them in order to solve their immediate needs. But they first need a strategy which looks at the problem top-down so that they can begin to lay the foundations to get that data flow right and ensure the data integrity is built in from the word go, rather than thinking about it when you’re ready to transfer into manufacturing.

Pharma IQ: In respect to workflow planning, what should companies keep in mind when they are looking for software to match the needs of the scientist, and not just the project?

Bhanot: You need to think about what a lab scientist is handling in their daily life and how are they capturing their data, sharing their data, and managing the instruments, inventory and samples they’re working with. Systems may not always talk to each other, so you still need human intervention to manage these interactions.

Also, you need to consider how that work is being scheduled; whether or not you’re working with different teams within the same organization or different teams across others; and how you want the data to get back to you. With respect to data, do you want it to be captured in a certain way that is easy for you to trend on or report out if you’re outsourcing?

Ideally, you’d have systems in place that can start to bring together your samples, instruments, your people as resources and your experiments type, scheduling it together rather than having somebody responsible for each of those facets.

Pharma IQ: How can software be used to make the lab a better environment for scientists to work in?

Bhanot: Software needs to be designed with the end-user’s workspace in mind. They are more likely to be using software in the lab on a tablet, than behind a computer at a desk, so it’s important to keep in mind that screens may be smaller, space may be limited and scientists may be more likely to be using a stylus than a mouse.

Also, getting people to move from paper to digital means you cannot simply replicate processes like for like. You have to think about whether you are going to save people time or cost them more – especially if they will say that it’s easier to carry out a particular task on paper. The cons to paper can be compromises in data integrity, and ultimately that can cost even more time and effort on behalf of the organization. Essentially, the software needs to be designed to make it easier for the end user to use without creating longer or more complicated processes.

Pharma IQ: Have you seen any of these approaches work in practice?

Bhanot: For one of the customers we worked with, the deployment of our system helped manage their lab ergonomics. It allowed them to rearrange tasks and items in the lab so that it became easier to use an electronic system.

In the old paradigm, you’re not integrating existing instruments and systems with paper, as you’re always going to be manually transcribing data from one system to another. But having a digital platform which can pick data up automatically, and which you can push or pull data to, means you can consider how you’re laying out your lab to capitalize on this functionality.