<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=411510132638266&amp;ev=PageView&amp;noscript=1">

SaaS validation strategy: Scilife Implementation without hassle


We are very proud that we provide Scilife's Platform as a pre-validated software. This lifts 95% of the validation burden off the shoulders of our customers. This being said, we often receive a question about the remaining 5% of the part. Therefore in this article, we are going to answer what needs to be done with regards to this remaining 5% at your end.


What do we do at our end?

Scilife's Platform is validated to comply with GAMP5. We have a dedicated validation team at Scilife to take care of this part. The outline of our SaaS validation strategy and approach is depicted in diagram below:

Graphic that shows our Scilife SaaS validation strategy

Our validation package includes signed and approved documented evidence of:

  1. Validation plan: 
    The Validation Plan outlines the validation approach, activities, responsibilities, and deliverables for the validation of Scilife's Platform. 

  2. User Required Specifications (URS):
    The User Requirements Specification (URS) identifies end-user requirements for the system. The URS defines what the system should do in order to satisfy business needs and how the system should function in order to comply with applicable regulations.

  3. Functional Specification (FS):
    The Functional Specification (FS) describes the functionality provided by Scilife's Platform in order to satisfy the specified User Requirements. 

  4. Configuration and Design Specifications (CS):
    The technical design & configuration specification documents the refinement and explanation/configuration of the system in the Functional Specification to the extent that it is sufficiently complete to be implemented.

  5. Installation and Configuration Testing:
    Installation and configuration verification activities will be carried out in accordance with an approved Installation and configuration verification Protocol. This Protocol governs the documentation and acceptance of the system and its configuration. A summary of the Installation and Configuration verification will be provided in an Installation and Configuration verification Report.

  6. Performance Qualification:
    Performance Qualification Testing is an evaluation of the application by users, in conjunction with their knowledge of the business processes required to perform the related 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. Different possibilities of workflow and security functions will be tested in this stage. A Performance Qualification Protocol (PQP) will be written to describe the objectives, procedures, data sets, and expected results for the user testing. Test scripts will be designed together with the key users and on basis of the criticality analysis.

  7. Traceability Matrix:
    The Traceability Matrix will serve as a tool for ensuring that specified requirements are met. This matrix will:

    - Establish the relationship between requirements and the testing activities that demonstrate the requirement is satisfied.

    - Provide a cross-reference between requirements and the procedures or external controls that ensure the requirement is satisfied.

  8. Validation Report:
    A Validation Report will be written at the conclusion of the project. The Validation Report will:

    - Summarize the entire validation effort as well as its outcome; 

    - Refer to and document non-conformities if any; 

    - Discuss and document deviations, if any, from the original Validation Plan.


What you might want to do at the receiving end?

In our experience, the remaining 5% effort on the SaaS validation activities can be done in many ways. In this blog we are going to explain three such options. All the options that we are going to explain in this article are risk-based approaches.

Option 1

SaaS validation activities in accordance with this option can be executed in three steps as below:

Step 1: Create a validation plan

    1. The validation plan should first state what is the name of the software, its intended use, Activated Modules in the Life Sciences Software. 

    2. This should be followed by an explanation that Scilife's Platform is a pre-validated software that comes with a package of validation documents as mentioned above. 

    3. State that the validation package will be reviewed and an assessment on the sufficiency of the package will be made.

    4. Conclude whether the package meets sufficiency requirements. If the package meets requirements then further user acceptance testing will not be required. If the package does not meet the requirements then conclude about performing additional user acceptance testing.

Step 2: User acceptance testing

In this step, state that:

    1. The vendor has provided test evidence with screenshots. 

    2. While the test evidence ensures that every Performance Quality Test is passed, it will be still useful to run a few user acceptance tests.

The next step is to:

    1. Create a user acceptance test. An example of such a test would be creating a document and pushing it through the workflow for review, force review, approval, etc.
      e. g. Create documentation. 

    2. It is recommended to do a basic test for all modules.

Step 3: Validation Report

State that:

    1. All the documents were reviewed.

    2. User acceptance tests were created.

    3. The tests were passed.

    4. Therefore Scilife's Platform is ready for use.


Option 2

This option consists of two steps as follows:

Step 1 Plan: 

In this step, the user states that all the documents and Performance Quality Test were reviewed and the Performance Quality Tests are sufficient.

Step 2 Report: 

In this step, the user states that based on step 1, I consider Scilife's Platform ready to use.


Option 3

Have one report called Scilife Validation Document. This report state:

    1. The description of Scilife's Platform and what it does.

    2. The details of the validation package are provided by the vendor.

    3. How the validation package was reviewed.

    4. Therefore Scilife's Platform is ready to use as all the PQTs meet our requirements.



Our SaaS validation strategy saves most of the validation effort at your end. Still, some of our customers may find it useful to do some validation effort at their end depending on the kind of audits, market, and clients they face.

We have recommended a few easy options for the same. In the end, if these options still lead to minor audit observations or market demands, then we’ll be always by your side always exploring more complex validation processes.