Qué hace y para quién
EMA Lab es el sistema de información clínica para laboratorios (LIS) del ecosistema EMA Health. Acompaña al laboratorio desde que la muestra cruza la puerta hasta que el reporte firmado llega al EHR del solicitante, atravesando admisión, toma, transporte, recepción central, análisis, las cuatro etapas de validación, la emisión de documentos fiscales y, cuando corresponde, el reporte de stewardship antimicrobiano. La pieza es ambiciosa por necesidad: el ciclo IVLIS moderno tiene demasiados estados y demasiadas regulaciones como para resolverse con un sistema genérico, y EMA Lab opera como plataforma multi-tenant y multi-país por diseño.
A quién está dirigido
Sección titulada «A quién está dirigido»El producto se diseñó pensando en laboratorios clínicos privados latinoamericanos que tienen volumen suficiente para necesitar trazabilidad real pero no tanto como para mantener un equipo de software propio, con primera implementación regulatoria activa en Chile. La arquitectura multi-tenant permite que un laboratorio opere una sola sede o varias bajo el mismo registro, con ruteo automático entre ellas. Los seis roles reconocidos —admin, director técnico, tecnólogo médico (TM), recepción, flebotomista y viewer— corresponden a la estructura habitual de un laboratorio latinoamericano y heredan la experiencia del proyecto IVLIS de BUPA Chile sobre Dedalus SUNRISE.
Una segunda audiencia son los vendors e integradores de equipamiento de laboratorio que necesitan conectar analizadores, sistemas de imagenología o EHR de clientes externos. La integración pasa por EMA Bridge usando los protocolos estándar HL7v2, FHIR R4 y ASTM. Internamente, los PMs y el equipo comercial de EMA usan esta documentación como referencia de capacidades del producto.
El problema que resuelve
Sección titulada «El problema que resuelve»El mercado latinoamericano de software para laboratorios clínicos vive con tres problemas crónicos. El primero es la dependencia de soluciones legacy —productos hechos a medida, sistemas locales monolíticos— que están instalados on-premise, son caros de mantener y no tienen interoperabilidad real. Cuando un laboratorio quiere recibir órdenes electrónicas desde una clínica externa o exportar a la autoridad sanitaria del país, el camino es siempre artesanal. El segundo es el LIS extranjero atado a una línea de equipamiento (Roche, Beckman, Sysmex middleware): técnicamente sólido pero inflexible para laboratorios que operan con un mix multi-vendor, lo que es la realidad habitual en la región. El tercero es la opción custom-built, donde el laboratorio mantiene su propio sistema con desarrolladores in-house: alto costo, dependencia de personas concretas y sin actualizaciones regulatorias automáticas cuando cambia la normativa.
EMA Lab se ubica en un cuarto cuadrante: cloud-nativo, FHIR-first, multi-vendor y con la regulación local modelada como plug-in por país en lugar de parche posterior. La idea no es replicar lo que hace un LIS legacy con otra interfaz, sino aceptar que un laboratorio moderno vive dentro de un ecosistema —de clínicas, hospitales referidos, organismos regulatorios, otros productos del propio EMA Health— y diseñar para escalar a múltiples países sin tocar el core del LIS. Hoy el plug-in chileno es la implementación productiva.
Propuesta de valor
Sección titulada «Propuesta de valor»El núcleo del producto es el ciclo IVLIS completo. Una orden llega desde el EHR del solicitante o se genera en recepción; se imprimen etiquetas con códigos Code 128B y dígito verificador Luhn; el flebotomista toma la muestra y registra eventuales no-conformidades contra el catálogo CLSI GP41 (16 razones tipificadas, estándar internacional); el transporte queda registrado, la recepción central hace el check-in por lote y el ruteo automático envía cada test a la sección correspondiente. Dentro de la sección, el TM ingresa el resultado —manualmente o vía Hub on-premise conectado al analizador— y el sistema corre las cuatro etapas de validación: técnica con autorización por sección, evaluador EMI, autoverify según condiciones predefinidas, y firma del director si alguna etapa anterior no liberó el resultado. El DR final lleva firma con QR y código de verificación público sin PII, y se envía al EHR cliente vía HL7v2 ORU outbound o FHIR Subscription.
La arquitectura FHIR R4 nativa no es una capa de exportación: es
la forma canónica de almacenar los datos clínicos. Esto significa
que cualquier integración con clínicas u hospitales parte de un
denominador común estándar. Los value sets clínicos (códigos
LOINC para tests, SNOMED CT para microorganismos y patologías,
ICD-10 para diagnósticos administrativos) viven en inglés según los
emite cada organismo, y el producto los presenta con display
localizado al idioma del tenant: en una instalación chilena el TM
ve “Hemoglobina, glicada” mientras el recurso almacena el código
LOINC canónico. La capa de aislamiento entre laboratorios opera en
cuatro niveles independientes —ORGBAC en Aidbox, RLS en Supabase,
client isolation por cliente externo y tagging por tenant— y se
refuerzan mutuamente por diseño.
La microbiología es uno de los puntos más diferenciadores. El módulo maneja el seguimiento de cultivos en siete estados distintos, desde incubación hasta antibiograma firmado. Soporta identificación automática vía MALDI-TOF Bruker con clasificación por confidence tiers, hemocultivos positivos que disparan task crítica FHIR inmediata, y un catálogo global de microorganismos con más de 80 entradas SNOMED. El antibiograma incluye SIR completo más MIC y zona de inhibición como componentes; el cultivo negativo nunca se marca automáticamente sino que requiere confirmación manual del TM al cumplirse el timeout configurado por tipo de muestra.
El stewardship antimicrobiano CLSI M39 está incluido sin licencia adicional. El motor produce trimestralmente el antibiograma institucional con las reglas de la guía M39 (estándar internacional, no específico de Chile), requiere multi-firma (director técnico más microbiólogo más signers configurables) y escribe dual-write a Supabase (operacional) y FHIR DetectedIssue (canónico). La función dry-run permite revisar el contenido del reporte antes de comprometerlo.
A esto se suman cuatro piezas adicionales que completan el
producto. La plataforma molecular genérica permite importar
resultados PCR y NGS desde cualquier vendor mediante un parser
registry extensible, con flag de pending review cuando aparece un
target crítico configurable. El Hub on-premise ofrece
conectividad con analizadores físicos vía Docker en el site del
laboratorio, con cuatro modos de conexión que sortean prácticamente
cualquier configuración de firewall. La emisión de documentos
fiscales se delega al worker emadte con API key per-tenant; en
el plug-in chileno opera contra SII vía Boleta y Factura
electrónicas, otros países conectarían con su organismo equivalente.
Y el ruteo entre sedes se resuelve con un motor que considera
disponibilidad, equipamiento y SLA de transporte.
Diferenciadores frente al mercado
Sección titulada «Diferenciadores frente al mercado»La tabla siguiente sintetiza dónde EMA Lab se separa del software LIS tradicional disponible en la región:
| Aspecto | EMA Lab | LIS tradicional |
|---|---|---|
| Estándar clínico | FHIR R4 nativo con value sets globales (LOINC, SNOMED, ICD-10) y display localizado | HL7v2 con propiedades custom |
| Multi-tenancy | Una sola instancia compartida con ORGBAC | Una instalación por cliente |
| Microbiología | Culture tracking, MALDI-TOF, hemocultivo positivo crítico | Limitada o ausente |
| Stewardship CLSI M39 | Motor integrado con multi-firma y dual-write | No presente |
| Plataforma molecular | Parser registry genérico | Manual o ausente |
| Validación | Pipeline de cuatro etapas auditadas | Mínima |
| Multi-vendor | Hub Docker on-premise con cuatro modos | Atado a una línea de equipos |
| Multi-site | Routing inter-sede más transport routes | No contemplado |
| Regulación local | Plug-ins por país; Chile productivo | Implementación manual o parcial |
| Tiempo de setup | Provisioning automatizado bajo 24 horas | Días o semanas |
Lo más relevante no es ningún ítem aislado sino el patrón. La mayoría de los LIS tradicionales fueron pensados para una era anterior —anterior a FHIR, anterior a la nube, anterior al stewardship integrado, anterior a la operación cross-país. EMA Lab asume el contexto actual desde el diseño.
Estado del producto
Sección titulada «Estado del producto»La versión actual es 0.2.0, con Wave 3 v2.0 y el sprint S9 cerrado e integrados en main. El sistema está cubierto por 809 tests ejecutándose verde sin tests omitidos, con cobertura RLS al 100% bajo mutation testing (decisión L087) y los hallazgos OWASP críticos y altos cerrados (L088, L089). La verificación cross-product de tenants, RBAC y routing está completa (L093 a L095), el runbook operativo cubre catorce secciones (L097) y existe un documento de system status pre-piloto (L098). El producto está listo para piloto controlado con un cliente real bajo el plug-in regulatorio chileno.
Fuera del alcance actual
Sección titulada «Fuera del alcance actual»EMA Lab se concentra deliberadamente en el ciclo clínico ambulatorio del laboratorio. El banco de sangre, la anatomía patológica (que vive en el producto separado emapath), la imagenología (emaimaging) y la conexión directa ASTM desde el worker de cloud están explícitamente fuera del alcance: la conectividad ASTM siempre pasa por el Hub on-premise. La validación ante esquemas nacionales de práctica de laboratorio (en Chile, INACE y PEEC) queda pendiente del piloto productivo, y la adopción global de shadcn/ui fue sustituida por wrappers Radix manuales por restricción del design system v1.0 (decisión L027). Los plug-ins regulatorios para países distintos de Chile son objetivo de roadmap; cada uno requiere integración con el organismo fiscal local, traducción de catálogos de patologías priorizadas y modelado de la ley de protección de datos correspondiente.