search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
LIMS Focus Validating a Laboratory Information Management System (LIMS) Dr Phil Williams, LIMS4U


This article is intended as a concise guide for those looking to validate a LIMS. A fuller paper covering these points in more detail can be requested from the author.


LIMS Validation is important in regulated industries to prove your system operates as intended and meets GxP (Good Laboratory/Manufacturing Practice) regulatory requirements. This imposes specifi c controls and procedures throughout the development and operation of the system as global regulated industries require that LIMS are validated. As a LIMS can be confi gured (using confi guration tools) and/or customised (writing custom code), this part of the lifecycle must be carefully controlled and documented.


For commercial LIMS, the PQ step of system validation is always done by the user organisation at their site, using their system architecture and data. The supplier can help by providing technical resources to implement and validate the system, and by allowing an assessment of the supplier’s quality system.


You can also get help by using Google to search for ‘LIMS Validation consultants’ and by using LinkedIn (try the LIMS4U LinkedIn group which has over 3,700 members, many knowledgeable in validation practices).


• Creation of a Validation Plan (VP) to identify what needs to be validated, who is involved, their responsibilities, and documentation required. A project plan should be created and maintained to log progress.


• Installation Qualifi cation (IQ) to check that the LIMS application has been successfully installed in the specifi ed environment.


• Confi gure (or customise) the system against functional specifi cation. Note that the risk assessment may differ between the two methodologies. GAMP 5 {Ref.1} stipulates confi gurable solutions, whose code does not change during LIMS confi guration, are a lower risk than customised solutions that do write software code to modify functionality. This directly affects the risk and therefore the amount of validation that needs to be performed.


• Operation Qualifi cation (OQ) to verify that the functionality of the software is operationally fi t to be deployed and can be handed over to the laboratory.


• Performance Qualifi cation (PQ) to verify the system performs as expected under real- world conditions. In practice, with Autoscribe Informatics confi gured LIMS solutions, PQ and OQ can be performed in parallel as the underlying modular functionality is already tested before the software is released. By design this is unchanged by confi guration and therefore deemed a lower risk by the risk assessment.


• The creation of a traceability matrix, If needed, to ensure traceability of any regulatory requirements.


• Development of risk-based change control procedures to ensure system re-validation after changes.


• User training and updating of standard operating procedures to include the LIMS.


• Agreement with IT for backup and recovery of data, and planning for disaster recovery should issues occur.


• A Final Validation (FV) report to review all activities undertaken against the validation plan, document any exceptions, and release the system for its intended use.


The fi nal step is customer sign-off and acceptance of the system. Reference


1. https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition GAMP 5 - A Risk-Based Approach to Compliant GxP Computerised Systems


Acknowledgements Figure 1. Validation Process Overview


Validation shows that the LIMS functions as intended. Proving this to the authorities can be crucial during a regulatory audit. Typical steps towards validation include:


• Creation of a User Requirements Specifi cation (URS) to defi ne the operational requirements, and regulatory compliance constraints. The URS helps LIMS vendor selection by defi ning must/should/could have’ requirements.


• Assessment of the supplier’s quality system, and how they develop their software.


• Development of Functional Specifi cations (FS) describing the system features to meet the URS.


• A risk assessment of the system, requirements, and development methodology to assess risk levels and the amount of validation needed to address them.


Thanks to Autoscribe (www.autoscribeinformatics. com) and Dr Bob McDowall (www.rdmcdowall.com) for their help with some of the dialogue used. Diagram modifi ed from an original courtesy of Dr Bob McDowall.


For further information, please email the author Dr Phil Williams at phil@lims4u.co.uk or visit ‘LIMS4U’ on LinkedIn. Phil has over 37 years’ experience in Lab automation. He foundered LIMS4U in 2020 and offers LIMS marketing, primarily via LinkedIn (over 27,000 connections).


Read, Share and Comment on this Article, visit: www.labmate-online.com/article INTERNATIONAL LABMATE - APRIL 2023


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56