Software Validation Package

Revision History

This document is maintained on a quarterly validation cycle. Each revision corresponds either to a software version update (requiring full revalidation) or a periodic revalidation confirming continued validated state.

1. Purpose and Scope

1.1 Purpose

This Software Validation Package (SVP) documents the complete verification and validation activities performed by RapidFacto for RapidFacto MES/QMS version 3.1. It provides objective evidence that the software consistently meets its specified requirements and is suitable for its intended use in medical device manufacturing environments.

This document serves as the vendor's validation dossier to be provided to client organizations (medical device manufacturers) as evidence of software supplier qualification and software validation. Clients may reference this SVP in their own Computer System Validation (CSV) activities to satisfy ISO 13485:2016 §4.1.6 and §7.5.6 requirements.

1.2 Scope

The validation scope encompasses:

• All functional modules of RapidFacto MES/QMS as deployed in the production SaaS environment
• Security controls including authentication, authorization, and multi-tenant data isolation
• Electronic records and electronic signatures per 21 CFR Part 11 / EU Annex 11
• Data integrity controls aligned with ALCOA+ principles
• Audit trail functionality across all regulated modules
• Report generation (34+ controlled-format PDF documents)
• Approval workflow engine with configurable multi-step routing
• Infrastructure controls including backup, recovery, and availability

1.3 Intended Use

RapidFacto MES/QMS is intended for use by medical device manufacturers to manage manufacturing execution workflows, quality management processes, and regulatory compliance documentation. Specific intended uses include:

• Creation and execution of Batch Manufacturing Records (BMR) with in-process quality controls
• Management of materials, inventory, and procurement with full traceability
• Controlled document and record management with versioning and approval workflows
• Quality management including CAPA, complaints, internal audits, and management review
• Training management with module authoring, assignment, assessment, and record keeping
• Equipment/machine management with maintenance scheduling and calibration tracking
• Generation of controlled-format regulatory reports (BMR, COA, FG test reports, etc.)
• Electronic signature capture for regulated actions per 21 CFR Part 11

2. Applicable Standards and References

3. Definitions and Abbreviations

4. System Description

4.1 Product Overview

RapidFacto MES/QMS is a cloud-hosted, multi-tenant Manufacturing Execution System (MES) fully integrated with a comprehensive Quality Management System (QMS). It is purpose-built for medical device manufacturers operating under ISO 13485:2016, MDSAP, CDSCO, and FDA regulatory frameworks.

The system digitizes the entire manufacturing lifecycle — from raw material receipt and testing through batch production, in-process quality control, finished goods testing, and batch release. Simultaneously, it provides complete QMS capabilities including controlled document management, CAPA, complaint handling, supplier qualification, internal audits, training management, and management review.

Every regulated action within the system is captured in an immutable audit trail. Electronic signatures with password re-authentication are enforced on critical operations. All records maintain full traceability from creation through any modification.

4.2 System Architecture

The system follows a secure three-tier architecture:

• Presentation Layer: Web-based single-page application accessible via modern browsers. Handles user interaction, form validation, PDF report rendering, and electronic signature capture. Communicates with the application layer exclusively via encrypted REST API calls with token-based authentication.
• Application Layer: RESTful API server implementing business logic, access control enforcement, audit logging, e-signature processing, approval workflow orchestration, and report data assembly. Covers all functional domains with comprehensive API surface.
• Data Layer: Enterprise-grade relational database with defined schemas for all business entities. Redundant cloud object storage for file attachments. Managed identity service for authentication and token issuance.

4.4 Functional Modules

4.5 User Roles and Permissions

The system implements granular role-based access control. Permissions are defined at the entity-type level with the following permission actions:

Pre-configured role templates are provided for common manufacturing positions: Production Manager, Production Worker, Sales Manager, Store Manager, QC Manager, QA Manager, Document Controller, Training Coordinator, Auditor, and Management Representative. Custom roles can be created by combining entity-level permissions.

5. Software Categorization

5.1 GAMP 5 Classification

RapidFacto MES/QMS is classified as a GAMP 5 Category 4 (Configured Product).

Rationale:

• The system provides standard, pre-built functionality for manufacturing execution and quality management
• Each tenant configures the system to their specific needs through: manufacturing model definitions (steps, IPQC, QC checklist), approval workflow configuration (steps, approvers, routing), e-signature module enablement per process area, role/claim assignment per user, report template customization, and logbook/form field definitions
• No custom code development is performed per client — all client-specific behavior is achieved through configuration of the standard product
• The configurable nature aligns with GAMP 5 Category 4 rather than Category 5 (custom), as the core business logic is vendor-developed and shared across all tenants

5.2 IEC 62304 Safety Classification

The software is classified as IEC 62304 Class B (software system that can contribute to a hazardous situation but where injury is not reasonably foreseeable).

Rationale:

• RapidFacto MES/QMS is a record-keeping, manufacturing execution, and quality management system — it does not directly control medical device hardware, manufacturing equipment, or patient-contacting processes
• A software failure (e.g., incorrect batch record, failed audit trail entry) could lead to a situation where a non-conforming device enters distribution. However, multiple independent downstream controls exist: QC testing, batch release approval, finished goods testing, physical inspection
• The software contributes to safety through accurate record-keeping and process enforcement, but is not the sole control against a hazardous situation — human review and physical testing provide independent barriers
• Class C (serious injury/death) was rejected because the software does not directly control any process that could cause injury, and multiple external controls exist
• Class A (no contribution to hazard) was rejected because inaccurate records could contribute to a non-conformance escaping detection, even if downstream controls would likely catch it

6. Software Development Life Cycle

RapidFacto follows an Agile software development life cycle aligned with IEC 62304:2006+A1:2015 requirements. Development is organized in time-boxed iterations with continuous integration and controlled release cycles.

Change Control: All changes to the production system follow a controlled process:

• Change request documented with scope, risk assessment, and rollback plan
• Code changes undergo mandatory peer review via pull request
• Automated CI pipeline runs unit and integration tests on every commit
• Staging deployment for integration verification before production
• Database schema changes managed through numbered migration scripts
• Production deployment logged with version, timestamp, and deployer
• Post-deployment verification checklist executed

7. Functional Requirements

The following table documents the high-level functional requirements for RapidFacto MES/QMS. Each requirement is traced to specific test cases in the V&V section and Requirements Traceability Matrix (Section 16). Requirements are organized by functional domain.

8. Risk Management

8.1 Methodology

Software risk assessment is performed in accordance with ISO 14971:2019 and ICH Q9. Risks are identified through failure mode analysis of software functions, considering:

• Probability of software failure occurrence
• Severity of consequence if failure is undetected
• Detectability of the failure through existing controls

Risk levels are assigned as High / Medium / Low based on the combination of these factors. Mitigation controls are implemented within the software, and residual risk is assessed after control implementation.

8.2 Risk Register

9. Verification and Validation

9.1 Test Strategy

The verification and validation program employs a multi-level testing approach consistent with IEC 62304 requirements and GAMP 5 Category 4 expectations. Testing is executed at four levels, each targeting different aspects of system correctness:

• Unit Testing: Individual service methods and utility functions tested in isolation. Covers business logic, calculations, validation rules, and data transformations. Backend services tested with JUnit 5 + Mockito; frontend utilities tested with Jest.
• Integration Testing: REST API endpoints tested end-to-end against a test database. Verifies request/response contracts, authentication enforcement, RBAC filtering, database persistence, and cross-module interactions.
• System Testing: Complete end-to-end workflow validation in the production-equivalent environment. Tests realistic user scenarios spanning multiple modules (e.g., PO → GRN → Inspection → Testing → Stock Update → Batch Requisition).
• Regression Testing: Full re-execution of existing test cases after each release to verify that new changes have not introduced defects in previously validated functionality.

9.2 Test Execution Summary

The following table summarizes test execution results for the current validation period (v3.1, June–July 2026):

9.3 System Test Cases — Detailed Results

The following table presents key system-level test cases executed during the validation period. Each test verifies a specific functional requirement and is included in the Requirements Traceability Matrix (Section 16).

9.4 Validation Conclusion

All verification and validation activities for RapidFacto MES/QMS v3.1 have been completed satisfactorily during the validation period (01-Jun-2026 to 15-Jul-2026). A total of 860 test cases were executed across unit, integration, system, and regression levels with a 100% pass rate. No critical or major deviations were observed during testing.

The software meets its specified functional requirements (FR-001 through FR-020) and demonstrates appropriate implementation of:

• 21 CFR Part 11 electronic record and electronic signature controls
• Immutable audit trail with complete data change attribution
• Role-based access control with entity-level permission granularity
• Multi-tenant data isolation without cross-contamination
• Data integrity aligned with ALCOA+ principles
• Controlled-format report generation with revision tracking

The software is confirmed to be in a validated state and is suitable for its intended use in medical device manufacturing quality management systems.

10. Electronic Records and Electronic Signatures

10.1 Applicability Statement

RapidFacto MES/QMS creates, modifies, maintains, archives, retrieves, and transmits electronic records that are used to fulfill regulatory requirements under 21 CFR Parts 210, 211, and 820. The system also provides electronic signature capabilities that are intended to be the equivalent of handwritten signatures. Therefore, the requirements of 21 CFR Part 11 are applicable to this system.

10.2 Controls Matrix

10.3 E-Signature Module Configuration

Electronic signature enforcement is configurable at two levels:

• Global toggle: Master enable/disable for the entire e-signature system (tenant-level setting)
• Per-module toggles: Individual enable/disable for each process area where signatures are captured

11. Security and Access Control

11.1 Authentication

User authentication is managed through a managed identity platform with industry-standard security controls. The authentication flow:

• User submits email and password to the identity provider
• Credentials are validated and a cryptographically signed token (JWT) is issued
• Token is included as a Bearer token in all subsequent API requests
• Backend validates token signature against the provider's public key endpoint
• Custom claims embedded in the token encode user role/permissions
• Tokens are short-lived (1 hour) with automatic secure refresh

Security characteristics:

• Passwords are never stored in the application database — managed by the identity provider
• All communication encrypted via TLS 1.3 (HTTPS only)
• Token signatures use industry-standard asymmetric cryptography (RS256)
• Token validation is stateless — no server-side session to hijack
• Failed login attempts tracked with brute-force protection

11.2 Authorization Model

The authorization model is based on entity-type-level permission claims embedded in the authentication token. This provides fine-grained access control enforced on every request.

Claim format: ENTITY_TYPE:PERMISSION (e.g., BATCH:WRITE,QUALITY:ALL_ACCESS)

Authorization is enforced at multiple layers:

• UI layer: Route guards prevent navigation to unauthorized pages; menu items filtered by claims; action buttons hidden for insufficient permissions
• API layer: Token validated on every request; endpoint-level and service-level permission checks for all sensitive operations
• Data layer: Tenant context filter ensures queries only return data belonging to the authenticated user's organization

11.3 Multi-Tenant Data Isolation

Multi-tenancy is implemented through logical isolation at the database query level:

• Every business entity is scoped to a tenant identifier
• On each API request, the authenticated user's tenant is extracted from their token and set as the active context
• All database queries are automatically scoped to the active tenant — this is enforced by the framework, not individual application code
• There is no API parameter that allows specifying a different tenant
• Cross-tenant access is architecturally impossible through the normal API surface

11.4 Audit Trail Architecture

The audit trail is implemented as an immutable, append-only log:

• Design: Append-only records — no update or delete operations are exposed for audit data at any layer
• Captured data: Entity type, entity ID, action (CREATE/UPDATE/DELETE/STATUS_CHANGE), performing user (ID, name, role), timestamp (server-generated UTC), old values, new values, change description
• Coverage: 25+ entity types audited including production batches, purchase orders, GRN, materials, machines, documents, training, complaints, CAPA, audits, MRM, logbooks, suppliers, inventory, approvals
• Integrity: No endpoints exist for modifying audit records; server-generated timestamps prevent client manipulation; database constraints enforce immutability
• Accessibility: Audit trail viewable per entity via dedicated UI; filterable by date range, user, and action type

12. Data Integrity (ALCOA+)

Data integrity controls are aligned with WHO TRS 996 Annex 5 and FDA guidance on data integrity and CGMP compliance. The following matrix documents how each ALCOA+ principle is addressed:

13. Backup, Recovery, and Business Continuity

14. Configuration and Change Management

14.1 Source Code Management

• All source code managed in Git with complete commit history
• Branch-based development: feature branches merged to main via reviewed pull requests
• Every commit attributed to author with timestamp
• Release versions tagged with semantic versioning (MAJOR.MINOR.PATCH)
• No direct commits to production branch — all changes via PR with review

14.2 Database Schema Management

• Schema changes managed through numbered SQL migration scripts
• Migrations applied sequentially with rollback capability
• Schema changes reviewed as part of code review process
• Production schema changes deployed during maintenance windows with backup verification

14.3 Report Format Control

• Each report type has a controlled format number (e.g., RPF01, RPF02)
• Revision numbers tracked per format (incremented on content/layout changes)
• Effective dates recorded for each revision
• Tenant-customizable templates with version control
• Default templates maintained centrally with revision history

14.4 Release Process

• Release candidate prepared with changelog
• Deployment to staging environment for integration verification
• Regression test suite executed in staging
• Production deployment with zero-downtime rolling update
• Post-deployment verification checklist (smoke tests on critical workflows)
• Rollback procedure documented and tested for each release
• Release notification to affected tenants

15. Supplier Assessment Information

16. Requirements Traceability Matrix

The following matrix demonstrates bidirectional traceability between functional requirements and test cases, confirming that all requirements have been verified:

17. Controlled Report Format Register

The following register documents all controlled-format reports generated by the system. Each report type has a unique format number, revision number, and effective date. Tenant-specific customizations are tracked separately.

18. Validation Conclusion

Based on the comprehensive verification and validation activities documented in this Software Validation Package, RapidFacto MES/QMS v3.1 has been demonstrated to meet its specified functional requirements and all applicable regulatory requirements.

Key findings:

• 860 test cases executed with 100% pass rate across all testing levels
• 21 CFR Part 11 controls fully implemented and verified (15 regulatory sections addressed)
• ALCOA+ data integrity principles addressed with documented controls
• Risk assessment identifies 12 hazards — all mitigated to Low residual risk
• Immutable audit trail verified for completeness and accuracy
• Electronic signatures verified for both acceptance and rejection cases
• Multi-tenant data isolation verified — no cross-contamination possible
• 34+ controlled-format reports verified with correct format/revision numbering

The software is confirmed to be in a validated state and is authorized for use in medical device manufacturing quality management systems operating under ISO 13485:2016, MDSAP, 21 CFR Part 820, and 21 CFR Part 11.

Next scheduled revalidation: October 2026 (quarterly cycle).