Panel de detalle del evento de calidad
El panel de detalle concentra toda la información y acciones del evento. Las secciones aparecen progresivamente a medida que el evento avanza por el ciclo: triage, investigación, CAPA y verificación de efectividad.
Header del evento
Muestra el código, tipo, criticidad y estado del evento en una línea con badges de color. Debajo: título y descripción. Los botones disponibles son:
- ✏ Editar — visible para Admin/QA mientras el evento no esté cerrado. Abre el modal de edición, que permite modificar Título, Área, Asignado a, RCA y Notas internas.
- 🖨 Imprimir — genera el informe completo A4 del evento: metadatos, RCA, CAPA, extensiones y audit trail.
- Cerrar — cierra el panel de detalle.
Metadatos y vínculos
El bloque de metadatos muestra: área responsable, reportador, asignado, fecha de apertura, SLA asignado y fecha de vencimiento (recalculada al confirmarse el triage).
Si hay vínculos configurados, aparecen como chips bajo los metadatos:
- 🔗 CC vinculado — Change Control relacionado
- 📄 Doc vinculado — Documento CDMS relacionado
- 📣 Cliente: nombre — cliente externo involucrado
Advertencia de segregación. Si el reportador y el asignado son la misma persona, el sistema muestra una advertencia: "El reportador y el asignado son la misma persona. GMP recomienda segregación de funciones para la investigación." La situación no bloquea el proceso, pero debe estar justificada.
Cuando el evento tiene un documento CDMS vinculado, aparece el panel Documentos impactados con la lista de versiones y relaciones documentales asociadas a ese documento.
Panel de triage (estado Abierto)
Mientras el evento está en estado Abierto, el panel de detalle muestra el bloque de triage para Admin/QA. Contiene:
- Un selector de criticidad, precargado con la criticidad propuesta por el iniciador. QA puede confirmarla tal cual o corregirla.
- El botón Confirmar criticidad y firmar, que ejecuta la transición a Triage confirmado con firma electrónica.
Segregación de funciones en el triage. El usuario que confirma el triage no puede ser el mismo que reportó el evento: el sistema lo rechaza con un error 409. Al confirmar, el SLA y la fecha de vencimiento se recalculan con la criticidad confirmada, y la acción queda registrada como qem:triage_confirmed en el audit trail.
Avanzar el estado (bloque FSM)
Cuando el evento puede avanzar al siguiente estado (y el usuario es Admin/QA), aparece el bloque de avance con la etiqueta del próximo estado y las condiciones requeridas:
| Acción (botón en la UI) | De → a | Endpoint | Quién | Firma | Condiciones |
|---|---|---|---|---|---|
| Confirmar criticidad | Abierto → Triage confirmado | /confirm-triage | Admin / QA | 🔐 Sí | Confirmante ≠ reportante (409). Recalcula SLA y vencimiento. |
| Iniciar investigación | Triage confirmado → En investigación | /start-investigation | Admin / QA | Operativo | Selector opcional de investigador (recibe notificación). |
| Registrar causa raíz (RCA) | En investigación → En CAPA | /open-capa | Admin / QA | 🔐 Sí | RCA de mínimo 20 caracteres cargado vía ✏ Editar; si falta, el mensaje indica "Editar el evento primero". |
| Completar CAPA / Cerrar fase sin CAPA | En CAPA → Pend. efectividad | /complete-capa | Admin / QA | 🔐 Sí | Con acciones: todas completadas y vínculos verificados (AD-S67-001). Sin acciones: justificación ≥15 caracteres + firma. |
| Confirmar efectividad y cerrar | Pend. efectividad → Cerrado | /close | Admin / QA | 🔐 Sí | Comentario de efectividad ≥10 caracteres; CC vinculado debe estar closed; re-valida vínculos de CAPAs. |
| ↩ Rechazar efectividad | Pend. efectividad → En CAPA | /reject-effectiveness | Admin / QA | 🔐 Sí | Razón ≥15 caracteres. Conserva CAPAs y extensiones. |
| ↩ Reabrir para enmienda | Cerrado → Abierto | /reopen | Solo Admin | 🔐 Sí | Razón ≥15 caracteres. Preserva el historial en el audit trail. |
El botón de avance se muestra deshabilitado con un mensaje explicativo cuando la condición no se cumple. Por ejemplo, si el RCA no fue cargado o tiene menos de 20 caracteres, el sistema indica que hay que editar el evento primero.
Análisis de causa raíz (RCA)
El RCA no se carga inline en el panel: se registra desde el modal ✏ Editar del evento (campo RCA), y es editable mientras el evento no esté cerrado. Es obligatorio para avanzar a la fase CAPA (mínimo 20 caracteres); sin límite de extensión — documentá el análisis completo.
La transición Registrar causa raíz (RCA) sí se firma electrónicamente. Los cambios posteriores al texto del RCA quedan registrados como qem:event_updated en el audit trail, y el RCA se incluye en el informe impreso.
Verificación de efectividad
Cuando el evento está en Pend. efectividad, el propio bloque de avance muestra un textarea para el comentario de efectividad (mínimo 10 caracteres), que describe la evidencia de que las acciones CAPA fueron efectivas. Al confirmar con firma electrónica, el evento se cierra. Antes de cerrar, el sistema re-valida los vínculos de las CAPAs y exige que el CC vinculado (si existe) esté cerrado — no alcanza con que esté aprobado.
Si la verificación resulta negativa, el botón ↩ Rechazar efectividad devuelve el evento a En CAPA con razón de mínimo 15 caracteres y firma; las acciones CAPA y las extensiones existentes se conservan (qem:effectiveness_rejected en el audit trail).
Si el evento ya está cerrado, esta sección muestra el comentario de efectividad registrado (en fondo verde) como referencia histórica.
Notas internas
Las notas internas se editan desde el modal ✏ Editar y son visibles para Admin/QA mientras el evento no está cerrado. Permiten registrar observaciones, pendientes, consultas y cualquier información adicional que no forma parte del RCA formal. Son de solo lectura para roles no-admin.
Acciones CAPA
La sección de acciones CAPA muestra el contador de acciones completadas/total y el listado de todas las acciones registradas.
Crear una acción CAPA
Admin/QA pueden agregar acciones haciendo clic en + Agregar. Campos del formulario:
| Campo | Descripción |
|---|---|
Tipo de CAPA (capa_type) | Correctiva — elimina la causa del problema. Preventiva — evita que ocurra en otros contextos. Inmediata — acción de contención rápida. |
Tipo de acción (action_type) | Estructura la acción y determina qué vínculos admite. Ver tabla siguiente. |
| Descripción | Qué se va a hacer. Debe ser específico y medible. |
| Responsable | Email del usuario responsable de ejecutar la acción. |
| Fecha límite | Plazo para completar la acción. Las acciones vencidas se destacan. |
Tipo de acción estructurado (S67)
| Tipo de acción | Código | Vínculos que admite |
|---|---|---|
| Entrenamiento | training | Solo training items del TMS (training_item). |
| Cambio de proc./doc. | procedure_change | Solo Change Controls del CCM (change_control). |
| Acción directa | direct_action | No admite vínculos. Se completa con evidencia y firma. |
El action_type es editable mientras la acción está abierta e inmutable una vez completada. Al cambiarlo, los vínculos existentes se eliminan (porque el nuevo tipo admite otra clase de vínculo). El cambio queda registrado como qem:capa_type_changed en el audit trail.
Vínculos bloqueantes
Los vínculos son bloqueantes: la acción no puede marcarse como completada hasta que todos estén verificados. Para agregar un vínculo: hacé clic en el botón + de la acción → buscá el training o CC por código o título → confirmá. El vínculo aparece en la lista de la acción con su estado actual (pendiente 🔴 / verificado ✅).
Mientras la acción no esté completada, podés eliminar vínculos desde el panel de vínculos de la acción. Las acciones en sí son append-only: no se eliminan, solo se completan.
AD-S67-001 — Verificación bloqueante obligatoria. Todos los vínculos de una acción CAPA deben estar verificados antes de poder completar la acción. No hay forma de saltear esta verificación. Es un invariante del sistema.
Ver Completar acción CAPA para el detalle del modal de completación (verificación de vínculos, evidencia y firma).
Adjuntos
El evento admite archivos adjuntos en dos niveles: a nivel del evento y a nivel de cada acción CAPA. Características:
- Subida directa al almacenamiento (URL presignada de R2), con tamaño máximo de 50 MB por archivo.
- Cada archivo queda registrado con su hash SHA-256 para integridad.
- Pueden adjuntar los usuarios Admin, QA o el reportante del evento.
- No se pueden agregar adjuntos si el evento está cerrado.
- Cada subida queda registrada como
qem:attachment_addeden el audit trail.
Extensiones de plazo
Si el SLA original no es suficiente para resolver el evento, podés registrar una extensión de plazo. La sección de extensiones (visible para Admin/QA cuando el evento no está cerrado) muestra el historial de extensiones — que es append-only — y un formulario para agregar una nueva.
Campos de la extensión:
- Nueva fecha de vencimiento: debe ser posterior a la fecha de vencimiento actual; si no, el sistema la rechaza con un error 409.
- Justificación regulatoria — mínimo 10 caracteres. Describí el motivo del retraso y las acciones que se están tomando.
Cada extensión queda registrada como qem:extension_granted en el audit trail con la fecha anterior, la nueva fecha y el solicitante. El badge SLA se recalcula con la nueva fecha de vencimiento.
Las extensiones documentan pero no borran el registro del SLA original vencido. Ambos datos coexisten en el audit trail para transparencia regulatoria. Esto es una característica, no un error.
Preguntas frecuentes
No hay límite. Podés agregar tantas acciones como el análisis requiera. El contador "X/Y completadas" te muestra el progreso. Para avanzar de En CAPA a Pend. efectividad, todas las acciones deben estar completadas — si hay acciones con vínculos sin verificar, no podés avanzar. Si en cambio no registrás ninguna acción, podés cerrar la fase con Cerrar fase sin CAPA (justificación ≥15 caracteres + firma).
No. Las acciones CAPA son append-only: no pueden eliminarse, solo completarse. Si creaste una acción por error, documentá la situación en la evidencia al completarla o en las notas internas del evento. Lo que sí podés eliminar, mientras la acción no esté completada, son sus vínculos desde el panel de vínculos.
Sí, mientras la acción no esté completada. Tené en cuenta que al cambiar el action_type se eliminan los vínculos existentes de la acción, porque cada tipo admite una clase de vínculo distinta. Una vez completada la acción, el tipo queda inmutable. El cambio queda registrado como qem:capa_type_changed en el audit trail.
Los usuarios Admin, QA y también el reportante del evento, tanto a nivel evento como en cada acción CAPA, mientras el evento no esté cerrado. El límite es 50 MB por archivo y cada adjunto queda registrado con su hash SHA-256 en el audit trail.