We need to start with a base assumption and that is: the life sciences company is responsible for validating a software solution for its own intended use regardless of where it is deployed.
There seems to be some confusion around this when it comes to SaaS systems and the vendors are contributing to this in order to sell more software. Somewhere along the way, one vendor said their solution was ‘validated’ (hiding the reality in the fine print of a Part 11 white paper) and customers flocked to the solution to avoid doing any validation work themselves. And then the rest of the SaaS vendors felt the need to say the same thing to be competitive.
The reality is that a vendor cannot validate for a customer’s intended use without doing additional work for the customer after the purchase. And this costs both time and money and the customer has to be a part of the process. Vendors don’t generally offer these services, although they may provide deliverables (for a fee) that are generally not tied to a customer’s business processes or intended use.
Well, then, what should this look like to meet compliance requirements and be defendable during an FDA inspection? I am so glad you asked.
Assuming we are talking about a medium to high risk system like CTMS, RIMS, Quality, Electronic Document Management, NCMR/CAPA, Complaints, Manufacturing/Inventory, SAE, etc. the first step is a validation master plan (VMP).
The VMP documents the scope of the system, the risk assessment and justification that drives the validation effort, and the validation effort itself. Validation begins with requirements and ends at system retirement…it is not simply testing. (I will document what is in a VMP in more detail in a separate blog post)
With that being said, the following are the primary (and critical elements) that should be considered with a risk based approach to computer validation(Note: this is for configurable-off-the-shelf without any custom code and assumes that the vendor meets your company requirements and industry best practices):
Vendor audit: if you are going to rely on your vendor for to develop the software and maintain the system (as software as a service) you can’t simply ‘throw it over the fence’ and leave it to the vendor. You have a responsibility to make sure that the vendor is meeting your company’s requirements and industry standards. The vendor audit may result in findings that drive the requirement for additional processes and controls to mitigate risk. I generally recommend that this is done before signing any contracts to make sure the vendor can actually meet the requirements.
Functional requirements: these drive configuration and business processes and are ultimately verified in the Performance Qualification (PQ) testing. This is critical…this is the foundation for all verification activity.
Functional requirement risk assessment: this is an assessment of each requirement that drives level of testing (I generally combine this into the functional requirements specification for ease of maintenance after Go Live).
IT SOPs: standard operating procedures to establish YOUR company’s minimum requirements for validated and business critical systems.
Work instructions and operational SOPs: in order to ensure that there is consistent use of the system to generate reliable data, you need to make sure people are using it in a consistent manner.
Performance Qualification (PQ) protocol: these are the business scenarios with specific tests that verify intended use and functional requirements. The protocol is approved by the validation team prior to execution and executed in a controlled manner by trained users (actual, intended users of the system).
Traceability matrix: this traces the requirements to configuration elements to verification tests (PQ tests) to provide documented evidence that the requirements have been effectively satisfied.
PQ final report: this is a summary of the execution of the PQ protocol and summarizes the results and findings.
Data migration plan: this defines the the way in which data will be migrated into the system whether from paper or electronic records. To rely on the migrated data, there should be a plan, verification, and summary of activities.
Configuration document: this is to establish the baseline for all future change control. I wrote a blog post on the importance of this as memories are short and it is really helpful to remember why decisions were made and what the decisions were.
VMP final report: this is a summary of the validation activities and how they aligned with the original plan. If the FDA comes in for an inspection, and they want to take a look at the validated state of your system (yes, it is yours even if it is offsite), they will start with the VMP final report.
I always leave my clients with an impact assessment template for to be used to simplify and streamline the process when there are updates to the SaaS solution (this happens two to three times a year). Once the system is live, it needs to be maintained and operated in a validated state and that responsibility does not just lie with the vendor. The vendor will introduce changes that could impact your requirements and processes.
The good news for our clients is that we can provide you with assistance with all of this. We have been developing and refining the templates and processes to make it easier for your company to comply with validation requirements as defined in the FDA regulations and GAMP5.
Feel free to reach out if you have any questions on this or if you want to sanity check what your vendor is telling you. Terri.Mead@Solutions2Projects.com or go to our website at Solutions2Projects.com.
Keep in mind that it is generally not in your vendor’s best interest to fully inform you of the true level of effort to validate a SaaS solution in the life sciences space. The vendors are incentivized to minimize the effort to get you to sign on the dotted line. It’s not really their problem but yours: they are not going to be the ones demonstrating data integrity and data reliability for electronic records and signatures subject to 21 CFR Part 11 or used in a regulatory submission; you are. It’s a bit of gamble, and yes, up to each company’s own risk assessment and tolerance. Then again I have to wonder: do you feel lucky, punk?