Gestionar Control de Cambios

Evaluar, aprobar, implementar y verificar los cambios en los sistemas informatizados validados manteniendo su estado validado.

Cuándo Usar

• Un sistema validado requiere una actualización de software, parche o cambio de configuración
• Los cambios de infraestructura (migración de servidor, actualización de SO, cambio de red) afectan a sistemas validados
• Una CAPA o hallazgo de auditoría requiere modificación del sistema
• Los cambios en los procesos de negocio requieren reconfiguración del sistema
• Los cambios de emergencia necesitan aprobación expedita y documentación retrospectiva

Entradas

• Requerido: Descripción del cambio (qué está cambiando y por qué)
• Requerido: Sistema(s) afectado(s) y su estado validado actual
• Requerido: Solicitante del cambio y justificación del negocio
• Opcional: Notas de versión del proveedor o documentación técnica
• Opcional: Referencias a CAPA o hallazgos de auditoría relacionados
• Opcional: Documentación de validación existente para el(los) sistema(s) afectado(s)

Procedimiento

Paso 1: Crear y Clasificar la Solicitud de Cambio

# Change Request
## Document ID: CR-[SYS]-[YYYY]-[NNN]

### 1. Change Description
**Requestor:** [Name, Department]
**Date:** [YYYY-MM-DD]
**System:** [System name and version]
**Current State:** [Current configuration/version]
**Proposed State:** [Target configuration/version]

### 2. Justification
[Business, regulatory, or technical reason for the change]

### 3. Classification
| Type | Definition | Approval Path | Timeline |
|------|-----------|--------------|----------|
| **Emergency** | Urgent fix for safety, data integrity, or regulatory compliance | System owner + QA (retrospective CCB) | Implement immediately, document within 5 days |
| **Standard** | Planned change with potential impact on validated state | CCB approval before implementation | Per CCB schedule |
| **Minor** | Low-risk change with no impact on validated state | System owner approval | Documented before implementation |

**This change is classified as:** [Emergency / Standard / Minor]
**Rationale:** [Why this classification]

Esperado: La solicitud de cambio tiene un ID único, una descripción clara y una clasificación justificada. En caso de fallo: Si la clasificación está en disputa, usar Estándar y dejar que el CCB tome la decisión.

Paso 2: Realizar la Evaluación de Impacto

Evaluar el cambio frente a todas las dimensiones del estado validado:

# Impact Assessment
## Change Request: CR-[SYS]-[YYYY]-[NNN]

### Impact Matrix
| Dimension | Affected? | Details | Risk |
|-----------|-----------|---------|------|
| Software configuration | Yes/No | [Specific parameters changing] | [H/M/L] |
| Source code | Yes/No | [Modules, functions, or scripts affected] | [H/M/L] |
| Database schema | Yes/No | [Tables, fields, constraints changing] | [H/M/L] |
| Infrastructure | Yes/No | [Servers, network, storage affected] | [H/M/L] |
| Interfaces | Yes/No | [Upstream/downstream system connections] | [H/M/L] |
| User access/roles | Yes/No | [Role changes, new access requirements] | [H/M/L] |
| SOPs/work instructions | Yes/No | [Procedures requiring update] | [H/M/L] |
| Training | Yes/No | [Users requiring retraining] | [H/M/L] |
| Data migration | Yes/No | [Data transformation or migration needed] | [H/M/L] |
| Audit trail | Yes/No | [Impact on audit trail continuity] | [H/M/L] |

### Regulatory Impact
- [ ] Change affects 21 CFR Part 11 controls
- [ ] Change affects EU Annex 11 controls
- [ ] Change affects data integrity (ALCOA+)
- [ ] Change requires regulatory notification

Esperado: Cada dimensión está evaluada con un sí/no claro y fundamento. En caso de fallo: Si el impacto no puede determinarse sin pruebas, clasificar la dimensión como "Desconocido — requiere investigación" y exigir una evaluación en entorno de prueba antes del cambio en producción.

Paso 3: Determinar el Alcance de la Revalidación

Basándose en la evaluación de impacto, definir qué actividades de validación son necesarias:

# Revalidation Determination

| Revalidation Level | Criteria | Activities Required |
|--------------------|----------|-------------------|
| **Full revalidation** | Core functionality changed, new GAMP category, or major version upgrade | URS review, RA update, IQ, OQ, PQ, TM update, VSR |
| **Partial revalidation** | Specific functions affected, configuration changes | Targeted OQ for affected functions, TM update |
| **Documentation only** | No functional impact, administrative changes | Update validation documents, change log entry |
| **None** | No impact on validated state (e.g., cosmetic change) | Change log entry only |

### Determination for CR-[SYS]-[YYYY]-[NNN]
**Revalidation level:** [Full / Partial / Documentation only / None]
**Rationale:** [Specific reasoning based on impact assessment]

### Required Activities
| Activity | Owner | Deadline |
|----------|-------|----------|
| [e.g., Execute OQ test cases TC-OQ-015 through TC-OQ-022] | [Name] | [Date] |
| [e.g., Update traceability matrix for URS-007] | [Name] | [Date] |
| [e.g., Update SOP-LIMS-003 section 4.2] | [Name] | [Date] |

Esperado: El alcance de la revalidación es proporcional al impacto del cambio — ni más ni menos. En caso de fallo: Si el alcance de la revalidación está en disputa, errar del lado de más pruebas. La subvalidación es un riesgo regulatorio; la sobrevalidación es solo un costo de recursos.

Paso 4: Obtener la Aprobación

Dirigir el cambio a través del flujo de trabajo de aprobación apropiado:

# Change Approval

### Approval for: CR-[SYS]-[YYYY]-[NNN]

| Role | Name | Decision | Signature | Date |
|------|------|----------|-----------|------|
| System Owner | | Approve / Reject / Defer | | |
| QA Representative | | Approve / Reject / Defer | | |
| IT Representative | | Approve / Reject / Defer | | |
| Validation Lead | | Approve / Reject / Defer | | |

### Conditions (if any)
[Any conditions attached to the approval]

### Planned Implementation Window
- **Start:** [Date/Time]
- **End:** [Date/Time]
- **Rollback deadline:** [Point of no return]

Esperado: Todos los aprobadores requeridos han firmado antes de que comience la implementación (excepto los cambios de emergencia). En caso de fallo: Para cambios de emergencia, obtener aprobación verbal del propietario del sistema y Aseguramiento de Calidad, implementar el cambio y completar la documentación formal dentro de los 5 días hábiles.

Paso 5: Implementar y Verificar

Ejecutar el cambio y realizar la verificación posterior al cambio:

# Implementation Record

### Pre-Implementation
- [ ] Backup of current system state completed
- [ ] Rollback procedure documented and tested
- [ ] Affected users notified
- [ ] Test environment validated (if applicable)

### Implementation
- **Implemented by:** [Name]
- **Date/Time:** [YYYY-MM-DD HH:MM]
- **Steps performed:** [Detailed implementation steps]
- **Deviations from plan:** [None / Description]

### Post-Change Verification
| Verification | Result | Evidence |
|--------------|--------|----------|
| System accessible and functional | Pass/Fail | [Screenshot/log reference] |
| Changed functionality works as specified | Pass/Fail | [Test case reference] |
| Unchanged functionality unaffected (regression) | Pass/Fail | [Test case reference] |
| Audit trail continuity maintained | Pass/Fail | [Audit trail screenshot] |
| User access controls intact | Pass/Fail | [Access review reference] |

### Closure
- [ ] All verification activities completed successfully
- [ ] Validation documents updated per revalidation determination
- [ ] SOPs updated and effective
- [ ] Training completed for affected users
- [ ] Change record closed in change control system

Esperado: La implementación coincide con el plan aprobado, y todas las actividades de verificación pasan. En caso de fallo: Si la verificación falla, ejecutar el procedimiento de reversión inmediatamente y documentar el fallo como una desviación. No proceder sin la conformidad de Aseguramiento de Calidad.

Validación

• La solicitud de cambio tiene ID único, descripción y clasificación
• La evaluación de impacto cubre todas las dimensiones (software, datos, infraestructura, SOPs, formación)
• El alcance de la revalidación está definido con fundamento
• Todas las aprobaciones requeridas obtenidas antes de la implementación (o dentro de 5 días para emergencias)
• Copia de seguridad previa a la implementación y procedimiento de reversión documentados
• La verificación posterior al cambio demuestra que el cambio funciona y nada más se rompió
• Los documentos de validación actualizados para reflejar el cambio
• El registro de cambio formalmente cerrado

Errores Comunes

• Omitir la evaluación de impacto para cambios "pequeños": Incluso los cambios menores pueden tener impactos inesperados. Un interruptor de configuración que parece inofensivo puede deshabilitar un registro de auditoría o cambiar un cálculo.
• Abuso de cambios de emergencia: Si más del 10% de los cambios se clasifican como "emergencia", el proceso de cambio está siendo eludido. Revisar y endurecer los criterios de emergencia.
• Planificación de reversión incompleta: Asumir que la reversión es "simplemente restaurar la copia de seguridad" ignora los datos creados entre la copia de seguridad y la reversión. Definir la disposición de los datos para cada escenario de reversión.
• Aprobación después de la implementación: La aprobación retrospectiva (excepto para emergencias documentadas) es una violación de cumplimiento. El CCB debe aprobar antes de que comience el trabajo.
• Falta de pruebas de regresión: Verificar solo la funcionalidad modificada es insuficiente. Las pruebas de regresión deben confirmar que las funciones validadas existentes permanecen sin afectación.

Habilidades Relacionadas

• design-compliance-architecture

  — define el marco de gobernanza incluyendo el comité de control de cambios

• write-validation-documentation

  — crear la documentación de revalidación desencadenada por los cambios

• perform-csv-assessment

  — reevaluación CSV completa para cambios importantes que requieren revalidación total

• write-standard-operating-procedure

  — actualizar los SOPs afectados por el cambio

• investigate-capa-root-cause

  — cuando los cambios son desencadenados por CAPA