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.
A SaaS solution for the life sciences industry, Scilife improves process and product control, efficiency, and quality.
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 consistently and reliably. 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. Scilife conducts full validation, eliminating the majority of the validation burden for Scilife customers. The only aspect customers are required to handle is the initial implementation setup and verification.
No provider can eliminate 100% of the validation effort for the customer. When validating a computer system according to GAMP 5, it's essential to verify the system aligns with your intended purpose. While Scilife as a supplier provides all the documentation and templates needed for this process, it's important to note we cannot demonstrate that on your behalf.
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:
-Solutions.png?width=1560&height=1082&name=Validation-of-Software-as-a-Service-(SaaS)-Solutions.png)
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.
Initial 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.
- Document configuration changes you plan to do in your system along with how you will verify those configuration changes. Attach verification screens with the change request.
- Develop any SOPs/WIs where applicable as per your business for all different modules, or simply refer to the Scilife Knowledge Base.
- Go live in the production environment.
- Close the change request.
After going 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.
How to handle various releases from Scilife:
- Minor Releases/Hot Fixes: Since minor releases do not involve any change in features and processes, no additional effort is required from customers. Customers can review the Change Request and Release Notes provided by Scilife to understand the minimum changes released. If customers identify any change that impacts configurations they have already carried out then they can follow the process as documented below for Major and Medium releases.
- Major/Medium Releases: Initiate change requests to document the impact of changes released on current configurations. If the new release has an impact, document the configuration changes you plan to do in your system along with how you will verify those configuration changes. Attach verification screens with the change request.
- Update any SOP/WI if the new release has an impact on these documents.
- Close change request.
A 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 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
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. It helps 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.
Get to know more about Scilife smart QMS for Life Sciences organizations.
