What’s in Your Vendor Validation Kit?

When deciding to make the purchase of a computerized system for your lab, it is important to know which areas require compliance. Testing of a laboratory informatics system (LIMS, ELN, CDS, SDMS), that is required to be compliant, is mandatory. Vendors supply their systems with appropriate validation documentation that is, in part, a basic outline of the functionality of the system. The validation package will consist of a varying degree of documentation, which includes testing around that basic functionality.

When purchasing this validation package from the vendor, it is important to know what to expect from both the vendor and of your organization to ensure that your validation package is complete.  The proper vendor documentation can reduce your validation burden by providing you with objective evidence; including IQ/OQ test scripts, requirements documents, and validation reports.

Documentation from a Vendor Validation Package

Validating a computer system is the process of demonstrating that the system has met a defined set of requirements. This will include the process of gathering requirements not only for the configuration of the system but the functionality as well. Below is an example list of what you may expect to receive from a vendor for a purchased computer system:

• Design Specification/ Configuration Specification
  • The design specification is meant to describe how the system is built, to identify minimum software and hardware requirements, and to document how the system must be configured to meet user and functional requirements. This document could include a high level overview of the software components and network requirements that the system will utilize. A hardware architectural overview should be included as well to provide a description of the physical components of the system that may include PCs, servers, the network, and any other devices used by the system.
• Functional Requirements Specification
  • The functional requirements specification will document the operations and activities that a system must be able to perform, based on how it was developed. This could include such requirements around how data is to be entered into the system, descriptions of operations performed by individual modules, descriptions of the system’s workflows, descriptions of system reports, as well as access to the system. It is important to understand that the functional requirements will be intended for general business use and that not all provided requirements may need to be tested based on your user requirements.
• Installation Qualification
  • The installation qualification document will verify that the proper installation and configuration of the system has been followed. It will verify the specifications identified in the Design Specification and/or Configuration Specification. This can include testing to ensure that necessary files have been loaded, equipment has been set up and connected correctly, and that pertinent procedures have been approved.
• Operational Qualification
  • The operational qualification provides documented evidence that the requirements identified in the Functional Requirements Specification have been tested.  It is a collection of test cases that are used to verify the proper functioning of the system. Each test case in the Operational Qualification should include an instruction, an expected result, and an actual result with an indication of pass or fail.

Documentation to be Created to Supplement a Vendor Validation Package

Even while focusing on best practices regarding validation activities, it is impossible for vendor documentation to provide truly turn-key performance as their documentation is designed to support, test and verify the system as the developed it, rather than how any specific customer intends to use it.  End user testing still needs to be performed to confirm that the system meets all requirements from the user requirements specification, a customer-specific document. While the vendor will supply documentation around validating the system in its out-of-box, non-configured format, it is still important to make sure that you have documented any needs around your business structure. This will ensure that you are providing a robust validation of your system to make sure you are compliant. These documents include the following at a minimum.

• Validation Plan
  • The validation plan may include procedures that are specific to your company regarding validation activities. It should provide a brief overview of the system, identify the required deliverables of the validation project and identify the individuals responsible for each deliverable. It will also define acceptance of the validated system and how to handle any deviations that may arise.
• Risk Assessment
  • While some may see this as an optional document, it is important to identify potential business and compliance risks associated with the computer system. It can help to define the criticality of certain risks and the probability of occurrence. Risk Assessments help streamline the validation process by identifying more critical risks first.
• User Requirement Specification
  • The User Requirement Specification (URS) will describe the business need for what your users will require from the system. The URS is generally created early in the validation process (even before purchase) to allow for planning of the system needed. This specification can include requirements around, workflows, data needs, life cycle maintenance, and user access based on your internal processes and procedures.
• Performance Qualification
  • The Performance Qualification demonstrates that the system meets the user requirements that have been defined for your business needs in the URS. It should be written using simulated real-world conditions.
• Traceability Matrix
  • This document will link all requirements to their respective test cases. The purpose of this document is to ensure that all the requirements that have been defined in the specifications have been tested. This is a way to track the testing throughout the validation process.
• Validation Summary Report
  • This document will provide an overview of the entire validation project once it has been executed. This report will include a description of the validation project, all of the test cases performed, any deviations that occurred during the testing process, and how those deviations were resolved. It may also describe how the system will be released for use.

While vendors do supply documentation around the validation of their systems, it is important to remember that your business needs and procedures will need to be incorporated and documented. Remember that the responsibility of a validated informatics system ultimately falls on YOU, not the vendor. Validated systems must be periodically reviewed to maintain your validated state and all changes to the system must be documented in addition to any vendor documentation that you have. If you are prepared and follow some of the basic practices you can be assured that readiness goes a long way to guarantee a successful validation project.

If you find yourself undertaking a validation project your organization should ask questions that gauge your knowledge of the process. Do you understand the needs of your users when trying to decide which system to purchase? Do you know which documents the vendor will provide and the gaps you will need to address? Do you know how to author validation documents or even which are needed for your industry practices? If so, how would you describe your knowledge around performing validation procedures? Please share your comments in the space below.