Investigación de queja

1. Objetivo

Establecer cómo se investiga una queja desde que Soporte la recibe hasta que se registra una conclusión que permita responder al socio y, si corresponde, derivarla a una no conformidad.

2. Alcance

Cubre la investigación: asignación de responsable, análisis de antecedentes, transiciones de estado y monitoreo de plazos.

No cubre:

• la apertura del ticket → [[wiki/entities/dispensai/protocolos/CAL-002]];
• la autoapertura por evaluación baja → [[wiki/entities/dispensai/protocolos/CAL-003]];
• la respuesta y el cierre → [[wiki/entities/dispensai/protocolos/CAL-005]];
• la derivación formal a no conformidad → CAL-006.

3. Definiciones

• Investigación: proceso de identificar qué ocurrió, por qué y qué acción corresponde, antes de responder al socio.
• Responsable: persona con acceso activo asignada a la gestión de la queja.
• Umbral de plazo: días máximos antes de que el sistema genere una alerta. Varía según prioridad: media 15 días, alta 7 días, crítica 3 días.
• NC automática: no conformidad creada por el sistema cuando una queja crítica supera el umbral sin resolverse.
• Historial de workflow: registro de cada transición de estado con usuario, fecha y motivo. El código lo escribe en iso_workflows, tabla que hoy no existe — ver brecha 4 en §17.

4. Roles y responsables

Rol	Responsabilidad
Soporte	Asigna la queja, conduce la investigación y registra las notas internas.
Calidad	Supervisión del plazo y derivación a NC cuando corresponda.
Sistema	Valida las transiciones de estado, registra el historial y genera alertas por plazo.
Responsable asignado	Tiene la queja en su nombre; es quien responde ante la alerta.

5. Disparador de inicio

El ticket llega a estado open —por CAL-002 o CAL-003— y Soporte lo asigna a un responsable para investigación. El disparador formal es la transición open → in_investigation registrada en el sistema.

6. Requisitos previos

• El ticket existe en service_complaints con estado open.
• Existe al menos un responsable de Soporte o Calidad con acceso activo en el sistema.
• El módulo de workflow de quejas (lib/iso-workflows.ts) está operativo.

7. Entradas

• Ticket con folio, descripción, categoría y prioridad.
• Antecedentes adjuntos por el socio.
• Historial de mensajes previos, si los hay.
• Datos de la dispensación o producto asociados, si la queja los vincula.

8. Procedimiento paso a paso

1. Soporte revisa el ticket y designa a un responsable (assigned_to_user_id).
2. El responsable cambia el estado a in_investigation. El sistema valida que la transición open → in_investigation sea permitida; si el ticket está en otro estado incompatible, la solicitud de cambio se rechaza.
3. El sistema intenta registrar la transición con usuario, fecha y motivo. Hoy ese registro no se produce: la tabla destino no existe (ver brecha 4 en §17). El estado del ticket sí queda en service_complaints; lo que se pierde es la traza de quién lo cambió y cuándo.
4. El responsable revisa los antecedentes: descripción, categoría, dispensación vinculada, evaluaciones previas del producto y notas internas anteriores.
5. El responsable registra su hipótesis de causa raíz en notas internas (no visibles para el socio).
6. Si la investigación requiere más datos, el responsable puede solicitar información adicional al socio mediante un mensaje visible en el ticket.
7. Al concluir la investigación, el responsable avanza el estado a in_progress para preparar la respuesta. Desde ahí continúa [[wiki/entities/dispensai/protocolos/CAL-005]].
8. Paralelamente, el código monitorea el plazo y, al superarse el umbral según prioridad, intenta generar una alerta queja_sin_resolver; si la queja es crítica y supera 3 días, intenta crear una no conformidad vinculada. Ninguna de las dos escrituras tiene destino hoy — iso_alerts y service_non_conformities fueron eliminadas (brecha 4 en §17). El seguimiento de plazo es, en la práctica, humano: Calidad revisa los tickets abiertos en service_complaints.

9. Puntos de control

#	Control	Momento
C1	Responsable asignado antes de iniciar investigación	Paso 1
C2	Transición in_investigation válida — la validación opera; el registro del historial no (brecha 4)	Paso 2-3
C3	Antecedentes revisados antes de concluir	Paso 4
C4	Plazo según prioridad revisado — hoy por revisión humana de service_complaints (brecha 4)	Paso 8
C5	Alerta al superar umbral — sin destino de escritura hoy (brecha 4)	Paso 8
C6	NC automática para queja crítica > 3 días — sin destino de escritura hoy (brecha 4)	Paso 8

10. Criterios de decisión

Situación	Resultado
Responsable asignado y antecedentes revisados	Avanzar a in_progress para preparar respuesta
Investigación incompleta	Mantener en in_investigation; solicitar antecedentes si falta información
Queja revela problema sistémico	Iniciar derivación a no conformidad en CAL-006
Queja crítica > 3 días sin resolver	Escalamiento a Calidad y Dirección por vía humana; la NC automática no tiene destino hoy (brecha 4)
Queja duplicada	Cerrar por duplicidad en CAL-005 dejando constancia del original

11. Excepciones y escalamiento

• Queja sobre una persona del equipo. Soporte escala directamente a Dirección sin que la persona involucrada acceda al expediente.
• Queja crítica sin responsable. El sistema genera la alerta por plazo, pero sin responsable asignado la notificación queda sin destinatario directo. Ver brecha 1 en §17.
• Queja que requiere resolución legal o clínica. Dirección o el equipo clínico la gestiona; Soporte registra las notas internas de la derivación.
• Responsable no disponible. Soporte reasigna antes de que se cumpla el umbral de plazo.

12. Registros generados

• Estado del ticket en service_complaints tras la transición a in_investigation.
• Notas internas del responsable (no visibles para el socio).
• Mensajes de solicitud de información, si los hay (visibles para el socio), en complaint_messages.

No se genera hoy, porque su tabla destino no existe (brecha 4 en §17): el historial de transición con usuario y timestamp, la alerta queja_sin_resolver y la no conformidad automática. La constancia de esos tres pasos es humana — nota interna en el ticket — no del sistema.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Quejas con responsable asignado	Quejas con assigned_to no vacío ÷ total	100 %	service_complaints
Tiempo en investigación	Promedio de días en in_investigation	Monitoreo de tendencia	No calculable hoy — sin historial de transiciones (brecha 4)
Quejas críticas vencidas	Críticas > 3 días sin resolver	0	service_complaints (cálculo sobre fecha de apertura y estado; sin alerta automática)
NC automáticas generadas	Conteo de NC con categoría atencion_cliente y origen en queja	Monitoreo	No calculable hoy — sin registro de no conformidades (brecha 4)

14. Riesgos y controles

Riesgo	Control	Tipo
Queja sin responsable	C1 — asignación previa a la transición	Preventivo
Investigación sin registro	Sin control efectivo — el historial de workflow no se persiste	Brecha (§17, brecha 4)
Plazo superado sin alerta	Revisión humana de tickets abiertos; la alerta automática no tiene destino	Detectivo manual
Queja crítica sin escalamiento	Escalamiento humano a Calidad y Dirección; la NC automática no tiene destino	Correctivo manual
Conflicto de interés	Regla del §11 — escalamiento a Dirección	Preventivo

15. Normativa y referencias

• ISO 9001:2015 §10.2, No conformidad y acción correctiva: exige análisis de causa raíz y registro de lo actuado ante cualquier no conformidad.
• ISO 26000:2010 §6.7.6, Resolución de conflictos y reclamos: la investigación forma parte de un proceso justo y trazable.
• [[wiki/entities/dispensai/protocolos/CAL-002]] — apertura del ticket investigado.
• [[wiki/entities/dispensai/protocolos/CAL-003]] — autoapertura previa a la investigación.
• [[wiki/entities/dispensai/protocolos/CAL-005]] — respuesta y cierre.
• CAL-006 — derivación a no conformidad.

16. Anexos y formularios vinculados

• Catálogo de categorías y prioridades.
• Plantilla de nota interna de investigación.

17. Implementación en el sistema

El protocolo está implementado parcialmente. La validación de transiciones opera; el registro del historial, la alerta por plazo y la no conformidad automática no tienen destino de escritura hoy. La estructuración del análisis de causa raíz es responsabilidad humana.

Elemento del protocolo	Dónde vive
Paso 2 — validación de transición	updateComplaintWorkflowStatus en dispensai/lib/iso-workflows.ts
Paso 3 — registro de historial	logWorkflowTransition escribe a iso_workflows — tabla inexistente (brecha 4)
Tabla de transiciones válidas	WORKFLOW_TRANSITIONS.queja: open→in_investigation, in_investigation→in_progress, in_progress→resolved, resolved→closed
Paso 8 — monitoreo de plazos	checkUnresolvedComplaints en dispensai/lib/iso-alerts.ts
Umbrales de alerta	media: 15 días, alta: 7 días, crítica: 3 días
NC automática	Bloque en checkUnresolvedComplaints que llama createNonConformity si priority === "critica" && daysOpen > 3 — escribe a service_non_conformities, tabla inexistente (brecha 4)
Historial consultable	getWorkflowHistory("queja", complaintId) en iso-workflows.ts — sin filas que devolver (brecha 4)

Brechas conocidas:

1. La transición in_investigation no exige responsable asignado. updateComplaintWorkflowStatus valida la transición tipológica pero no verifica que assigned_to_user_id esté presente. Una queja puede pasar a investigación sin destinatario, lo que hace inútil la alerta por plazo.
2. El cron de monitoreo está confirmado; requiere secretos de Vault por tenant. La migración dispensai/supabase/migrations/20260407000000_pg_cron_scheduling.sql registra tres jobs con pg_cron: iso-audit-daily (2:00 AM UTC), iso-audit-weekly (3:00 AM UTC lunes) y proactive-alerts (cada 6 horas). Los tres llaman call_cron_endpoint() que dispara HTTP hacia /api/cron/iso-audit, la cual invoca runISOMonitoring → checkUnresolvedComplaints. Brecha subsistente: la migración exige configurar manualmente secretos de Vault (app_url, cron_secret) por instancia de tenant. Sin esa configuración los jobs arrancan pero fallan en tiempo de ejecución sin alertar. Los umbrales de 3/7/15 días son efectivos solo en tenants con los secretos configurados.
3. Campo de causa raíz en texto libre; sin estructura obligatoria. service_complaints tiene root_cause_analysis TEXT (baseline schema línea 526) y root_cause TEXT (migración 20260406000000_iso27001_integration.sql línea 91). No existen columnas separadas para hipótesis, hallazgos ni conclusión. La evidencia de investigación depende de que el responsable complete el campo con la profundidad suficiente.
4. Las tablas iso_workflows, iso_alerts y service_non_conformities no existen, y el plano ISO está apagado. Este protocolo las declaraba como registro de evidencia. Las tres fueron eliminadas por dispensai/supabase/migrations/20260515000000_iso_standby.sql —líneas 128 (iso_workflows), 129 (iso_alerts) y 138 (service_non_conformities)— y iso_workflows vuelve a eliminarse en 20260629000000_cross_tenant_dispensation_fix_canonical.sql:83. Ninguna migración posterior las recrea: la única sentencia CREATE TABLE de las tres vive en 20240101000000_baseline_schema.sql, anterior al drop. El plano ISO se trasladó al Worker dispensai/backends/workers/iso (D1), detrás de la bandera ISO_ENABLED, que está en false en los seis tenants con .env local; con la bandera apagada logISOSystemEvent es un no-op silencioso, según documenta dispensai/lib/iso-event-logger.ts:8. Consecuencia operativa: la investigación de quejas se sigue ejecutando como procedimiento —hay responsable, hay estado y hay notas internas en service_complaints—, pero el historial de transiciones, la alerta por plazo vencido y la derivación automática a no conformidad no dejan rastro verificable en el sistema. La trazabilidad de esos tres pasos es hoy humana. Esto vacía en la práctica la brecha 2: los umbrales de 3/7/15 días no producen alerta persistente en ningún tenant, tenga o no los secretos de Vault configurados.

Brecha observada en auditoría 2026-08-31

• Ruta no encontrada exacta: /admin/farmiemos/rse/quejas/[id] — puede ser variante (singular/plural, /admin vs /dashboard) o ruta renombrada. Acción correctora: actualizar el frontmatter con la ruta real que usa el sistema.
• Ruta no encontrada exacta: /admin/farmiemos/calidad/no-conformidades — puede ser variante (singular/plural, /admin vs /dashboard) o ruta renombrada. Acción correctora: actualizar el frontmatter con la ruta real que usa el sistema.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial, derivada de la navegación del flujo de quejas y del módulo de workflows	Calidad
1.1	2026-08-29	Cierre de INFERIDO: brecha 2 confirmada — cron pg_cron existe en migración 20260407000000_pg_cron_scheduling.sql (iso-audit-daily, iso-audit-weekly, proactive-alerts); brecha 3 actualizada — campos root_cause_analysis y root_cause existen como texto libre. Estado ascendido a Vigente.	Harness dispensai-protocolos
1.2	2026-08-29	Corrección de evidencia inexistente: iso_workflows, iso_alerts y service_non_conformities salen del frontmatter (registro_evidencia, implementacion.tablas). Nueva brecha 4 con las migraciones que las eliminaron y el estado de ISO_ENABLED. §3, §8, §9, §10, §12, §13, §14 y §17 corregidos para no afirmar registros que no ocurren. Brechas 3 → 4.	Sistema / admin
1.0+audit-2026-08-31	2026-08-31	Detectados gaps en auditoría: /admin/farmiemos/rse/quejas/[id], /admin/farmiemos/calidad/no-conformidades. §17 actualizada para documentar la brecha con evidencia de código. Estado documental sin cambio.	Auditoría automática