CCM — Control de Cambios
El Change Control es el mecanismo regulatorio que asegura que toda modificación al sistema de calidad sea evaluada, aprobada formalmente y verificada post-implementación antes de considerarse cerrada.
¿Qué es un Change Control?
Un CC documenta una solicitud de cambio: puede afectar procedimientos, equipos, proveedores, instalaciones, métodos de análisis u otras variables del sistema de calidad. El proceso garantiza que el cambio fue analizado por todas las áreas impactadas, aprobado por los responsables correspondientes, implementado correctamente y verificado.
El CC tiene 6 pestañas de información: Resumen, Assessments (evaluaciones por área), Tareas, Aprobaciones, Verificación y SOPs/IDTs (documentos vinculados).
Tipos de cambio
Al crear el CC elegís uno de los tres tipos de cambio. El tipo define qué roles deben firmar la aprobación:
| Tipo | Código | Criterio | Aprobadores requeridos |
|---|---|---|---|
| Minor | minor | Bajo impacto, sin afectación de procesos regulados críticos | QA Lead |
| Major | major | Impacto significativo en documentos, procesos o equipos regulados | Responsable de área + QA Lead + Gerencia técnica |
| Crítico | critical | Afecta validaciones, calificaciones o compromisos con clientes GMP | Responsable de área + QA Lead + Gerencia |
Admin/QA pueden corregir el tipo después de creado el CC haciendo clic en el badge de tipo del header del detalle, mientras el CC esté en Borrador o En assessment.
Estados del Change Control
| Estado | Código | Significado | Salidas posibles |
|---|---|---|---|
| Borrador | draft | CC creado, editable. Aún no enviado a evaluación. | Enviar a evaluación · Cancelar |
| En assessment | in_assessment | Las áreas impactadas evalúan el cambio y los aprobadores firman sus aprobaciones. | Auto-aprobación (al firmar la última aprobación) · Rechazar 🔐 · Cancelar |
| Aprobado | approved | El CC fue aprobado. Listo para implementación. | Iniciar ejecución |
| En ejecución | in_execution | El cambio se está implementando (tareas). | Enviar a verificación |
| En verificación | in_verification | Se verifica que el cambio fue implementado correctamente. | Confirmar y cerrar · vuelve a En ejecución si la verificación falla |
| Cerrado | closed | Cambio implementado y verificado. CC completo. | Reabrir → Borrador |
| Cancelado | cancelled | CC abandonado antes de completarse (no es un juicio sobre el mérito del cambio). | Reabrir → Borrador |
| Rechazado | rejected | Decisión formal, con firma, de que el cambio no procede. | Reabrir → Borrador |
Flujo completo y transiciones
Detalles de las transiciones
| Acción (label en la UI) | De → A | Endpoint | ¿Quién? | ¿Firma 🔐? | Condiciones / notas |
|---|---|---|---|---|---|
| Enviar a evaluación | Borrador → En assessment | submit | Admin/QA | No (comentario opcional) | — |
| (automática — no hay botón) | En assessment → Aprobado | — (al resolver la última aprobación) | — | La firma está en cada aprobación individual 🔐 | Se ejecuta sola cuando todos los roles requeridos por el tipo firmaron "aprobado" |
| Rechazar CC | En assessment → Rechazado | reject | Admin/QA | ✅ Sí (reautenticación) | Razón obligatoria ≥ 15 caracteres. Decisión formal sobre el mérito del cambio. |
| Cancelar CC | Borrador / En assessment → Cancelado | cancel | Admin/QA | No (operativa) | Razón obligatoria ≥ 15 caracteres. Abandono del trámite. |
| Iniciar ejecución | Aprobado → En ejecución | start-execution | Admin/QA | No (comentario opcional) | — |
| Enviar a verificación | En ejecución → En verificación | start-verification | Admin/QA | No (comentario opcional) | Bloqueada mientras haya tareas sin resolver (deben estar completadas o dispensadas) |
| Confirmar y cerrar | En verificación → Cerrado | close | Admin/QA | No (operativa) | La firma regulada ocurrió al completar la verificación con resultado "Aprobado" |
| (automática) | En verificación → En ejecución | — | — | — | Si la verificación se completa con resultado "Fallido" |
| Reabrir | Cerrado / Cancelado / Rechazado → Borrador | reopen | Admin/QA | No (operativa) | Justificación obligatoria ≥ 15 caracteres; queda en el audit trail |
No existe el botón "Aprobar CC". La aprobación del CC es automática: cuando el último rol requerido por el tipo de cambio firma su aprobación individual (tab Aprobaciones), el CC pasa solo de En assessment a Aprobado. Si un rol resolvió más de una vez, la última decisión de cada rol es la que vale.
¿El CC quedó trabado en assessment? Si un aprobador rechazó su aprobación o nunca la resuelve, el CC no queda atrapado: en En assessment siempre están disponibles Rechazar CC (con firma, cierra formalmente el cambio como no procedente) y Cancelar CC (abandono del trámite, sin firma). Ambas piden una razón de al menos 15 caracteres.
Separación de funciones. El solicitante del CC no puede avanzar el CC cuando está En assessment ni resolver aprobaciones de su propio CC. Esto previene que quien solicita el cambio sea también quien lo aprueba — principio GMP fundamental.
Firmas: qué pide reautenticación
Solo tres acciones del CCM son firmas reguladas con reautenticación (contraseña):
- Aprobar una aprobación (tab Aprobaciones, decisión "Aprobado")
- Completar la verificación con resultado "Aprobado" (passed)
- Rechazar el CC
El resto de las acciones (enviar a evaluación, iniciar ejecución, enviar a verificación, confirmar y cerrar, cancelar, reabrir, rechazar una aprobación individual) son operativas: abren el mismo modal pero solo con un comentario opcional, sin contraseña. En las acciones con motivo obligatorio (rechazar, cancelar, cerrar, reabrir) el modal ofrece motivos sugeridos precargados para elegir con un clic. Ver Firma electrónica.
CCs generados automáticamente
El CDMS genera CCs automáticamente cuando se trabaja sobre documentos regulados:
- Creación de un documento nuevo (v1.0): al crear un SOP o IDT, el sistema crea un CC en Borrador vinculado a ese documento.
- Nueva versión de un documento vigente: al iniciar una nueva versión de un SOP o IDT, también se crea un CC vinculado.
Los CCs automáticos se identifican porque el tab Resumen muestra el campo Documento origen con link directo al documento, y en el tab SOPs/IDTs el vínculo lleva el badge auto-generado. El CC debe resolverse antes de que el documento pueda efectivizarse.
Lista de CCs y filtros
La pantalla principal del CCM muestra los CCs en una lista con contadores por estado y buscador por código, título o solicitante. Los CCs con fecha de vencimiento próxima o vencida se destacan visualmente. Al hacer clic en un CC se abre el panel de detalle.
Preguntas frecuentes
Sí. Si existe un CC activo (no cerrado/cancelado/rechazado) vinculado a un documento del CDMS, el sistema bloquea la efectivización de ese documento hasta que el CC se resuelva. Esto asegura que los cambios documentales estén formalmente aprobados antes de entrar en vigencia.
El CC permanece En assessment: la auto-aprobación solo ocurre cuando todos los roles requeridos firmaron "aprobado". El aprobador puede volver a resolver (la última decisión de cada rol es la que vale), o Admin/QA pueden salir del impasse con Rechazar CC (firma + razón) o Cancelar CC (razón, sin firma).
Rechazado es una decisión formal sobre el mérito del cambio: se firma con reautenticación y queda como pronunciamiento de que el cambio no procede. Cancelado es el abandono operativo del trámite (por ejemplo, un CC duplicado o que perdió sentido): pide razón pero no firma.
Sí. Admin/QA pueden usar Reabrir desde cualquiera de los tres estados terminales. El CC vuelve a Borrador, editable, con una justificación obligatoria de al menos 15 caracteres que queda registrada en el audit trail. No requiere reautenticación.
El tab Assessments muestra la advertencia "⛔ Hay assessments bloqueantes". El bloqueo queda registrado y es responsabilidad del equipo de QA gestionar su resolución antes de que los aprobadores firmen — la advertencia no impide técnicamente que las aprobaciones se resuelvan.