Casos de uso y workflows

Esta página recorre los diez flujos que estructuran la operación diaria de un laboratorio sobre EMA Lab. La perspectiva es funcional —qué pasa, en qué orden y por qué importa— y deja para el manual de usuario los pasos concretos por rol.

Orden ambulatoria estándar

El flujo de orden ambulatoria es el caso base, el que ocurre cientos de veces al día en un laboratorio activo. Tiene la particularidad de que la orden no nace en el laboratorio: viene desde el EHR de la clínica solicitante a través del conector FHIR Subscription o un mensaje HL7v2. EMA Lab la recibe, valida que el paciente y los tests existan en el catálogo, y produce un ServiceRequest por cada test solicitado —no agrupados en perfiles. Esa decisión, registrada como ADR-003, es deliberada: la facturación, el ruteo y la validación son granulares por test, así que tenerlos como recursos separados desde el inicio simplifica todo el resto del ciclo.

Una vez creada la orden, el sistema imprime las etiquetas Code 128B con dígito verificador Luhn que acompañarán a cada tubo durante todo el trayecto físico. La toma puede hacerla un flebotomista del laboratorio en sede, o llegar pre-tomada desde el cliente externo. El transporte queda registrado y, cuando la integración con un tracker lo permite, se consigna también la temperatura de la cadena de frío. La recepción central hace el check-in por lote y el motor de ruteo distribuye cada test a la sección correspondiente.

Dentro de la sección, el TM ingresa el resultado —manualmente desde la UI o automáticamente vía Hub on-premise conectado al analizador— y el sistema corre las cuatro etapas de validación. La etapa técnica verifica la autorización del TM para esa sección; la etapa EMI corre las reglas configuradas (rangos de referencia, delta check, panic value); la etapa de autoverify aplica las condiciones específicas del test, que pueden incluir edad, sexo o histórico del paciente; la etapa final, si las anteriores no liberaron el resultado, requiere firma del director técnico. El reporte firmado lleva un código QR de verificación pública sin PII y se envía al EHR del solicitante vía HL7v2 ORU outbound o FHIR Subscription, con cola de retry si falla.

Orden de urgencia

Las órdenes con prioridad stat siguen el mismo recorrido pero con señales visuales que las priorizan en cada cola. El countdown TAT en los worklists usa código de color (verde, amarillo, rojo) según la distancia al SLA, y el sistema marca la cabecera del tubo con indicación visible para que el operador físico no la confunda con una orden estándar.

Si el TAT supera el SLA configurado, el sistema genera automáticamente una no-conformidad CLSI GP41 con razón “TAT excedido”. Esa NC queda disponible para investigación posterior y aparece en los reportes operacionales mensuales que el director revisa. La notificación de valor crítico, cuando corresponde, dispara una Communication FHIR hacia el médico solicitante y queda registrada con el acuse de recibo.

Cultivo bacteriano y antibiograma

El flujo de microbiología es el que más se aleja de un test químico estándar, porque opera con tiempos biológicos y no con tiempos de analizador. El cultivo atraviesa siete estados a lo largo de uno o varios días, y cada transición requiere acción explícita del TM —el sistema nunca asume estados por su cuenta porque la lectura de placa es interpretativa.

La identificación del organismo puede hacerse por bioquímica manual o por MALDI-TOF. Cuando el laboratorio dispone de un equipo Bruker, EMA Lab importa el archivo de salida y clasifica el resultado por confidence tier: con score igual o mayor a 2.3 considera la identificación de alta confianza y la ingresa automáticamente; entre 2.0 y 2.3 acepta la identificación a nivel de género; entre 1.7 y 2.0 la marca como probable y enciende un banner amber que el director debe revisar antes de firmar; bajo 1.7 rechaza la importación. El antibiograma se carga sobre paneles configurados, con resultados SIR y los valores cuantitativos (MIC y zona de inhibición) como componentes del recurso Observation.

Dos casos especiales merecen mención. El primero es el cultivo negativo: el sistema nunca lo marca automáticamente, ni siquiera cuando se cumple el timeout configurado. La decisión, registrada como ADR-021, obedece a que un negativo prematuro es clínicamente más peligroso que un timeout extra. Los timeouts por tipo de muestra son 48 horas para cultivo estándar, 14 días para hongos y 42 días para micobacterias. El segundo caso es el hemocultivo positivo: cuando el TM marca growth_detected con flag de hemocultivo, el sistema crea automáticamente una task FHIR de tipo critical-value-notification (decisión L051) que dispara alerta inmediata al médico solicitante.

Stewardship antimicrobiano CLSI M39

El reporte trimestral de stewardship se diferencia del resto de los flujos en que es agregado, no individual. El cron 0 3 1 1,4,7,10 * dispara el primer día de cada trimestre el motor de antibiograma institucional, que recorre los cultivos del periodo y aplica las reglas de la guía CLSI M39 para producir un reporte representativo.

La regla CLSI M39 que más visiblemente filtra el resultado es el mínimo de treinta aislamientos por combinación organismo-antibiótico: si un par no cumple ese umbral en el trimestre, se excluye del reporte. Una vez agregados los datos, el reporte queda en estado draft y queda disponible una función de dry-run (decisión L072) que permite al admin revisar el contenido sin comprometer la emisión. Si las cifras hacen sentido, el reporte pasa a ready_for_signing y los signers configurados —típicamente el director técnico y el microbiólogo— firman individualmente. Cuando todas las firmas están presentes, el sistema escribe en paralelo a Supabase (operacional) y genera un DetectedIssue FHIR (canónico), produce el XLSX, lo sube a R2 y crea el DocumentReference correspondiente.

Plataforma molecular genérica

Las plataformas moleculares (PCR, NGS, secuenciación) suelen producir resultados en formatos propietarios que cambian de un vendor a otro y de un kit a otro. EMA Lab resuelve la importación con un parser registry extensible: cada formato vivo en producción tiene un parser en src/lib/molecular/parsers/<vendor>.ts, y el sistema selecciona automáticamente el adecuado por las cabeceras del archivo recibido.

El admin del laboratorio puede configurar targets críticos: combos de gen y resultado que merecen revisión obligatoria del director antes de pasar a la etapa autoverify (BRCA1 positivo, KRAS mutado, BCR-ABL detectable). Cuando una importación contiene un target crítico, el sistema marca el caso como pending review y enciende un banner amber. Los demás resultados pasan a autoverify normal.

Control de calidad interno

El control de calidad interno es la pieza que un laboratorio bien operado ejecuta antes de empezar el turno y revisa cuando algo se ve sospechoso. EMA Lab implementa el conjunto de reglas Westgard clásico, con la particularidad de que la regla de tendencia 7-T se aplica con monotonía estricta —siete puntos consecutivos al mismo lado del media sin valores repetidos exactos— y por defecto produce un warning, no un fail bloqueante. La decisión, registrada como L024, busca evitar falsos positivos por estabilidad operacional sin perder la señal cuando el equipo realmente está derivando.

Westgard 7-T — strict monotonic (L024)

La regla 7-T (siete tendencias) requiere monotonía estricta: al menos siete puntos consecutivos arriba o abajo del media sin repetidos exactos. La acción default es warn, lo que produce alerta pero no bloquea el batch.

Cuando una corrida QC falla, el TM puede repetir con otro tubo del mismo lote, abrir una no-conformidad GP41 si la falla es persistente, o bloquear el batch a la espera de revisión del director.

Hub on-premise

Algunos laboratorios operan analizadores físicos que no tienen acceso directo a internet, ya sea por política corporativa o por limitaciones de los protocolos legacy ASTM/HL7v2 que muchos equipos hablan nativamente. Para esos casos EMA Lab provee un Hub Docker que se instala en la red local del site y actúa de intermediario entre el analizador y el cloud.

El Hub se autentica contra el cloud con un token rotable y soporta cuatro modos de conexión —polling, SSE-keepalive, hybrid y websocket— que permiten operar bajo prácticamente cualquier configuración de firewall corporativo. Cuando el analizador entrega un resultado, el Hub lo reporta al cloud, que registra la Observation, dispara el consumo de reactivos correspondiente cuando está habilitado y actualiza la ServiceRequest a estado completado.

Notificación de valor crítico

La notificación de valor crítico cumple un requerimiento regulatorio explícito de las leyes de derechos del paciente (en Chile, la Ley 20.584; en otros países, sus equivalentes locales): cuando un resultado cae dentro de un rango definido como crítico, el laboratorio debe alertar oportunamente al médico solicitante y dejar registro del aviso. EMA Lab modela esto con un Communication FHIR de categoría alert y un mecanismo de escalation chain con timeout.

El sistema espera el acuse de recibo del médico durante treinta minutos. Si el ack no llega, escala al director médico de la institución; si el director tampoco responde, sigue subiendo por la cadena configurada. Cada eslabón de la cadena queda registrado en critical_value_log con su timestamp, lo que permite auditar cumplimiento.

Facturación electrónica

La emisión del documento fiscal no la hace EMA Lab directamente: se delega al worker emadte con una API key per-tenant. Esa separación permite que la lógica fiscal y la criptografía de los certificados digitales vivan en un servicio dedicado que se actualiza en su propio ciclo, sin acoplar al producto clínico. En el plug-in chileno opera contra el SII; otros países conectarían con su organismo fiscal equivalente.

Cuando una orden se completa, el motor de pricing calcula el monto según la lista de precios del cliente, se inserta el Invoice con sus líneas y se invoca a emadte. El worker fiscal contacta al organismo del país, obtiene el folio asignado y hace callback al lab con el resultado; ese callback es idempotente por invoice_id, por lo que reintentos no producen duplicados. Si el organismo rechaza, el invoice queda en cola de pendientes y se reintenta asincrónicamente.

No conformidad CLSI GP41

Cuando algo sale mal —una muestra mal tomada, un error analítico, un TAT excedido— el laboratorio levanta una no-conformidad. EMA Lab modela las dieciséis razones tipificadas por la guía CLSI GP41 y las expone como DetectedIssue FHIR (decisión ADR-008) para que el dato sea queryable cross-resource y agregable en reportes regulatorios.

La fuente de la NC determina su categoría (pre-analytical, analytical, equipment o SLA) y el flujo de acción posterior. Algunas NCs se resuelven con repetir el test, otras requieren notificar al cliente externo, otras (especialmente las recurrentes) abren una investigación formal que el director cierra con acción correctiva documentada.

Patrones que recorren todos los flujos

A lo largo de los diez workflows aparecen cinco principios de diseño comunes. El primero es el modelado per-test del ServiceRequest: facturación, ruteo y validación son granulares y necesitan recursos separados desde el inicio. El segundo es la validación obligatoria en cuatro etapas: incluso cuando un resultado pasa por autoverify, el sistema deja registro de las cuatro fases para que el audit sea completo y auditable.

El tercero es el principio de asincronía no bloqueante: la emisión DTE, el HL7v2 outbound, la escritura FHIR canonical y los correos no obstaculizan al equipo en tiempo real; si fallan, viven en una cola de retry y, eventualmente, en una dead-letter queue con alerta al admin. El cuarto es el audit log completo sobre toda mutación, con tenant, usuario, acción, recurso afectado y diff. El quinto es la separación entre canónico y operacional: para los datos clínicos (Observation, DiagnosticReport, Specimen) Aidbox es la fuente de verdad; para los datos operacionales (worklists, configuración QC, billing, inventario) lo es Supabase.