SaaS validation strategy: Scilife Implementation without hassle

Published
Updated

What are SaaS solutions?

Software as a service (SaaS) solutions allow users to easily connect to and use cloud-based apps over the internet instead of having to install software on the user's local computer. Common examples include email services, calendars, and office tools (such as Microsoft Office 365). SaaS provides a complete software solution that you purchase on a pay-as-you-go basis from a cloud service provider.

Scilife is a SaaS solution for the Life Science industry to improve the control, efficiency, and quality of their processes and products.

SaaS solutions are becoming increasingly common in many industries today. These solutions – which may support multiple customers/tenants – may be subject to more frequent feature changes as well. This poses risks in terms of frequent functionality changes, such as ensuring that the system remains fully validated at all times.

 

What is Validation?

Computer Systems Validation (CSV) is an activity to improve the quality and value of a software product. Title 21 CFR Part 11 requires the “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.” Validation, at its most basic level, is the process of ensuring that applications, systems, solutions, and/or environments satisfy intended functionality in a consistent and reliable manner. The main benefit of validation is a high level of assurance that the system will perform as required and as intended during operation.

 

Validation of the Scilife Platform

The product implementation on the hosted platform is governed by the validation process. To implement the application for customers with zero defects and in the least possible timeframe, Scilife uses a system validation approach on the hosted platform. This lifts 95% of the validation burden off the shoulders of our customers. Of course, some customers are eager to know about the remaining 5% of the equation! In this article, we are also going to answer what needs to be done about the remaining 5% on your end.

Scilife uses a GAMP5 validation approach for validating the system on the Amazon Web Services (AWS) platform. As part of the validation phase, the Scilife platform is validated for, e.g., standard functionality and workflows in an environment independent of customers. This validated environment for standard functionalities and workflows can be used as-is by our customers, if their business process is aligned with the Scilife platform default workflow. A full package of validation deliverables is made available to the customer as a validation package with all documents listed below:

 

Standard Documents

Qualification Documents

Summary Documents

  • Validation Plan
  • User Requirements Specification
  • User Requirements Specification
  • Configuration Specification
  • Traceability Matrix
  • Test Plan
  • Risk Analysis
  • Installation and Operational Qualification Documents
  • Performance Qualification Document
  • Test Summary Report
  • Validation Summary Report

 

Scilife has implemented a complete validation for the SaaS platform on the AWS platform. Additionally, Scilife has been developed following regulatory requirements, being fully validated by us according to GAMP/21CFR11. The validation package includes a drafted, executed, and signed-off validation documentation set that customers can use as the basis for the validation of Scilife on their end. All showcased options are risk-based approaches. This document effectively eliminates most of the costs and resources needed for validation by our customers.

 

GAMP Category 3
Implementation Approach

Approach #1

When only one process workflow or low-risk features (as per customer business process) are implemented, the following steps should be executed by the customer:

    • Initiate Change Request to explain the change from manual to an electronic process for using the Scilife SaaS platform along with Reason, Impact, and Risk assessment.

    • Document configurations in the Configuration Specifications and perform verification in the validation environment. This can be considered as User Acceptance Testing by the customer; the customer can also test additional business processes.

    • Develop any SOPs/WIs where applicable to a customer’s business for all different modules, or simply refer to the Scilife Knowledge Base. SOPs/WIs need to be approved before production use.

    • Go-Live in the production environment by the customer.

    • Close the change request.

 

Approach #2

When more than one process workflow is implemented, the following steps are recommended to be executed by the customer:

    • Initiate a change request to explain the change from manual to an electronic process for using the Scilife SaaS platform along with reason, impact, and risk assessment.

    • Document standard Scilife platform configurations that will be used by users for pre-validated SaaS modules.

    • Perform configuration verification in the validation environment. This can be considered as User Acceptance Testing by the customer; the customer can also test additional business processes.

    • Develop any SOPs/WIs where applicable to a customer’s business for all different modules, or simply refer to the Scilife Knowledge Base. SOPs/WIs need to be approved before production use.

    • Go-Live in the production environment by the customer.

    • Close the change request.

 

GAMP Category 4
Implementation Approach

The changes made as per customer-specific requirements are validated in the customer environment. The actions that the customer must do in this case are:

  • Initiate Change Request to explain the change from manual to an electronic process for using the Scilife SaaS platform along with Reason, Impact, and Risk assessment.

  • A new Validation Plan should be created, which will be used to drive the validation process during the customer implementation phase.

  • Customer-specific customizations and changes related to the configuration will be implemented/configured in the system and will be functionally tested.

  • Perform a User Acceptance Test (UAT) to ensure the system functions as intended. For this, the following four-step process needs to be performed:

    • Create a UAT plan to identify and document which business processes will be tested;
    • Create UAT scripts;
    • Execute UAT scripts; and
    • Prepare UAT report.

  • Develop any SOPs/WIs where applicable to a customer’s business for all different modules, or simply refer to the Scilife Knowledge Base. SOPs/WIs need to be approved before production use.

  • Go-Live in the production environment.

  • All these activities will be documented in the validation report that should be generated as part of the implementation phase.

  • Close the change request.

After go-live, all changes to the customer environment will be driven by the change management process to ensure that all changes to the customer environment are documented.

The Scilife SaaS platform is maintained in a validated state by ensuring these listed procedures are followed:

  • Operational and maintenance SOPs/policies/WIs

  • Change management information

  • Incident management

  • Disaster recovery

  • Data backup and recovery

  • Personnel (including qualifications and training)

 

The Scilife Validation Documentation Package

A full package of validation deliverables is made available including the Validation Plan, Risk Assessment, Release Notes, User Requirements Specification, Configuration Specification, Test Plan, Installation and Operational Qualification Test Scripts, Performance Qualification Test Scripts, Test Summary Reports, Traceability Matrix, Standard Documents, and the Validation Summary Report. Our validation package for customers includes signed, approved, and documented evidence of the following elements:

1. Validation Plan

This plan outlines the validation approach, activities, responsibilities, and deliverables for the validation of the Scilife platform.

 

2. User Required Specifications (URS)

The URS identifies end-user requirements for the system. This document defines what the system should do in order to satisfy business needs and how the system should function to comply with all applicable regulations.

 

3. Risk Analysis

This document is directly related to the User Requirements Specification (URS) document. It is important for the identification and mitigation of risks that come with the various URS items. Each URS item is analyzed to identify potential risks that specific functionality may pose from a GxP or from a business requirement perspective. Once identified, these risks are classified according to their severity and probability, after which mitigation of the risks is described to assign a risk priority.

 

4. Release Notes

This document informs the Major/Medium/Minor releases separately for each solution of the Scilife platform, with details of new features and changes introduced with that release. It also documents known issues/bugs, workarounds, and validation approaches.

 

5. Configuration Specifications (CS)

The CS contains configuration requirements in terms of preconfigured settings in the system. The objective here is to explain the configuration options of the Scilife platform and to document the details of user roles and their permissions/accessibility.

 

6. Test Plan

The Test Plan lists the procedures needed to verify the proper installation, configuration, and operation of this platform in the validation and production environments.

 

7. Installation and Operational Qualification (IOQ)

IOQ provides assurance that the application and its supporting infrastructure have been correctly installed and configured, and also provides a high level of assurance that the complete integrated system functions as specified before executing the Performance Qualification.

 

8. Performance Qualification

This test is an evaluation of the application by users, in conjunction with their knowledge of the business processes required to perform certain tasks. It involves the execution and documentation of specific tests designed to demonstrate that the application performs as expected and meets the users’ specified requirements.

 

9. Traceability Matrix

This tool ultimately ensures that all specified requirements are met. The matrix establishes the relationship between requirements and testing activities that demonstrate the requirement is satisfied. It also provides a cross-reference between requirements and procedures or external controls that ensure a specific requirement is satisfied.

 

10. Test Summary Report

This report summarizes the activities that verify the testing process/test results for the Installation Qualification, Operational, and Performance Qualification testing.

 

11. Validation Summary Report

This document summarizes the results of all activities and the status of the deliverables identified in the Validation Plan to determine if the Scilife platform was properly implemented according to the predefined specifications and operates as intended.

 

Conclusion

At Scilife, we ensure that the performance of our platform and its functionalities are always reliable and adapt to our customers’ changing needs anytime, without causing headaches. We take care of most of the validation process, following all standard procedures and regulations, freeing up valuable time and resources for our customers from this process to smoothly onboard you and your team on the platform.

 

Are you still looking for software that suits your needs and does not represent an extra workload for the whole team?
Discover how Scilife can ease the process!

BOOK YOUR DEMO

The requirements of Life Sciences companies (including in the pharma and medical device space) inevitably change over time. Sometimes, a change is due to regulatory requirements; sometimes, customer needs change. Keep reading if you want to...