LabWare LIMS Validation

Written by Kimberly Stanton - Associate, Validation Manager

As with all LIMS applications implemented in regulated environments, LabWare LIMS implementations must go through Validation prior to being released for routine use. LabWare implementations present unique challenges due to the ability for companies to create complex static data and work-flows, configure many different Sample Types, manage Standard/Reagents, manage Equipment/Instruments and the ability implement Stability Studies.

A Validation Plan for any LIMS implementation must be created to detail the Purpose, Scope, Deliverables, Responsibilities and the Acceptance Criteria to release the new LIMS application in the Production environment for routine use. If the LIMS application is to be installed in multiple sites with different hardware and potentially different requirements due different regulatory constraints or business work-flows it maybe necessary to create more then one Validation Plan.

User Requirements for a LabWare LIMS application should document the following to ensure a smoother implementation and Validation effort: 

• All applicable Regulatory requirements 
• System Administration requirements 
• Multiple Site requirements if applicable 
• Laboratories that will be utilizing the new LIMS application 
• User Roles that will need to be implemented 
• All Sample Types that will need to be implemented 
• Work-flows to include Lots, Samples, Projects, Batches and Stability as applicable 
• Test Methods functionality must be documented, however, since the amount of Test  Methods that will need to be documented will vary, the use of an Appendix to the URS or a reference to Data Migration plan may be considered  
• Product Specification functionality must also be documented and similar to Test Methods mentioned above if there are many Product Specifications to be implemented an Appendix or Data Migration plan reference may be considered 
• Reports to include Certificate of Analysis, Standard and Reagents, Stability Results, and any other applicable reports 
• Any Interface requirements such as Instruments, SAP, TrackWise, etc. 
• Standard Operating Procedures applicable to the LIMS implementation

A Risk Assement(s) should be created to determine the Risk Level of the Requirements documented for the LIMS application. Risk Levels will help determine the level of testing that will need to be performed, Standard Operating Procedures that should be created and the level of Training that should be conducted. For example if there is Requirement that has a high Impact if it fails, high Probability that it will fail (mainly if it is a configured or customized part of the application) and Data Integrity could be impacted if the Requirement fails, testing activities would include Unit Testing, Operational Testing and Performance Testing. A corrective action for this Requirement could be User Training and Standard Operating Procedure development. If a Requirement is considered less of Risk if it fails, for example a core part of the LIMS application that satisfies the Requirement, testing may not even be necessary if the company implementing the application is satisfied with the level of testing LabWare performs on their core product, this would be verified during a Vendor Audit or minimal testing in the Operational Testing could be conducted.

Considerations regarding how to document Design/Configuration Specifications should be planned, since the complexity of a LabWare implementation can vary it may be helpful to create multiple Design/Configuration Specifications. For example a separate Design/Configuration Specifications for System Administration, Material Management, Lot Manager, Batch Manager, Project Manager, Sample Manager, Stability Manager and any applicable Interface functionality maybe a good approach. This approach will need special attention from the Project Manager since managing multiple documents can be very difficult.

One of the most overlooked pieces of a LabWare implementation is Static Data planning, configuration, verification and process testing. Static Data, depending on the Data’s complexity can be as or sometimes more complicated then the software piece of the LabWare implementation.

A Data Migration plan is key to Static Data planning, the plan should include references to all of the Static Data that will be implemented into LabWare, the instance (environment of the application) the Data will be configured in, how the configuration of the Static Data will be documented (separate Design Spec to include LIMS Basic Code design) and how the Data will be verified prior to being imported into the Validation (and Training environment if applicable) environment.

As with other LIMS and regulated applications implementation there should be multiple instances (environments) of the application one for software development, one for Static Data development, one for Validation testing, and the Production environment. It is also recommended that a Training environment is available, the Training environment should include verified Static Data for the new Users to train with. If it is not possible to obtain a Training environment one of the Development environments can be used as the Training environment as long as verified Data is available and software developments/updates are not taking place during training sessions.

The Validation and Production environments must go through an Installation Qualification. It is not required that the Development or Training environments go through an Installation Qualification, however, there must be adequate controls in place that ensures that any software changes or Static Data updates are implemented into all of the environments that are not required to go through IQ verification.

Since LabWare implementations can be very ‘data centric’ careful consideration must be made regarding what Static Data will be used during testing, if the Static Data has not been setup correctly any testing conducted has a potential of failing due to the Data. For example say a Product Specification that has Test Method that cannot be completed unless the Sample the Test Method is associated to is added to a Batch and the Quality Control Samples are not properly configured in the Batch Protocol has been selected for testing, the Sample will never be able to be Reviewed or Approved and the Lot the Sample is associated to cannot be approved if the Sample is not Approved the testing will fail.

Also, careful considerations on Requirements that may require special Static Data setup must be made. If a script requires the tester to verify that a Result entered on a Component of Test Method can be canceled, the Test Method selected for testing must have ‘Allow for Cancel’ option selected in order for the Result(s) to be canceled. If the configuration of the Static Data is not correct the script will fail.

Prior to formal Validation testing informal Unit Testing maybe considered, informal testing can minimize deviations either caused by system inconsistencies (nice way of saying Bug) or script errors. The Unit Testing can be conducted with Operational Qualification scripts created by the Validation team. This also provides the testers the opportunity to learn the system and become familiar with Test scripts that will be executed during the Operational Qualification.

The Operational Qualification testing phase for a LabWare implementation should include functional and negative testing much like any other Validation project, however, a LIMS OQ can be a large undertaking due to the complexity of the configurations of the Software and Static data, therefore, multiple testers (preferably from different Labs) should be used to reduce the amount of time it takes to execute OQ test scripts. Since the training of the testers on the new LabWare application maybe limited it is important for the OQ scripts to be created using a ‘point and click’ methodology, this will make the execution effort easier for the testers.

User Training must be conducted prior to the Performance Qualification testing phase of the LabWare implementation. Training tailored to the individual Labs may help be a better alternative as oppose to large Training sessions that include all users. Since the Labs using the new LIMS application will have different access to functionality of the system an overall Training session may confuse Users. For example let’s say if one Lab will primarily do their work in the Batch Manager and they do not have access to Lot Manager, Training on Lot Manager will be lost on them.

Performance Qualification testing can either be conducted in a simulated Production environment of the LabWare application or in a live Production environment depending on the confidence level of the implementation. If the Performance Qualification is conducted in a simulated Production environment it recommended that Performance Monitoring testing phase is conducted once the application is considered approved for routine use. Critical business/regulatory processes and Products/Testing for all Laboratories involved with the new LabWare application should be included in any Performance Qualification testing phase to ensure the new LIMS application is meeting all business and regulatory needs.

A Traceability Matrix is recommended to ensure testing coverage, corrective actions for non testable requirements and/or reasoning for lack of testing for all User Requirements documented for the LabWare LIMS implementation. The Traceability Matrix will also trace Configuration Requirements and possibly Standard Operating Procedures where system Configuration Requirements cannot satisfy a User Requirement.

There are many points to consider when implementing a LabWare LIMS application; this blog just highlights some of major components to ensure a successful implementation. We sincerely hope that the information presented is helpful.