Qué hace y para quién

EMA Clinic es el sistema clínico ambulatorio del ecosistema EMA Health. Acompaña a una institución de salud desde que el paciente cruza la puerta hasta que sale con su receta y su comprobante fiscal en el correo, atravesando admisión, consulta médica, diagnóstico, prescripción y cobro. Está pensado como un único hilo continuo, no como una colección de módulos que el equipo tiene que coser a mano, y opera como plataforma multi-tenant y multi-país por diseño.

A quién está dirigido

El producto se diseñó mirando a las clínicas e instituciones ambulatorias privadas de mercados latinoamericanos, con una primera implementación regulatoria activa en Chile (catálogos GES y ENO, emisión DTE al SII, cumplimiento de Ley 20.584). La arquitectura multi-tenant escala desde un consultorio de un solo box hasta una clínica con cincuenta profesionales activos: ningún flujo asume un volumen mínimo y los seis roles que el sistema reconoce —admin, médico, enfermería, secretaría, caja y profesional aliado— corresponden a la estructura típica de una clínica latinoamericana.

Una segunda audiencia son los vendors e integradores que necesitan conectar otro sistema clínico, un equipo de imagenología o un partner de laboratorio con la clínica. Para ese caso, EMA Bridge ofrece los conectores HL7v2 y FHIR R4 estándar que permiten intercambiar datos sin acuerdos custom. Internamente, los PMs y el área comercial de EMA usan esta misma documentación como referencia funcional del producto.

El problema que resuelve

El mercado de software clínico ambulatorio en América Latina se ha mantenido durante años en un estado incómodo. Por un lado, las soluciones legacy locales —productos hechos a medida, sistemas monolíticos instalados on-premise— son caras de mantener y sin capacidad real de interoperabilidad: cuando una clínica quiere conectarse con un laboratorio externo o exportar datos a la autoridad sanitaria del país, el camino es siempre artesanal. Por el otro lado, las plataformas cloud extranjeras (Salesforce Health Cloud y similares) ofrecen una arquitectura moderna pero asumen un contexto regulatorio que no es el local: ninguna emite documentos fiscales electrónicos al organismo tributario del país, ninguna conoce los catálogos de patologías priorizadas locales, ninguna respeta los consentimientos exigidos por la legislación de protección de datos sin meses de configuración.

EMA Clinic busca el espacio intermedio. Es SaaS multi-tenant nativo en la nube, escrito en FHIR R4 puro desde el primer día, y con la regulación local modelada como plug-ins por país en lugar de parches posteriores. Cada país que entre al producto requiere su propio plug-in regulatorio (catálogos de patologías garantizadas, formato de facturación electrónica, ley de protección de datos local) sin tocar el core clínico. Hoy el plug-in chileno es la implementación productiva.

Propuesta de valor

El flujo ambulatorio completo es el corazón del producto. Una secretaria admite al paciente y crea el Encounter; el cajero registra el pago y emite el documento fiscal electrónico correspondiente al país; el médico abre la ficha clínica, anota la anamnesis, registra signos vitales, llega a un diagnóstico y prescribe; al cerrar el encuentro se genera automáticamente el resumen de consulta firmado con QR y se envía al paciente. Cada paso vive dentro del mismo hilo y deja trazabilidad completa en el audit log, sin necesidad de exportar a Excel o reconciliar entre módulos.

La arquitectura FHIR R4 nativa no es una capa de exportación: es la forma canónica de almacenar y consultar la información clínica. Esto significa que cualquier integración con otro sistema clínico, con un laboratorio o con el portal del paciente parte de un denominador común estándar. También permite que el aislamiento entre clínicas opere a tres niveles simultáneos —ORGBAC en Aidbox, RLS en Supabase y tagging por tenant en cada recurso— en lugar de depender de filtros aplicados a mano por cada desarrollador.

Los value sets clínicos (códigos LOINC para observaciones, SNOMED CT para condiciones y procedimientos, ICD-10 para diagnósticos administrativos, RxNorm para medicamentos) viven en inglés como definen sus organismos emisores. El producto los presenta con display localizado al idioma del tenant: en una instalación chilena el médico ve “Hipertensión esencial (primaria)” pero el recurso FHIR almacena el código SNOMED canónico. Esa separación permite que las integraciones cross-país operen contra el código estándar mientras la UI respeta el idioma operativo.

La pieza regulatoria es probablemente lo que más tiempo ahorra en cada nueva implementación país. El producto ofrece tres componentes que cada plug-in nacional implementa:

• Catálogos de patologías priorizadas —en el plug-in chileno, GES con 90 patologías y ENO con 150 códigos ICD-10. Cada plug-in define su propio catálogo y sus reglas de SLA y notificación.
• Facturación electrónica gubernamental —en Chile, integración directa con SII vía emisión de Boleta 39 sin intermediarios. Otros países conectarían con su organismo equivalente.
• Cumplimiento de protección de datos —en Chile, modelado de consentimientos según Ley 20.584. La estructura de Consent FHIR permite implementar las exigencias locales (LGPD, HIPAA, GDPR, etc.) con cambios acotados.

Tres bloques completan la propuesta: scheduling multi-recurso, que encuentra slots cuando una consulta requiere médico, sala y equipo disponibles simultáneamente; atención de urgencia, con triaje ESI que sugiere un nivel y deja registro auditado si la triagista lo sobrescribe; y extensibilidad sin código vía SDC (Structured Data Capture) y PlanDefinition para que las clínicas modelen sus propios cuestionarios y flujos sin pedir desarrollo.

Diferenciadores frente al mercado

La tabla siguiente sintetiza dónde EMA Clinic se separa del software clínico tradicional disponible en la región:

Aspecto	EMA Clinic	Software clínico tradicional
Estándar clínico	FHIR R4 nativo con value sets globales (LOINC, SNOMED, ICD-10, RxNorm)	HL7v2 con propiedades custom
Multi-tenancy	Una sola instancia compartida con ORGBAC	Una instalación por cliente
Regulación local	Plug-ins por país; Chile productivo (GES, ENO, DTE, Ley 20.584)	Implementación manual o ausente
Localización	Display localizado por tenant sobre código canónico	Mezcla código y traducción
Scheduling	Multi-recurso con detección de colisiones	Calendario por profesional
Atención de urgencia	ESI con SLA y métricas	No contemplada
Hosting	Cloudflare Workers, edge global	On-premise o cloud genérico
Tiempo de setup	Provisioning automatizado	Días de instalación y configuración

Lo más relevante no es ningún ítem aislado sino el patrón. Las soluciones legacy fueron pensadas para una clínica funcionando como isla en un país concreto, mientras que EMA Clinic asume desde el inicio que la clínica vive dentro de un ecosistema —de laboratorios, hospitales referidos, organismos regulatorios, otros productos del propio EMA Health— y que el producto necesita escalar a múltiples países sin tocar el core.

Estado del producto

La versión actual es 0.2.0, con el sprint S9 cerrado. El sistema está desplegado en clinic.emahealth.io y se considera listo para piloto controlado con una clínica real bajo el plug-in regulatorio chileno (Wave 5). Los criterios de cierre incluyen ORGBAC server-side completo, audit cross-product verificado y los flujos críticos —encuentro ambulatorio, urgencia, declaración de patología priorizada, notificación obligatoria y cobro con DTE— probados de extremo a extremo.

Fuera del alcance actual

EMA Clinic se concentra deliberadamente en el flujo ambulatorio y la atención de urgencia de baja complejidad. La hospitalización (niveles 2 a 5), el pabellón quirúrgico, la firma electrónica avanzada y la telemedicina nativa están explícitamente fuera del alcance de la versión actual. La firma electrónica simple basada en QR cubre los casos regulatorios habituales y la firma avanzada está planificada para la versión 1.5, una vez que un cliente concreto la requiera. La telemedicina, por ahora, se resuelve mediante integración con LOOPS en lugar de incorporar video propio al producto. Los plug-ins regulatorios para países distintos de Chile son objetivo de roadmap; cada uno requiere una integración con el organismo fiscal local, la traducción del catálogo de patologías priorizadas y el modelado de la ley de protección de datos correspondiente.