Top Tips for Designing and Implementing a Custom LIMS

1 How to Guide A laboratory information management system (LIMS) is one of the key informatics applications for automating or digitalizing a laboratory heavily reliant on paper-based and manual processes. The main tasks within LIMS solutions are sample management through collation, analysis and reporting of results. This guide focuses on the development of a custom LIMS and does not cover any regulations or quality standards. It is intended to be industry-agnostic and focus on the benefits and risks of custom software development. A laboratory should take the principles and learning points here and apply applicable regulations, guidance or standards to adapt the approach to their specific situation. Customize or configure? The terms customize and configure are often confused when referring to LIMS, but can be defined as: • Configure: Turning existing functions on or off within a LIMS application. Involves developing workflows without writing software code. • Customize: Using either a recognized computer language (e.g. C++) or one developed by a supplier to write new LIMS functionality. Custom code can be used to develop modules for commercial LIMS, or a custom system can be developed from first principles. The assumption made in this guide is that a commercial LIMS is being customized rather than developing a system from scratch. How to decide if a custom LIMS is the right choice for your lab Commercial LIMS have been available for over 40 years and have been implemented in many industries, covering many different regulations, guidelines and quality standards. Custom software is often regarded as the highest-risk software. The organization that implements custom software is solely responsible for its maintenance and update to ensure it remains operational. A flowchart to assess whether a custom LIMS can be justified for a laboratory is shown in Figure 1. Top Tips for Designing and Implementing a Custom LIMS Bob McDowall, PhD TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 2 How to Guide Figure 1. The process to assess if a custom LIMS can be justified for a laboratory. Credit: Bob McDowall When assessing if a custom LIMS is justified, consider the following: 1. Why is a commercial LIMS not adequate for your laboratory? The organization must conduct due diligence to document why a commercial system is not suitable by evaluating several suppliers’ products. The answer will depend on the work performed by the laboratory (and by extension the organization) and the processes to be automated. The laboratory’s user requirements specification (URS) will be used to assess several commercial LIMS and suppliers and identify gaps in the applications. Do any or none fit? Why? Is the rationale for a custom system big company ego? For example, there are only two ways to work: our way and the wrong way? A report detailing why commercial systems are not adequate must be prepared as this is an essential input to justify to senior management the need for a custom solution. TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 3 How to Guide 2. Should the LIMS fit the laboratory, or the laboratory fit the LIMS? Implementing any informatics application will result in a change in working practices. It’s important to consider if redesigning business processes could permit the use of a commercial system consistent with meeting the laboratory’s business objectives. I strongly recommend mapping your as-is processes and problem-solving to prepare for digitalization before any LIMS implementation. This approach identifies and understands the reasons for bottlenecks, where paper records are generated and the use of spreadsheets and manual processes. Then redesign the process to eliminate them when defining your digitalized to-be processes. In addition, gather metrics for both the as-is and to-be processes in terms of time savings and efficiencies. The former will be based on actual data and the latter will be based on estimated figures. Both will be used to calculate cost savings in the laboratory and the organization in terms of earlier product releases. 3. Revisit the LIMS assessment report Check if the redesigned process would allow the use of a commercial LIMS with configuration. This approach would be faster to implement and more robust compared to a custom solution, as the support would be provided by the LIMS supplier. If a configured commercial LIMS is now a viable option, the process moves to step 4 in Figure 1. Any LIMS (standard, configured or custom) will entail changes in laboratory working practices, impacting all staff inside and outside the laboratory. Involvement of staff at all levels is mandatory and critical, after all, they are the ones doing the work. Choosing a custom solution doesn’t come lightly, and the next step is convincing senior management who needs to be able to fund the initial development and ongoing support of the LIMS. Convincing senior management Senior management will not consider the development of a custom LIMS unless there are substantial business benefits to be obtained. The key components of the business case are shown in Figure 2 and discussed below: Figure 2. Key components of a business case for custom LIMS development. Credit: Bob McDowall TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 4 How to Guide Justification for a custom LIMS • LIMS assessment report This must include why a commercial system is not adequate and will be supported by the LIMS assessment report. Due diligence must have been performed – how many commercial systems have been evaluated and why were they rejected? • Process redesign savings to offset project cost Process redesign should generate quantifiable business benefits both within the laboratory and within the organization. For example, if the laboratory can release a product batch a day earlier with the redesigned process, what is the annual impact of all batches released one day faster on the company cash flow? • Total project cost The cost-benefit analysis must be accurate and include the contingency for inevitable time and cost overruns in developing custom software. From experience, you won’t get everything right the first time and you’ll need to correct the software mistakes later as well as add additional functionality for the future. Project management • Project manager Ideally, the project manager is from the laboratory as this sends a direct message that the LIMS is being developed for the analysts. • Identify and train laboratory administrators Although process redesign will result in more efficient processes, management may be tempted to cut staff. Don’t. As extra capacity frees up staff, some will transition to become LIMS administrators setting up methods, custom calculations and reports, they are also the first line of help in the lab. Failing to identify potential staff to fill this role in the planning stages of the project will result in problems later. • Involvement of analytical staff Input from the staff in the specification, prototyping and testing of the custom system is critical from the onset. This ensures that the LIMS will meet user expectations. However, this comes at the cost of taking analysts out of the lab to work on the LIMS and must be budgeted for. A decision needs to be taken if temporary staff should be engaged to backfill positions to ensure any current work is unaffected. This is the same for a commercial system as well as a custom LIMS. Custom software development • Who will write the software? Will the software be written in-house, by the LIMS supplier or by an external software company? Furthermore, who will review, document, understand and maintain the code? In-house has the advantage that the development is under the direct control of the organization and will probably be cheaper than using an external supplier. However, this depends on whether you have the personnel available and the level of their technical expertise. TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 5 How to Guide • Time to develop the system A custom system will take longer to specify, develop and test than implementing a commercial system. This must be managed carefully to keep lab staff involved in the project. The best way is to keep them informed of progress and demonstrate new functions early to gain feedback. The late Ray Dessy said if analysts don’t ask for improvements the staff are putting up with the system rather than wanting the LIMS to succeed. Time (and cost) overruns are common in custom software development; therefore, the project plan and budget need to be regularly reviewed. If the project and resources are approved, then the work can begin. However, there are risks you need to be aware of. Custom project risk warnings A custom LIMS has the potential to be one of Edward Yourdon’s “death march” projects where project parameters exceed the norm by at least 50%.1 This is especially so if the proposal for the project has been overly optimistic rather than realistic. Furthermore, in Crash, a book that discusses the world’s worst computer disasters, one of the top ten causes of disaster is, “an avoidance of cheap, proven, off-the-shelf, packages in favor of costly, unproven, custom-built software; or, worse, tailoring of a standard package.”2 The next section further explores the project risks of customized LIMS in more detail. Number one in a field of one Option 1: Complete custom LIMS A complete custom LIMS is unique to your laboratory and no other; the system must be supported and enhanced by your organization. There will be no external support for your custom system. This means: • No supplier enhancements • No new functionality • No technology updates • No bug fixes • All ongoing support and functional enhancement must be planned and budgeted in advance Option 2: Customized commercial LIMS Taking commercial LIMS and developing custom code to meet your requirements has two levels of support. Your custom code will be unique, and this comes with the same caveats as described in Option 1. In addition, you will have supplier support for the commercial LIMS, e.g., software updates, bug fixes, etc. However, there could be changes to the commercial LIMS application that may result in your custom software not functioning as before. Most LIMS suppliers provide connections for custom code extensions. This is the most likely way to ensure that custom functionality continues to operate correctly. However, support and enhancement of your custom code is your organization’s responsibility and this also needs to be budgeted for along with the commercial LIMS support contract. TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 6 How to Guide Managing custom software development, testing and release Your custom software needs to be written either in-house (if you have the staff for this) or by an external company. To ensure success, you need to ask the following questions: • What expertise do the developers have in developing custom software for your LIMS? • Are the developers familiar with your laboratory? • Do they have expertise in the software language to be used? • Have they done similar custom projects before? For external software houses, are there references they are willing for you to contact and discuss their work? • Do they have staff that can be permanently allocated to your project so that there is a good understanding between the lab and developers? Will the developers be working on other projects? • Where are the locations of the development team and the laboratory? Distance and time differences can hinder communication. • What are the costs for the development and testing? In-house development probably means that much of the cost could be hidden. External costs are much more visible for accountants and senior management to monitor. • How can you ensure you can manage the change and keep the users, and the business engaged and invested throughout the project? • Can your infrastructure support mitigating any security, backup and recovery risks? • Have you got the resources/agreements for managing changes, enhancements and bugs once the system is released into operational use? • Are you replacing a current LIMS system and is there a need to migrate data? • Do you have resources to support the migration of data to ensure it remains integral, complete, accurate and attributable? • After going live, you will still need access to the development environment(s) as there will be functions that need to be corrected, others enhanced, bugs to be fixed and building functions that should have been in the release but were forgotten. This applies regardless of in-house or external software development. Writing the custom software Here, I assume that Option 2 (customization of a commercial system) has been chosen: the selected system cannot function effectively without the additional custom modules. We’ll also assume that all laboratory processes have been redesigned for digitalization: paper is eliminated, spreadsheet calculations are TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 7 How to Guide integrated into the LIMS or an interfaced application, analytical instruments and systems are interfaced on a priority basis and data is transferred electronically between systems to avoid manual data entry and associated transcription errors. The additional custom modules provide additional functionality and must be carefully integrated with the commercial system. This involves mapping custom functionality onto the commercial LIMS and planning those connections. The challenge then becomes how to develop, test and integrate the custom modules into the commercial LIMS. Agile software development There are various software development methodologies available e.g., V model, waterfall and Agile. The methodology most likely to be used will be Agile. This methodology aims to develop, test and integrate usable code in two- to three-week sprints. Project management tools such as Jira, DevOps or YouTrack are used to manage the software development and testing process. Records of the software development and testing will be maintained in the tool rather than in formal documents. A wiki or document management tool may also be used for communication between the lab and the development teams to refine concepts and give feedback during the project. At suitable points the software must be shown to users for their evaluation and feedback; it will also feed into user acceptance testing against updated and current user requirements. Do’s and don’ts for LIMS projects The following advice is offered for any LIMS project: • Don’t ignore regulations, standards and applicable procedures • Do automate a business process from beginning to end • Don’t automate a partial process • Don’t automate a silo • Don’t forget to interface analytical instruments and systems • Do prototype LIMS processes • Don’t ignore user feedback • Don’t forget database population Case study: The importance of communication Below is a case study of a custom LIMS project, highlighting the importance of communication during the process. TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 8 How to Guide A bioanalytical laboratory required a LIMS to automate its laboratory operations. While commercial systems were sample-driven (single sample with multiple tests), the laboratory required a protocol-driven system (handling few tests but multiple samples from multiple subjects). The LIMS supplier selected agreed to undertake the customization, partly to offer the software to other potential customers. The laboratory URS used as part of system selection was further developed into a functional specification, which guided the software development including interfacing of analytical balances and CDS. Although communication between the business analyst and laboratory was excellent, there were no discussions with the software programmers due to the geographical separation between the laboratory and the suppliers. Consequently, when the system was delivered, several issues became apparent: • Inadequate specification by the laboratory • Interpretation of the functional specification by software developers without reference to the laboratory • There was no prototyping of functionality which did not permit effective user evaluation until the first version of the complete system was delivered. • The laboratory could not demonstrate the system to users until the customization was delivered, resulting in very critical feedback for some functions • Changes in the way the laboratory operated between selection and delivery resulted in temporary work arounds until functionality was updated with repeated retaining of staff. • The cost of changes outside of the initial contract were unbudgeted at first • The custom system took over 18 months of development, with further development required after the initial release to resolve the main functionality problems. Key learning points Key requirements for a custom project to succeed include an excellent business case, long-term senior management support and deep resources (both in people and money) as well as the following: • Clear and detailed specifications and process maps. • Requirements: Should be 25 words or less. • Maintain open communication between all stakeholders. • Prototyping new processes and listening to user feedback. • Be prepared to adapt and plan for changes and implement potential workarounds. • Be realistic with time and budget planning. • Encourage management to be flexible when redesigning processes. • Ensure management support. TOP TIPS FOR DESIGNING AND IMPLEMENTING A CUSTOM LIMS 9 How to Guide Acknowledgements I would like to thank Gemma Harben, John English, Mahboubeh Lotfinia and Monika Andraos for their constructive review comments to improve this listicle. Sponsored by References 1. Yourdon E, Death March. 2nd ed. Upper Saddle River, NJ: Yourdon Press/ Prentice Hall Education Professional Technical Reference. 2004. 2. Collins T, Bicknell D, Crash: Learning from the World's Worst Computer Disasters. London: Simon & Schuster.1998 About the Author: Bob is an analytical chemist with over 50 years’ experience, including 15 years working in the pharmaceutical industry and over 30 years working for the industry as a consultant. Bob has been involved with process redesign, specifying and implementing laboratory informatics solutions for over 40 years and has nearly 35 years’ experience of computerized system validation in regulated GXP environments.