Implementing a Commercial ELN: 10 Key Steps for UK Labs
Learn how to plan, integrate, and maintain a commercial ELN from our regular Lab Horizons columnist CompSci Cat. This article first appeared in Issue 7 of Lab Horizons digital edition.
Hello dear readers, here we are again. Now lean over, tap your computer three times, and whisper, “I solemnly swear that I want to learn about ELNs,” and I will share my secrets with you. For those of you who are avid readers of the magazine, you may be forgiven for thinking that an article like this has already been written, but fear not—new content is afoot!
Just over a year ago, I wrote about the successful implementation of an open-source, in-house Electronic Lab Notebook (ELN) at the University of Nottingham (which is still exciting and ongoing, so watch this space!). However, much of that previous article focused on choosing an ELN and ensuring it could be embedded in a laboratory—both still very important aspects. Today, I want to concentrate on the next part of the journey: the considerations for implementing a large-scale, commercial ELN across an entire department, and the necessary groundwork before you can start using it. I have broken these down into ten key steps that need to be addressed before, during, and after taking on such an implementation.
1. Staffing Time – “Time will not slow down when something complex lies ahead.”
Now, everyone repeat after me: YOU. CANNOT. DO. THIS. WITHOUT. SIGNIFICANT. STAFF. TIME. If you are under the illusion that you can simply purchase an ELN (or any new software) and have everything magically fall into place, think again. As the rest of this article will demonstrate, implementing an ELN properly requires a significant amount of effort. If you are potentially spending a large sum of money on licences, it is worth protecting that investment by also allocating the staff time needed for the best chance of success.
You need dedicated staff time not only to set up the ELN from a technical perspective but also to liaise with various stakeholders and user groups to establish a cohesive plan. Several different types of staff time will be required: communicating with the vendor about purchasing and support, carrying out development work to set up accounts, roles, and templates, consulting with senior management regarding organisational structures, and, of course, training and on-boarding the people who will use the ELN.
2. Data Exit Strategy – “Never trust anything that stores your data if you can’t see where it keeps it?”
Before agreeing to implement a piece of software, think about your data exit strategy. It might sound pessimistic, but it is simply prudent. What if you decide to leave the platform? What if something goes wrong, and you do not have external copies of your data?
Ideally, you want to set up a process to back up data onto your own storage systems so that your information is not locked in if circumstances change. However, this requires both the technical expertise to extract data from the ELN (for example, via an API) and the know-how to store it securely, with the appropriate access controls.
3. Understanding the Organisational Hierarchy – “We are only as strong as we are united, as weak as we are divided.”
If you are implementing a large-scale ELN, it is important to understand the organisational hierarchy that the system must replicate. Different groups might need distinct functionalities, or they might need to capture different types of experimental data—each requiring its own templates. One major benefit of an ELN is the ability to share work more easily between groups, but that process needs careful planning. Some teams may be working on confidential projects and will need their work siloed just as securely as in a paper lab notebook. Others may need shared notebooks or experiments with the ability to view each other’s data.
In large-scale organisations, there will also be formal processes for signing off and approving work. Many commercial ELNs include this kind of functionality, but it must be configured correctly, which requires a thorough understanding of the organisation’s chain of command.
4. Account Management – “Accounts aren’t created by magic.”
Typically, you need to create user accounts that reflect the organisation’s hierarchy in terms of access and control. In an ideal scenario, you might work with the ELN vendor to enable single sign-on, so the new system integrates seamlessly with your existing user management. Even then, however, there is usually work to do in configuring those accounts in the ELN.
Decision-making processes also come into play. You might choose to provide every user with an account automatically, or you may only grant accounts on request, depending on budgets and team requirements. Either way, when users are created, they must be assigned the correct privileges and given access to relevant areas. There must be a system in place for approval, so someone in an unrelated department cannot simply request a licence.
It is also crucial to plan for what happens when people leave, so their data is reassigned rather than lost in a paper lab book no one can access. Additionally, staff may move within the organisation, changing departments or getting promoted. If someone’s responsibility level changes, they might need a higher level of access to ELN features. Handling these adjustments can range from trivial to very complex, but it will certainly involve some interplay between those making the decisions and those who technically administer the ELN.
5. Integration with Other Systems/Practices – “What is this witchcraft?”
When implementing an ELN, consider how it integrates into the current workflows and mandatory practices in your organisation. A typical health and safety flow might require researchers to create risk assessments and COSHH forms, have them signed off, and then be authorised to carry out lab work. With an ELN in this workflow, you need to decide how these steps connect. Some ELNs have built-in health and safety modules, which must then be configured to match your organisation’s policies; if that functionality does not exist, you must work out an alternative approach.
For instance, you could mandate that all health and safety documentation be uploaded into each experiment’s record, ensuring a formal link between the two. None of this needs to be overly complicated, but it does need to be thought through, documented, and formalised before scientists are let loose on the system.
6. Developing/Making Use of Extended Functionality – “There’s a lot more to ELNs than simply installing them.”
ELNs have evolved considerably over the years. While many early offerings were straightforward ELNs or had basic links to a LIMS (Laboratory Information Management System), current platforms often include much more: Scientific Data Management Systems, inventories, and sample libraries, for example. These can be huge selling points, but setting them up is rarely simple.
That does not mean you should not use them—far from it. However, it does go back to the point in Step 1: these features take staff time. Laboratories do not inventory themselves overnight. If you want to adopt these functionalities, you must plan who will do the work and how it will be organised, so the resources are in place to roll these features out effectively.
7. Templates – “Double, double toil and trouble; fire burn and templates bubble.”
A crucial reminder: converting paper to digital is great, but it does not automatically improve the quality of the data captured. If you are investing in an ELN, it should not merely replicate your paper notebooks; it should enhance the information recorded. We should all aim for FAIRer (Findable, Accessible, Interoperable, and Reusable) data, and a big part of that is capturing the right data at source rather than leaving it in our heads until it is forgotten.
Templates help mitigate this risk. Many ELNs offer template features that can be designed to capture relevant experimental metadata, prompting scientists to provide more detail than a blank sheet of paper might. Setting these templates up requires domain expertise from the scientists themselves—knowing what data is essential—and technical expertise to configure them in the ELN. Again, we come back to the need for staff time from different parts of the organisation.
8. Hardware & Lab Setup – “It matters not what a lab starts as, but what it grows to be.”
As I noted in my previous article, ensuring your labs are properly set up with adequate hardware is key. It would be unwise to spend money on ELN licences and staff training if the laboratory environment itself is not ready. Decide how the ELN will be used—whether scientists will input data directly in the lab or continue using paper notebooks and then transfer information later.
Working directly in the lab can minimise duplication, but requires suitable hardware on the bench. This, in turn, demands appropriate power supplies, reliable Wi-Fi or ethernet connections, and enough physical space to accommodate the devices. All these details should be taken into account before rolling out your ELN.
9. Establishing Support – “Everyone deserves the chance to fly.”
Any large-scale software requires a solid support mechanism, and users should know where to go if they encounter issues. They will lose confidence in the system if problems persist or remain unresolved. Ideally, there should be some first-line technical support within your organisation to deal with straightforward matters—how to use certain features, or ensuring that privileges are set correctly.
For more complex issues, you need a clear path to support from the vendor. The quality of this support should be a priority when deciding which ELN to adopt, as it can determine the long-term success and user satisfaction of your system.
10. Onboarding and Training – “Fear of an unknown ELN increases fear of the ELN itself.”
Adopting any new piece of software can be daunting. It is vital to provide proper on-boarding and training, covering both the software’s functions and how it fits into the organisation’s workflows. Introducing an ELN often prompts changes in other areas; for instance, if it includes an inventory or health and safety functions, these may alter established procedures. Users must understand exactly what is expected of them within the system.
They will also have questions about data storage, accessibility, visibility, and what happens if problems arise. Addressing these queries is essential for building trust and encouraging successful adoption.
Now, this may sound daunting, but remember, to the well-organised laboratory, electronic lab notebooks are but the next great adventure.
Until next time, Mischief Managed!
