Casos de uso y workflows

Esta página recorre los siete flujos que definen lo que EMA Clinic hace durante un día típico de operación. Los flujos son universales —aplican a cualquier país donde el producto opere— pero algunos incorporan nombres y catálogos específicos del plug-in regulatorio chileno, que es la implementación productiva actual. Cuando otros países entren al producto, esos catálogos se reemplazan por sus equivalentes locales sin tocar el flujo subyacente. La perspectiva es funcional —qué pasa, en qué orden y por qué importa— sin entrar en los pasos concretos por rol; ese detalle vive en el manual de usuario.

Encuentro ambulatorio completo

El encuentro ambulatorio es la unidad básica del producto. Empieza cuando el paciente cruza la puerta y termina cuando el comprobante fiscal correspondiente al país llega a su correo electrónico, sin que ninguna persona haya tenido que saltar entre sistemas o pedir aclaraciones a otro turno.

El recorrido típico atraviesa cuatro manos. La secretaria abre la admisión: verifica si el paciente ya existe en la clínica, lo crea si es necesario y genera el Encounter que va a acompañar todo lo que ocurra después. El cajero registra el cobro, lo que produce un movimiento de caja y un borrador de factura; en paralelo, el worker de facturación electrónica empieza a tramitar el documento con el organismo fiscal del país (en el plug-in chileno, una Boleta 39 al SII). El médico llama al paciente desde la sala de espera y abre la ficha clínica. Mientras toma anamnesis y registra signos vitales, el sistema evalúa las condiciones ya documentadas contra los catálogos de patologías priorizadas y notificación obligatoria que tenga activos el plug-in del país y, si corresponde, genera tasks con plazo. Cuando el médico confirma el diagnóstico y prescribe, el encuentro se cierra y se produce automáticamente el resumen de consulta firmado con QR.

La emisión del documento fiscal corre asincrónicamente para no bloquear al equipo clínico. Si el organismo del país rechaza el documento —identificador inválido, ambiente caído u otra causa— el sistema deja registro en la cola de pendientes y reintenta cuando corresponda. La consulta no se ve afectada por el fallo de un sistema externo.

Atención de urgencia con triaje ESI

El módulo de urgencia opera con la escala ESI (Emergency Severity Index, niveles 1 a 5), estándar internacional para ordenar la atención según la gravedad estimada del caso. La triagista —usualmente personal de enfermería capacitado— ejecuta un cuestionario estructurado SDC al momento de recibir al paciente: motivo de consulta, dolor en escala 0-10, signos vitales y síntomas de alarma. Sobre esos datos el motor sugiere un nivel ESI.

La sugerencia es exactamente eso: una sugerencia. La triagista puede aceptarla y dejar el caso registrado como suggested = final, o puede sobrescribirla si su criterio clínico apunta a otra prioridad. En ese segundo caso es obligatorio dejar la razón del override por escrito, con una categoría predefinida (criterio clínico, comorbilidad, edad extrema, estabilidad evidente u otro motivo). El sistema no permite guardar el cambio sin razón porque las métricas de calidad operacional dependen de poder distinguir cuándo el motor falló y cuándo el motor acertó pero el caso requería juicio humano.

Una vez clasificado, el paciente entra a la cola visual de urgencia con cinco filas correspondientes a los cinco niveles ESI. Cada fila muestra un countdown según el SLA propio del nivel: cero minutos para nivel 1 (resucitación inmediata), diez para nivel 2 (emergente), treinta para nivel 3 (urgente), una hora para nivel 4 y dos horas para nivel 5. El médico llama según prioridad, atiende y cierra el encuentro como cualquier otro. Al cierre, el motor de métricas operacionales registra el tiempo puerta-médico real y la tasa de override de la triagista, datos que después alimentan el reporte mensual al organismo sanitario del país.

Detección y declaración de patología priorizada (GES en Chile)

Muchos países tienen regímenes de patologías priorizadas: catálogos de condiciones para los que el sistema de salud garantiza acceso, plazos y cobertura financiera particulares. En Chile ese régimen se llama GES (Garantías Explícitas en Salud) y cubre 85+ patologías; otros países tienen sus equivalentes (en Colombia, Plan de Beneficios; en México, FONSABI; etc.) con catálogos y reglas distintas.

El flujo en EMA Clinic es genérico y se parametriza con el catálogo del plug-in nacional activo. Cuando un médico confirma un diagnóstico —cambia el verificationStatus de provisional a confirmed— el sistema corre automáticamente el evaluador del plug-in contra el catálogo SNOMED. Si la patología cae dentro del régimen, se crea una task con plazo (en Chile, 24 horas) para que el profesional declare formalmente.

La declaración formal se hace desde la cola de tasks pendientes, no desde la ficha del paciente. El motivo es operacional: muchas declaraciones se completan en bloque al final del turno, o por personal administrativo del consultorio que tiene los datos demográficos a la mano y libera al médico de esa carga. El formulario viene prellenado con la patología detectada, el identificador de identidad del paciente y el código del establecimiento sanitario, así que el trabajo manual se reduce a confirmar y completar campos que el sistema no pudo deducir.

Al confirmar la declaración, el sistema produce tres artefactos relacionados: un Flag que marca al paciente como cubierto por la patología correspondiente, una Communication que notifica al paciente sobre sus derechos y plazos garantizados, y el cierre de la task. El reporte mensual al organismo sanitario incluye automáticamente las declaraciones del periodo agrupadas por código de establecimiento.

Notificación obligatoria a autoridad sanitaria (ENO en Chile)

El régimen ENO (Enfermedades de Notificación Obligatoria) opera con una lógica similar al de patologías priorizadas pero distinto en propósito: GES garantiza acceso del paciente a tratamiento, ENO garantiza que la autoridad sanitaria recibe información epidemiológica oportuna sobre patologías de declaración obligatoria. En Chile el catálogo cubre 150 códigos ICD-10; otros países tienen listados distintos (CDC en Estados Unidos, OMS en cooperación multilateral, etc.).

El médico completa información clínico-epidemiológica adicional —fuente probable de contagio, contactos cercanos, lugar de exposición— que el régimen de patologías priorizadas no exige. El sistema produce una Communication con categoría alert y un payload estructurado que el reporte mensual al organismo sanitario toma como input.

Scheduling multi-recurso

Algunas consultas requieren disponibilidad simultánea de varios recursos: una consulta dermatológica con dermatoscopio, un procedimiento traumatológico con sala equipada y técnico de apoyo, un control oftalmológico con autorrefractómetro. El motor de disponibilidad resuelve el problema de combinatoria de horarios.

La operación es conceptualmente simple: el sistema toma los slots libres de cada actor (médico, sala, equipo), calcula la intersección y descarta los slots que generan colisión con otros eventos del calendario. El verificador de conflictos distingue entre colisiones duras (dos eventos no pueden coexistir bajo ninguna circunstancia) y blandas (la clínica permite la superposición pero deja una marca de advertencia). El resultado es una lista de slots virtuales que el front-end agenda muestra al usuario y, si selecciona uno, se reserva como Appointment ligado a la ServiceRequest cuando corresponda.

Pricing en tres niveles

El motor de precios reconoce tres modos de pago que conviven en la realidad de cualquier institución de salud privada: pacientes particulares, pacientes con cobertura institucional (en Chile Fonasa o Isapre; en otros países, los pagadores equivalentes) y pacientes pertenecientes a empresas con convenio.

Para particular, el precio es el base_price_clp del servicio prestado. Para cobertura institucional pública, el copago se calcula automáticamente según el tramo del paciente (en el plug-in chileno, los tramos A, B, C, D de Fonasa con copagos del 0%, 10%, 10% y 20% respectivamente). Para cobertura privada con bono, el sistema valida el documento contra el cliente correspondiente (en Chile, el cliente imed para Isapres) y aplica el monto correspondiente cobrando solo la diferencia. Para convenios empresa o gobierno, el sistema busca el precio negociado en agreement_prices, no cobra al paciente al momento y deja un borrador de factura que se procesa después contra el pagador.

Reporte estadístico mensual a la autoridad sanitaria

Casi todos los países exigen a las clínicas un reporte estadístico mensual con la actividad de atención. En Chile ese reporte se llama REM (Resumen Estadístico Mensual) y se entrega al DEIS del MINSAL antes del día 15 del mes siguiente; en otros países la forma, plazos y catálogo son distintos pero la idea funcional es la misma.

El admin solicita el reporte desde el módulo de reportes; el motor del plug-in del país genera el reporte filtrando por tenant y código de establecimiento, agrupa por las categorías que el formato local espera, y produce un XLSX descargable. Al generar el reporte el sistema también deja una pista de auditoría con cuántos encuentros se incluyeron y cuáles se excluyeron junto con la razón de exclusión, datos útiles cuando un cierre fiscal exige reconciliar cifras. El paso final, la subida al portal del organismo sanitario, es manual por requerimiento regulatorio en la mayoría de los países.

Patrones que recorren todos los flujos

A lo largo de los siete workflows aparecen cuatro principios de diseño que conviene tener presentes. El primero es auto-detección con verificación humana: el sistema sugiere (un diagnóstico provisional, un nivel ESI, una patología priorizada, una notificación obligatoria) pero el profesional confirma o sobrescribe con razón. Nunca se deja a la máquina decidir sola sobre lo clínico.

El segundo es el uso de tasks con plazo como mecanismo de SLA: las declaraciones de patología priorizada, las notificaciones obligatorias y los cierres de discharge viven como tasks FHIR con restriction.period.end definido. Si vencen, un cron las marca como failed y aparecen en los dashboards correspondientes. El tercero es el principio de asincronía no bloqueante: la emisión de documentos fiscales, la generación del reporte mensual y los envíos de correo nunca obstaculizan al equipo clínico en tiempo real. Si fallan, quedan en cola y se reintentan. El cuarto, transversal, es la existencia de un audit log completo sobre toda mutación con tenant, usuario, acción, recurso afectado y diff de cambios.