Validation for Cloud Software

Why Choose Cloud?

You may have heard the benefits of cloud systems. They are the way of the future. They are the way of the present. When was the last time you received an updated version of software in the mail? Have you ever noticed when Amazon released an updated version of its software? That has all been replaced with cloud solutions. Why are businesses choosing cloud for their enterprise systems? Here are the classic benefits of multi-tenant cloud systems.

• Less expensive—no major hardware investments
• Easier to maintain—the software vendor does the upgrades
• More secure—the data centers that power the cloud are tightly controlled
• More reliable—the data run documented backup protocols and systems redundancies
• More versatile—you can run these programs from many platforms like tablets, phones, smart TVs around the globe
• Scalable—you can scale your users and computing power up or down as needed

If your company is ready to invest in enterprise software, why wouldn’t you choose a cloud system?

• Less control—the software company manages the software and hardware
• Validation—for life sciences companies, validating cloud systems seems challenging

Definitions: Cloud and SaaS

This article discusses how to mitigate risk when selecting a cloud vendor and how to validate a cloud system along with the benefits of the cloud approach. Let’s define cloud computing and SaaS software, which are often used interchangeably, but are not the same.

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

Ref: NIST SP 800-145 The NIST Definition of Cloud Computing

Within cloud computing, there are three service models: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). This article addresses SaaS offerings.

“Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.”

Ref: NIST SP 800-145 The NIST Definition of Cloud Computing

Among the three services, SaaS is where the customer subscribes to use the software; they do not own the software.

Not all cloud solutions are SaaS. An IaaS customer can run their copy or version of software hosted on cloud infrastructure, but they are still responsible for upgrades and patches. In this model, each customer could use a unique version of the software simultaneously. This increases support costs to the software vendor, which translates into higher maintenance costs for the customer. And the customer may decide to stay on an old version, so they don’t get the benefits they pay for with their maintenance agreement.

The SaaS model is less expensive to buy and significantly less to manage. The risk is that the SaaS company can upgrade your software, even change the user interface or functionality, on their schedule. In a highly regulated industry like life sciences, this means the system you validated has changed out from under you. So, the SaaS vendor must keep you informed of new releases and updates coming down the line.

Mitigate Risk in Your Buying Process

The relationship between the cloud software vendor and client differs from that of an on-premises software vendor. Because the vendor is controlling the hardware and software of the solution, you need to trust that they will manage the software configuration transparently. To be confident in their ability to support your business needs, make these elements a part of your review:

• Master Service Agreements (MSAs) clearly written to include uptime, backup and recovery practices, system redundancies, and security
• Third-party certifications, like System and Organization Controls (SOC) compliance, which includes inspection of facilities to make sure they are operating to industry standards
• Customer references with business requirements like yours
• Validation program: the process, the coverage, and the service

IQ and OQ for Cloud Software

Validating a cloud software system is a partnership between you and the SaaS vendor, starting in the buying process. The buying process starts with your business needs. Life sciences companies must include the ability to validate the system according to FDA 21 CFR 820.70 (g) Equipment and (i) Automated Processes. For several years, the FDA and regulated industries have understood and defined software validation within the context of process validation. Process validation has three parts: IQ (installation qualification), OQ (operational qualification), and PQ (performance qualification).

To make the shortlist at a life sciences company, the software company must have a clear validation strategy as well as the processes and documentation to support it.

Cloud IQ

Let’s start with IQ, “installation qualification.”

IQ testing demonstrates and confirms that the cloud software is installed according to approved specifications. Do make sure the software company has an installation qualification (IQ) validation protocol and that the customer can access the results of the tests in the protocol. The SaaS vendor should also provide documentation on the redundant network and server infrastructure, its security architecture, its backup/disaster recovery mechanisms, and procedures. As a cloud software customer, it’s your responsibility to verify and trust that the software vendor’s IQ and OQ documentation will be acceptable to FDA and third-party auditors.

This approach contrasts with that for a hosted or on-premises client/server architecture. With client/server architecture you, the customer, are responsible for ensuring you have the appropriate hardware and processes in place. One challenge with this approach is maintaining IQ validation. Software upgrades may require hardware upgrades. In this environment, the customer must absorb the cost of the new hardware and the costs and delays of executing IQ on that new hardware.

Arena monitors and tests the hardware to maintain IQ. Arena scales hardware to ensure that the system can continue to operate under load.

Cloud OQ

The next part of validation is OQ, “operational qualification.”

OQ testing verifies that the software consistently works according to the intended use. The SaaS software vendor OQ validation goes beyond standard verification testing for quality. A best practice is to perform verification activities independent from validation activities, and each is conducted in separate environments. Verification testing consists of unit tests whereas validation testing involves user stories—each occurring as separate processes during the software development lifecycle. Validation activities are defined by validation user requirements.

Since we started offering Arena Validate, the Arena validation user requirements used for OQ have been growing to include more user stories and requirements. This growth comes from expanded functionality and customer input.

PQ for Cloud Software

The next, final step of validation is PQ, “performance qualification.”

PQ testing verifies that you can run your processes on the software. Because software enables your unique processes, PQ includes aspects of FDA CFR 21 Part 11 compliance.

CAPA processes broadly are corrective actions and preventive actions in a QMS system. At your company, you define the CAPA workflows and conditions based on your needs.

Training SOPs are required for software users. FDA CFR 21 Part 11.10 (i) states that FDA regulated companies should have procedures and controls for “Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.” So, you can use Arena Training or another training management system, but only you can set up the training plans for employees and partners according to your business needs.

Electronic password SOPs and forms are another area in which the software company can’t perform for you. FDA CFR Part 11.10 (j) states that FDA regulated companies should have “The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.” Arena, like other software companies, has many password controls, but you need a process to ensure that an electronic signature is equivalent to ink in your business.

PQ Sounds Like a LOT

It can be. While the software company is in the best position to do IQ and OQ, the customer is in the best position to do PQ. It is work, but it’s less than you had to do with the old client/server solutions. Let’s go through the common questions on PQ.

What Do You Need to Do?

Master Validation Plan

Create a master plan with PQ tasks, responsibilities, and dates.

Define Your Unique Needs

Create a list of unique user needs. Use the OQ documentation from Arena to see what has already been tested. Remember, the user requirements in OQ are those developed by Arena to cover most customer needs, but each Arena customer will have unique needs as well.

Assign a risk to each unique user need. To determine the risk associated with your unique needs, consider these fundamental questions from the Q9 Risk Management, FDA Guidance for Industry:

1. What might go wrong?
2. What is the likelihood (probability) it will go wrong?
3. What are the consequences (severity)?

Test Your Needs

Develop validation protocols. Here are some example elements for your validation protocol.

• Approval block
  • Names, dates, comments
• Objective or goal example
  • The goal of this protocol is to document the evidence that the software does support our CAPA processes and to provide assurance that it can work when we go live using the software
• Scope example
  • We are testing a CAPA process that is unique to our company. We will not test the default CAPA workflow already tested in OQ.
• Approach example
  • Review the CAPA workflow in the administration tool against the documented process
  • Run the CAPA workflow on a validation workspace that is a duplicate of the production workspace
  • Four test users function as the various roles in the workflow
  • Test users approve, reject, and comment on the CAPA steps
  • A test user checks the CAPA attributes and links at each step of the workflow
  • A test user runs our CAPA reports throughout the CAPA process
• Reason example
  • Our company decided to invest in cloud software to get the benefits of running CAPA and other processes in the cloud. Today, we rely on our CAPA system based on paper and spreadsheets. We need to be just as confident in the cloud software’s ability to support this crucial business process.
• Revalidation example
  • Revalidation should be done:
    • At each major release of the cloud software
    • On any change to the CAPA process
    • When we add a new partner or supplier to the process
  • We will not revalidate if we change the employees who participate in the CAPA process
• Responsibilities example
  • Quality assurance (QA) will be responsible for coordinating the test activity and documenting the results
  • Engineering and operations will each provide one person to test their roles in the CAPA process
  • QA will be responsible for following up on issues that testing revealed

Master Validation Report

This report contains the tests and the results. It documents issues uncovered by testing and how they were resolved. This report should be available to internal and external auditors.

Implement/Revise Procedures

Going forward, you will add or change the unique needs you identified for the first PQ validation. And the software company will add or change features that will impact your use of it. So, establish a process for doing PQ based on those changes. That should include reading release notes and impact statements from the software vendor, updating your user needs, testing, and documenting the results along with the software revision.

What’s the Level of Effort?

The level of effort depends on how many unique needs you have and the resources you have in place.

Some unique needs can be avoided—take your solution architect’s advice to reengineer your processes to better leverage the software. A common opportunity to streamline is your workflows. With software, you can make more reviews parallel instead of serial, giving your organization more flexibility and speed.

Other unique needs are so beneficial, you won’t want to avoid them. One example is integration. Integrations between systems save time, money, and keying errors, so that is usually a good investment. Common integrations (for instance, at Arena, that would be integrated PLM with ERP), are easy to validate because the functions are very common across implementations.

As for your resources, you may have people experienced in the PQ validation process, which will ease the burden.

Can We Get Some Help?

Yes, often the software company has resources and advice for you. At Arena, we have Solution Architects with PQ validation experience who have wisdom to offer you and your situation. And, Arena partners Medicept and The Product Realization Group are experienced and ready to help at any or all steps of PQ validation.

The Takeaway

When evaluating software vendors, be sure to prioritize validation. Multi-tenant cloud vendors give you a head start by doing IQ and OQ for you. Cloud solutions enable you to stay on the most current software release, so you can say goodbye to revision-locked enterprise software.