QEM — Quality Event Manager
El QEM registra y gestiona todos los eventos de calidad del laboratorio. Cada evento pasa por un triage de criticidad confirmado por QA, un ciclo de investigación (RCA), una fase CAPA (opcional con justificación) y una verificación de efectividad antes del cierre. Las transiciones críticas requieren firma electrónica.
Tipos de evento de calidad
| Tipo | Código | Cuándo usarlo |
|---|---|---|
| Desvío | deviation | Apartamiento de un procedimiento o especificación aprobado, detectado antes o durante la ejecución de un ensayo o proceso. |
| Discrepancia | discrepancy | Diferencia o inconsistencia entre documentos, datos o resultados que requiere investigación. |
| No conformidad | non_conformity | Incumplimiento documentado de un requisito de norma, regulación o procedimiento interno. |
| Reclamo | complaint | Retroalimentación negativa de un cliente o parte interesada sobre la calidad del servicio o resultado. |
| Obs. de auditoría | audit_observation | Observación surgida de una auditoría interna o externa que requiere seguimiento en el QEM. |
Estados del evento y sistema de SLA
El ciclo de vida del evento tiene seis estados:
| Estado | Código | SLA activo | Descripción |
|---|---|---|---|
| Abierto | open | ✅ Sí | Evento registrado con una criticidad propuesta por el iniciador. El SLA comienza a correr desde la apertura. Espera el triage de QA. |
| Triage confirmado | triaged | ✅ Sí | QA confirmó (o corrigió) la criticidad con firma electrónica. El SLA y la fecha de vencimiento se recalcularon con la criticidad definitiva. |
| En investigación | under_investigation | ✅ Sí | Se está analizando la causa raíz. El RCA se carga desde el modal ✏ Editar del evento. |
| En CAPA | in_capa | ✅ Sí | RCA registrado y firmado. Las acciones correctivas/preventivas están siendo ejecutadas (o se justifica formalmente que no hacen falta). |
| Pend. efectividad | pending_effectiveness | ❌ No | Fase CAPA cerrada. Período de verificación de que las acciones surtieron efecto. El SLA no corre en este estado. |
| Cerrado | closed | — | Efectividad confirmada con firma. Evento resuelto y cerrado. Solo un Admin puede reabrirlo para enmienda. |
Cómo funciona el SLA
El SLA define el tiempo máximo en horas para resolver el evento según su criticidad: Crítico 24 h · Mayor 48 h · Menor 72 h · Observación sin SLA. La fecha de vencimiento (due_date) se calcula como fecha de apertura + SLA, y se recalcula en el triage si QA corrige la criticidad propuesta.
El badge SLA en la lista y en el panel de detalle indica:
- SLA ok — quedan más de 12 horas para el vencimiento
- SLA próximo — quedan 12 horas o menos (el umbral es fijo de 12 horas, independiente de la criticidad)
- SLA vencido +Nd — se superó la fecha de vencimiento. Muestra cuántos días de retraso hay.
Los estados Pend. efectividad y Cerrado quedan fuera del cálculo de SLA: en ellos el proceso de investigación y CAPA ya cumplió su objetivo, por lo que el badge no muestra "SLA vencido" aunque el tiempo total haya superado las horas originales.
Además, un job nocturno genera alertas de SLA próximo y SLA vencido, con umbrales configurables por criticidad desde Admin QEM.
Flujo FSM completo
Tabla de transiciones
| Acción (botón en la UI) | De → a | Endpoint | Quién | Firma | Condiciones |
|---|---|---|---|---|---|
| Confirmar criticidad | Abierto → Triage confirmado | POST /qem/{id}/confirm-triage | Admin / QA | 🔐 Sí | QA confirma o corrige la criticidad propuesta por el iniciador. Segregación: el confirmante no puede ser el reportante (error 409). Recalcula SLA y fecha de vencimiento. |
| Iniciar investigación | Triage confirmado → En investigación | /start-investigation | Admin / QA | Operativo | Selector opcional de investigador; si se asigna, el investigador recibe una notificación. |
| Registrar causa raíz (RCA) | En investigación → En CAPA | /open-capa | Admin / QA | 🔐 Sí | Requiere RCA de mínimo 20 caracteres, cargado desde el modal ✏ Editar (no inline). Si falta, el sistema indica "Editar el evento primero". |
| Completar CAPA / Cerrar fase sin CAPA | En CAPA → Pend. efectividad | /complete-capa | Admin / QA | 🔐 Sí | Con acciones CAPA: todas completadas y con vínculos verificados (AD-S67-001). Sin ninguna acción (CAPA opcional): modal de justificación de mínimo 15 caracteres + firma. |
| Confirmar efectividad y cerrar | Pend. efectividad → Cerrado | /close | Admin / QA | 🔐 Sí | Comentario de efectividad ≥10 caracteres. Si hay CC vinculado, debe estar cerrado (closed — no alcanza approved). Re-valida los vínculos de las CAPAs. |
| ↩ Rechazar efectividad | Pend. efectividad → En CAPA | /reject-effectiveness | Admin / QA | 🔐 Sí | Razón de mínimo 15 caracteres. Conserva las acciones CAPA y las extensiones de plazo existentes. |
| ↩ Reabrir para enmienda | Cerrado → Abierto | /reopen | Solo Admin | 🔐 Sí | Razón de mínimo 15 caracteres. Preserva el historial: closed_at se limpia pero queda registrado en el audit trail. |
Las transiciones marcadas 🔐 requieren firma electrónica (re-autenticación). Cada una queda registrada en el audit trail; entre otras: qem:triage_confirmed, qem:effectiveness_rejected y qem:event_reopened.
Crear un evento de calidad
Hacé clic en + Nuevo evento. Completá el formulario:
| Campo | Oblig. | Descripción |
|---|---|---|
| Tipo | ✅ | Ver la tabla de tipos de evento arriba. |
| Criticidad | ✅ | Crítico / Mayor / Menor / Observación. Es una propuesta: QA la confirma o corrige en el triage con firma electrónica, y recién ahí queda definitiva (y se recalcula el SLA). |
| Título | ✅ | Descripción concisa del evento (mínimo 5 caracteres). Debe identificar el problema. |
| Descripción | ✅ | Detalle del evento: qué ocurrió, cómo se detectó, qué estaba pasando (mínimo 10 caracteres). |
| Área responsable | ✅ | Área a cargo de gestionar la investigación y CAPA. |
| Cliente | No | Si el evento involucra a un cliente externo, registrá su nombre aquí. |
| CC vinculado | No | Change Control relacionado con el evento. |
| Documento vinculado | No | SOP o IDT relacionado con el evento. Permite ver documentos impactados en el panel. |
El investigador no se asigna al crear el evento: la asignación ocurre recién en la transición Iniciar investigación, con un selector opcional.
Al crear un evento se notifica a todos los usuarios QA y Admin, sea cual sea la criticidad. La criticidad propuesta solo cambia la prioridad del aviso, no sus destinatarios.
Lista de eventos y KPIs
La pantalla principal del QEM muestra estas métricas en la barra superior:
- Eventos activos: total de eventos que no están cerrados
- Críticos activos: eventos con criticidad Crítica en estados activos
- SLA vencidos: eventos en estados activos (excluyendo Pend. efectividad) que superaron su SLA
- Pend. cierre: eventos en estado Pend. efectividad, esperando la verificación de efectividad
La lista muestra los eventos agrupados por tipo. Al hacer clic en un evento se abre el panel de detalle.
Notificaciones del módulo
| Notificación | Cuándo se envía | Destinatarios |
|---|---|---|
qem_event_created | Al crear un evento | Todos los QA y Admin (prioridad según criticidad) |
qem_event_assigned | Al asignar investigador en Iniciar investigación | El asignado |
qem_event_closed | Al cerrar el evento | Reportante + asignado |
qem_sla_warning / qem_sla_overdue | Job nocturno de SLA (umbrales configurables por criticidad en Admin QEM) | Equipo QA / Admin |
Preguntas frecuentes
El iniciador propone una criticidad al crear el evento, pero la criticidad definitiva la confirma (o corrige) QA en el triage, con firma electrónica. Por segregación de funciones, quien confirma el triage no puede ser el mismo usuario 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.
El evento queda marcado como "SLA vencido" con el conteo de días de retraso, y el job nocturno envía notificaciones automáticas. El vencimiento queda en el registro pero no bloquea el proceso — podés seguir avanzando el evento normalmente. Podés registrar una extensión de plazo con justificación para documentar el motivo del retraso.
Sí. La fase CAPA es opcional: si el evento no tiene ninguna acción CAPA registrada, el botón Cerrar fase sin CAPA abre un modal que exige una justificación de mínimo 15 caracteres más firma electrónica. Si en cambio hay acciones registradas, todas deben completarse (con sus vínculos verificados) antes de poder avanzar.
Sí, pero solo un usuario con rol Admin, mediante ↩ Reabrir para enmienda, con razón de mínimo 15 caracteres y firma electrónica. El evento vuelve al estado Abierto conservando todo su historial: la fecha de cierre se limpia del evento pero queda registrada en el audit trail (qem:event_reopened).