Realizar Evaluación CSV

Llevar a cabo una evaluación de Validación de Sistemas Informatizados usando la metodología basada en riesgo GAMP 5 para entornos regulados.

Cuándo Usar

• Se introduce un nuevo sistema informatizado en un entorno GxP
• Un sistema validado existente experimenta un cambio significativo
• Se requiere revalidación periódica
• La preparación para una inspección regulatoria exige un análisis de brechas de validación

Entradas

• Requerido: Descripción del sistema (nombre, propósito, proveedor, versión)
• Requerido: Declaración de uso previsto y contexto regulatorio (alcance GxP)
• Requerido: Categoría de software GAMP 5 (1–5)
• Opcional: Especificación de requisitos de usuario (URS) existente
• Opcional: Documentación del proveedor (especificaciones de diseño, notas de versión, SOPs)
• Opcional: Documentación de validación previa

Procedimiento

Paso 1: Determinar la Categoría de Software GAMP 5

Clasificar el sistema:

Categoría	Tipo	Ejemplo	Esfuerzo de Validación
1	Software de infraestructura	SO, firmware	Bajo — verificar instalación
3	Producto no configurado	COTS tal como está	Bajo-Medio — verificar funcionalidad
4	Producto configurado	LIMS con configuración	Medio-Alto — verificar configuración
5	Aplicación personalizada	App R/Shiny a medida	Alto — validación completa del ciclo de vida

Esperado: Categoría claramente asignada con fundamento documentado. En caso de fallo: Si la categoría es ambigua, usar la categoría superior y documentar el fundamento.

Paso 2: Redactar la Especificación de Requisitos de Usuario (URS)

Crear un documento URS con requisitos numerados:

# User Requirements Specification
## System: [System Name] v[Version]
## Document ID: URS-[SYS]-[NNN]

### 1. Purpose
[Intended use statement]

### 2. Functional Requirements
| ID | Requirement | Priority | Source |
|----|-------------|----------|--------|
| URS-001 | System shall calculate BMI from height and weight inputs | Must | Regulatory SOP-xxx |
| URS-002 | System shall generate audit trail entries for all data changes | Must | 21 CFR 11.10(e) |
| URS-003 | System shall export results in PDF format | Should | User request |

### 3. Non-Functional Requirements
| ID | Requirement | Priority | Source |
|----|-------------|----------|--------|
| URS-010 | System shall respond within 3 seconds for standard queries | Should | Usability |
| URS-011 | System shall restrict access via role-based authentication | Must | 21 CFR 11.10(d) |

### 4. Data Integrity Requirements
[ALCOA+ requirements: Attributable, Legible, Contemporaneous, Original, Accurate]

### 5. Regulatory Requirements
[Specific 21 CFR Part 11, EU Annex 11, or other applicable requirements]

Esperado: Todos los requisitos tienen IDs únicos, prioridades y trazabilidad a la fuente. En caso de fallo: Señalar para revisión de las partes interesadas los requisitos sin fuente o prioridad clara.

Paso 3: Realizar la Evaluación de Riesgo

Aplicar el enfoque basado en riesgo GAMP 5 usando un Análisis de Modos de Fallo y Efectos (FMEA):

# Risk Assessment
## Document ID: RA-[SYS]-[NNN]

| Req ID | Failure Mode | Severity (1-5) | Probability (1-5) | Detectability (1-5) | RPN | Risk Level | Mitigation |
|--------|-------------|----------------|-------------------|---------------------|-----|------------|------------|
| URS-001 | Incorrect BMI calculation | 4 | 2 | 1 | 8 | Low | OQ test case |
| URS-002 | Audit trail entries missing | 5 | 3 | 3 | 45 | High | IQ + OQ + monitoring |
| URS-011 | Unauthorized access | 5 | 2 | 2 | 20 | Medium | OQ test + periodic review |

Número de Prioridad de Riesgo (RPN) = Severidad x Probabilidad x Detectabilidad.

Rango RPN	Nivel de Riesgo	Requisito de Prueba
1–12	Bajo	Verificación básica
13–36	Medio	Caso de prueba documentado
37+	Alto	IQ/OQ/PQ completo con reprueba

Esperado: Cada requisito URS tiene una fila correspondiente en la evaluación de riesgo. En caso de fallo: Escalar al responsable de validación los requisitos sin evaluar antes de proceder.

Paso 4: Definir la Estrategia de Validación (Plan de Validación)

# Validation Plan
## Document ID: VP-[SYS]-[NNN]

### Scope
- System: [Name] v[Version]
- GAMP Category: [N]
- Validation approach: [Prospective / Retrospective / Concurrent]

### Qualification Stages
| Stage | Scope | Applies? | Rationale |
|-------|-------|----------|-----------|
| IQ | Installation correctness | Yes | Verify installation, dependencies, configuration |
| OQ | Operational requirements | Yes | Verify functional requirements from URS |
| PQ | Performance under real conditions | [Yes/No] | [Rationale] |

### Roles and Responsibilities
| Role | Name | Responsibility |
|------|------|---------------|
| Validation Lead | [Name] | Plan, coordinate, approve |
| Tester | [Name] | Execute test scripts |
| System Owner | [Name] | Approve for production use |
| QA | [Name] | Review and sign-off |

### Acceptance Criteria
- All critical test cases pass
- No unresolved critical or major deviations
- Traceability matrix complete

Esperado: Plan de validación aprobado por todas las partes interesadas antes de la ejecución de pruebas. En caso de fallo: No proceder a la ejecución de pruebas sin un plan de validación aprobado.

Paso 5: Crear Protocolos de Prueba (IQ/OQ/PQ)

Redactar scripts de prueba para cada etapa de calificación:

# Operational Qualification Protocol
## Test Case: TC-OQ-001
## Traces to: URS-001

**Objective:** Verify BMI calculation accuracy

**Prerequisites:**
- System installed per IQ protocol
- Test data set prepared

**Test Steps:**
| Step | Action | Expected Result | Actual Result | Pass/Fail |
|------|--------|-----------------|---------------|-----------|
| 1 | Enter height=180cm, weight=75kg | BMI displayed as 23.15 | | |
| 2 | Enter height=160cm, weight=90kg | BMI displayed as 35.16 | | |
| 3 | Enter height=0, weight=75kg | Error message displayed | | |

**Tester:** _________ Date: _________
**Reviewer:** _________ Date: _________

Esperado: Cada requisito de riesgo medio y alto tiene al menos un caso de prueba. En caso de fallo: Añadir los casos de prueba faltantes antes de que comience la ejecución.

Paso 6: Construir la Matriz de Trazabilidad

Crear una Matriz de Trazabilidad de Requisitos (RTM) que vincule cada requisito a través de la evaluación de riesgo hasta los casos de prueba:

# Traceability Matrix
## Document ID: TM-[SYS]-[NNN]

| URS ID | Requirement | Risk Level | Test Case(s) | Test Result | Status |
|--------|-------------|------------|--------------|-------------|--------|
| URS-001 | BMI calculation | Low | TC-OQ-001 | Pass | Verified |
| URS-002 | Audit trail | High | TC-IQ-003, TC-OQ-005 | Pass | Verified |
| URS-003 | PDF export | Low | TC-OQ-008 | Pass | Verified |
| URS-011 | Role-based access | Medium | TC-OQ-010, TC-OQ-011 | Pass | Verified |

Esperado: El 100% de los requisitos URS aparece en la matriz de trazabilidad con resultados de prueba vinculados. En caso de fallo: Cualquier requisito sin resultado de prueba vinculado se señala como una brecha de validación.

Paso 7: Redactar el Informe de Resumen de Validación

# Validation Summary Report
## Document ID: VSR-[SYS]-[NNN]

### 1. Executive Summary
[System name] v[version] has been validated in accordance with [VP document ID].

### 2. Validation Activities Performed
| Activity | Document ID | Status |
|----------|-------------|--------|
| User Requirements | URS-SYS-001 | Approved |
| Risk Assessment | RA-SYS-001 | Approved |
| Validation Plan | VP-SYS-001 | Approved |
| IQ Protocol/Report | IQ-SYS-001 | Executed — Pass |
| OQ Protocol/Report | OQ-SYS-001 | Executed — Pass |
| Traceability Matrix | TM-SYS-001 | Complete |

### 3. Deviations
| Dev ID | Description | Impact | Resolution |
|--------|-------------|--------|------------|
| DEV-001 | [Description] | [Impact assessment] | [Resolution and rationale] |

### 4. Conclusion
The system meets all user requirements as documented in [URS ID]. The validation is considered [Successful / Successful with conditions].

### 5. Approval
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Validation Lead | | | |
| System Owner | | | |
| Quality Assurance | | | |

Esperado: El informe hace referencia a todos los entregables de validación con una conclusión clara de aprobado/fallido. En caso de fallo: Si las desviaciones no están resueltas, el informe debe indicar el estado "condicional" con referencias CAPA.

Validación

• Categoría GAMP 5 asignada con fundamento documentado
• La URS tiene requisitos numerados con prioridades y trazabilidad a la fuente
• La evaluación de riesgo cubre cada requisito URS
• El plan de validación aprobado antes de la ejecución de pruebas
• Los protocolos de prueba tienen campos de prerrequisito, paso, resultado esperado y firma
• La matriz de trazabilidad vincula cada requisito con el riesgo y los resultados de prueba
• El informe de resumen de validación documenta todas las actividades, desviaciones y conclusión
• Todos los documentos tienen IDs únicos y control de versiones

Errores Comunes

• Sobrevalidación: Aplicar el esfuerzo de Categoría 5 al software de Categoría 3 desperdicia recursos. Ajustar el esfuerzo al riesgo.
• Trazabilidad faltante: Los requisitos que no se vinculan hasta los casos de prueba son brechas invisibles.
• Probar sin un plan: Ejecutar pruebas antes de que el plan de validación esté aprobado invalida los resultados.
• Ignorar los requisitos no funcionales: Los requisitos de seguridad, rendimiento e integridad de datos a menudo se pasan por alto.
• Validación estática: Tratar la validación como un evento único. Los cambios requieren reevaluación.

Habilidades Relacionadas

• setup-gxp-r-project

  — estructura del proyecto para entornos R validados

• write-validation-documentation

  — redacción de protocolos e informes IQ/OQ/PQ

• implement-audit-trail

  — implementación de registro de auditoría para registros electrónicos

• validate-statistical-output

  — metodología de verificación de salida estadística

• conduct-gxp-audit

  — auditoría de sistemas validados