<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=489233&amp;fmt=gif">

SaaS validation strategy: Scilife Implementation without hassle


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 from a cloud service provider on a pay-as-you-go basis.

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 also be subject to more frequent feature changes. 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.


Computer System Validation of SaaS Platforms at Scilife

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 to provide Scilife’s platform as validated software. 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.

Validation of the Scilife Platform

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
  • Risk Analysis Document
  • Configuration Specification
  • Traceability Matrix
  • Test Plan
  • Installation and Operational Qualification Documents
  • Performance Qualification Document
  • Test Summary Report
  • Validation Summary Report


In our experience, Scilife has implemented complete validation for the SaaS platform on the AWS platform. Additionally, Scilife was developed following regulatory requirements, being fully validated by us according to GAMP5/21CFR11/Annex11. 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 Implementation Approach for Customers

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

  • Create one Validation Master Plan to describe the validation approach, deliverables, roles & responsibilities, and all required activities for the implementation of all Scilife modules. 

  • Create a separate Configuration Specification document for each module to document standard Scilife platform configurations that users will use. E.g., are QA signatures required on all documents or not?

  • Create and execute User Acceptance Test scripts in the Validation environment to ensure module workflow and module settings successfully meet the business needs as defined in the Configuration Specification document. The customer can also test additional business processes.

  • Prepare and approve the Validation Summary Report separately for each module upon completion of validation activities as per this Validation Master Plan. 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.

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)

A full package of validation deliverables is made available, including the Validation Plan, Risk Assessment, User Requirements Specification, Configuration Specification, Test Plan, Installation and Operational Qualification Test Scripts, Performance Qualification Test Scripts, Test Summary Reports, Traceability Matrix, 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 validating 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 to identify and mitigate 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 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. 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.


5. 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.


6. Installation and Operational Qualification (IOQ)

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


7. Performance Qualification

This test evaluates 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.


8. 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 to satisfy a specific requirement.


9. Test Summary Report

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


10. 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.



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 Smart QMS can ease the process!

Book your Demo

Most pharma and medical device companies are increasingly adopting electronic Quality Management Systems (eQMS) to streamline their quality management processes. A well-designed quality management system helps you to meet customer satisfact...