Vault Validation Management is an application in the Vault Quality Suite that helps organizations manage and execute paperless validation across validation disciplines including: Computerized Systems Validation (CSV), Facility, Equipment, and Utility (FUE), process validation, cleaning validation, and method validation. Validation Management includes several key features:

  • Validation Management automation helps facilitate the creation of versions of validation entities as well as requirements.
  • Additional objects support validation activities and deliverables needed to prove an entity has been validated.
  • A paperless test execution experience where pre-approved test scripts consisting of setup steps and execution steps can be executed by one or more assigned executors. Executors can perform procedures defined by test authors, access requirements being challenged, describe their observed results, and upload attachments to provide objective evidence.
  • Test execution can be paused, terminated, and eventually resumed when exceptions or discrepancies are encountered. These exceptions and discrepancies can be created directly from the test step where the issue was encountered. The discrepancy will then undergo a workflow for investigation, root cause, and corrective action.

Validation Management Data Model

Validation Management uses these core objects:

  • Validation Inventory Item: An asset that needs to be managed by an organization’s validation processes. Validation Management supports the following Inventory Item types: Computer System, Cleaning, Equipment, Facility, Method, Process, and Utility. For example: VernSoft GxP System
  • Validation Entity: A specific version of an asset at a point in time that will be evaluated by an organization’s validation process. In other words, a versioned instance of an Inventory Item which contains the validation information for that specific version. For example: VernSoft GxP System v1.4 or VernSoft GxP System v1.5. A Validation Entity will have its own unique requirements in addition to requirements that are still applicable from a prior version. The Validation Entity will also have its own unique activities and validation deliverables.
  • Validation Activity: A specific activity performed upon a validatable entity. This object describes the purpose and scope of the deliverables needed for an entity to become validated and used in a production environment. Additional information captured includes start and end dates, participants, and all the deliverables needed to complete the activity. Activities have the following types: Initial Qualification / Commissioning, Change / Modification, and Periodic Review. For example: VernSoft GxP System v1.5 Upgrade Validation Project. The validation activity can also be thought of as a validation project that must be performed in order for the entity to become validated and used in production, while collecting all supporting evidence and completing all necessary validation procedures.
  • Validation Deliverable: A document or other artifact which supports or marks a milestone in a Validation Activity. The deliverable contains the work done to demonstrate that an entity is or is not validated. The Validation Deliverable record functions as a placeholder for a deliverable document or test deliverable. For example: Validation Plan 1.0 (VernSoft GxP System v1.5).docx. Deliverables have the following types:
    • Design / Requirements Deliverable: Used for a User Requirement Specification document, Functional Requirement Specification document, or Design Specification document.
    • Planning Deliverable: Used for validation plan documents.
    • Reference Deliverable: Used in cases where you need to leverage validation deliverables or content from a vendor, supplier, or other third party.
    • Report Deliverable: Used for report documents such a validation summary report or a requirements trace matrix report.
    • Risk Assessment: Used for risk assessments or impact assessment documents.
    • Testing Deliverables: Used for test protocols and test scripts. Each test protocol or test script needs one deliverable.
  • Validation Requirement: Describes the requirements against which entity or asset will be evaluated. When a new version of a Validation Entity is created, Vault copies all the associated requirements from the previous entity. There are three types of requirements: User Requirements, Functional Requirements, and Design Specifications. For example: UR-VernSoftGxP-1.
  • Validation Team Assignment: A role assigned to an individual for a particular Validation Inventory Item record. Users with permission to create Validation Team Assignment records at the Validation Inventory Item record level can assign a user to a specific validation role.
  • Test Protocol: Contains narrative content stored in a document record that is relevant to the overall protocol and also consists of one or many test scripts. The Test Protocol narrative content includes information such as the purpose, scope, system overview, responsibilities, reference information, execution requirements, appendices, or other information.
  • Test Script: Contains steps to be performed by assigned Executors to fulfill a required Testing Deliverable that is part of the overall validation activity. Executors perform tests in the test execution interface. A Test Script can be standalone or part of a Test Protocol. If multiple attempts to execute a Test Script are needed for a particular Testing Deliverable, copies of the original Test Script can be created for each additional test run.
  • Requirements Traceability Matrix: Vault creates placeholder Requirements Traceability Matrix records when requirements are associated with an entity version. An entity version is created from a prior version such that each approved requirement has a trace matrix record for that version of the entity. These placeholder records are used to identify requirements which should be tested, but have not yet been planned for testing. Existing placeholder records are either updated or new records are added during test script authoring.

Validation Management Roles

Validation processes require the collaboration of several individuals with separate responsibilities. These individuals are represented in Vault Validation Management via the following roles.

Business Process Owner or System Owner

The owner of the system or process being tested. This user is typically involved with authoring requirements, contributes to assigned validation deliverables, and is part of the approval process for validation deliverables.

Approver

Any authority involved in the approval process for validation deliverables and fully executed Test Scripts. There can be multiple approvers for a given validation deliverable.

Independent Reviewer

An individual involved in an independent review of individual Test Scripts. Responsible for ensuring that any discrepancies have been properly addressed and that the system is properly challenged to ensure that the validated state is reliable and compliant prior to involving final approvers.

Quality Unit

The member of the quality assurance team with final authority over whether a validation deliverable is approved or rejected. This also applies to Testing Deliverables to determine whether the test script has passed or failed, or is approved or rejected.

Test Author

A user who is responsible for authoring Test Protocols and Test Scripts, typically a member of the Validation team. For Test Scripts, the Test Author will add the content including all test steps that must be performed to ensure that all defined user and functional requirements will be challenged appropriately prior to submitting the Test Script for pre-approval. Once pre-approved, Test Scripts are available for execution by assigned executors.

Test Co-Author

In cases where multiple users need to author test steps within the same Test Script, one or more Test Co-Authors may be necessary. They must be a member of the Validation team. The Test Author and Test Co-Authors can add, edit, or delete test steps simultaneously within the Test Authoring Interface.

Lead Executor

In cases where multiple Executors are performing test steps within the same Test Script, the Lead Executor is responsible for the overall governance of the execution of the test script. The Lead Executor often performs a review of the testing work prior to submitting it for independent review or formal approval.

Executor

A user who is responsible for performing assigned Test Steps defined in Test Scripts. While test scripts often have only one Executor, in some cases the individual steps within a test script are assigned to multiple Executors.

Minimum Permissions to Access Test Authoring, Test Execution, & Review Protocol UIs

The following table lists the minimum object-level permissions required for users to view Validation Management interface pages. In addition to these object-level permissions, users require the Read field-level permission to all fields in these objects except for Name and, if applicable, State and Object Type. Vault displays an error message if the minimum permissions are not assigned at the object or field level to a user that attempts to open the Test Authoring, Test Execution, or Test Protocol Review interfaces.

Minimum Object-Level Permissions

Object Test Authoring Interface Test Execution Interface Test Protocol Review Interface
Validation Entity Read Read Read
Validation Requirement Entity Version Read Read Read
Validation Activity Read Read Read
Validation Deliverable Read (Testing Deliverable object type) Read (Testing Deliverable object type) Read (Testing Deliverable object type)
Validation Requirement Read (All object types Including custom and base object types) Read (All object types Including custom and base object types) Read (All object types Including custom and base object types)
Requirements Traceability Matrix Read Read Read
Test Protocol Read Read Read
Test Script Read Read Read
Test Step Read (Setup Step and Execution Step object types) Read (Setup Step and Execution Step object types) Read (Setup Step and Execution Step object types)
Test Step Change Not Applicable Read Read
Discrepancy Not Applicable Read Read
Related Discrepancy Not Applicable Read Read
Test Step Additional Prompt Read Read Read
Unit of Measure Read Read Read

Minimum Field-Level Permissions

Object Field Test Authoring Interface Test Execution Interface Test Protocol Review Interface
Validation Entity validation_inventory_item__v Read Read Read
Validation Activity validation_inventory_item__v Read Read Read
validation_entity__v Read Read Read
Validation Deliverable validation_inventory_item__v Read Read Read
validation_activity__v Read Read Read
Validation Requirement validation_inventory_item__v Read Read Read
description__v Read Read Read
entity_version__v Read Read Read
requirement_category__v Read Read Read
requirement_id__v Read Read Read
requirement_source__v Read Read Read
requirement_version__v Read Read Read
requirement_risk_assessment__v Read Read Read
test_strategy__v Read Read Read
Requirements Traceability Matrix validation_inventory_item__v Read Read Read
validation_entity__v Read Read Read
deliverable__v Read Read Read
requirement__v Read Read Read
test_script__v Read Read Read
test_step__v Read Read Read
Test Protocol validation_inventory_item__v Read Read Read
deliverable__v Read Read Read
document__v Read Read Read
document_unbound__v Read Read Read
test_protocol_id__v Read Read Read
title__v Read Read Read
Test Script validation_inventory_item__v Read Read Read
author__v Read Read Read
co-author__v Read Read Read
deliverable__v Read Read Read
test_protocol__v Read Read Read
test_script_id__v Read Read Read
test_run_number__v Read Read Read
title__v Read Read Read
Test Step validation_inventory_item__v Read Read Read
actual_results__v Not Applicable Read Read
actual_results_fit_to_width__v Read Read Read
actual_results_setting__v Read Read Read
attachment_setting__v Read Read Read
author__v Read Read Read
co-author__v Read Read Read
comment__v Not Applicable Read Read
comment_allowed__v Read Read Read
complete__v Not Applicable Read Read
date_time_completed__v Not Applicable Read Read
date_time_witnessed__v Not Applicable Read Read
executor__v Read Read Read
expected_results__v Read Read Read
expected_results_fit_to_width__v Read Read Read
expected_results_setting__v Read Read Read
pass_fail_not_applicable__v Not Applicable Read Read
procedure__v Read Read Read
procedure_fit_to_width__v Read Read Read
procedure_setting__v Read Read Read
result_label__v Read Read Read
step__v Read Read Read
step_title__v Read Read Read
test_script__v Read Read Read
verdict_setting__v Read Read Read
witness__v Read Read Read
witness_required__v Read Read Read
Test Step Change validation_inventory_item__v Not Applicable Read Read
change_reason__v Not Applicable Read Read
field_changed__v Not Applicable Read Read
change_justification__v Not Applicable Read Read
new_value__v Not Applicable Read Read
original_value__v Not Applicable Read Read
test_script__v Not Applicable Read Read
test_step__v Not Applicable Read Read
test_step_additional_prompt__v Not Applicable Read Read
Test Step Additional Prompt validation_inventory_item__v Read Read Read
actual_datetime_response__v Not Applicable Read Read
actual_number_response__v Not Applicable Read Read
actual_text_response__v Not Applicable Read Read
author__v Read Read Read
co-author__v Read Read Read
executor__v Read Read Read
fit_to_width__v Read Read Read
prompt_label__v Read Read Read
prompt_order__v Read Read Read
prompt_required__v Read Read Read
test_script__v Read Read Read
test_step__v Read Read Read
text_instruction__v Read Read Read
unit_of_measure__v Read Read Read
witness__v Read Read Read