Ponemos una capa FHIR delante de los sistemas que ya operan —expediente, laboratorio, imágenes, sistemas heredados sin API— para que hablen el estándar sin ser reemplazados, con la conformidad verificada y la operación intacta.
Los sistemas que sostienen la operación clínica rara vez se pueden apagar: tienen años de datos, procesos amarrados, contratos vigentes y usuarios que dependen de que funcionen mañana a las siete. Pero cada vez más se les pide participar en un intercambio para el que nunca fueron diseñados: exponer un resultado, notificar a una autoridad, alimentar una vista consolidada, conectarse a una red. Una capa FHIR resuelve esa tensión traduciendo entre lo que el sistema guarda y lo que el ecosistema exige, sin tocar su base de datos ni su operación. Bien diseñada, compra años de margen. Mal diseñada, se convierte en el sistema heredado siguiente: otra caja que nadie se anima a tocar.
«Sistemas heredados» no dice nada. Lo que define el trabajo es la forma real del origen y lo que uno encuentra al abrirlo.
Acceso directo al esquema relacional del sistema clínico, casi siempre en solo lectura y contra una réplica, para no competir con la operación.
Tablas sin documentar, campos reutilizados para dos cosas distintas, banderas de estado que solo entiende quien las escribió y reglas de negocio que viven en la aplicación y no en el modelo.
Mensajería de admisión, órdenes y resultados que ya circula entre sistemas y que puede aprovecharse como fuente en lugar de construir una extracción nueva.
Segmentos Z propios de cada instalación, campos opcionales usados de forma creativa, y el hecho de que un mensaje describe un evento, no el estado actual del paciente.
CSV, posicionales o XML que el sistema ya genera para reportes o para otros consumidores, procesados por lote.
Ventanas de generación fijas, entregas parciales o repetidas, codificaciones de caracteres heredadas y ningún mecanismo para saber qué cambió desde el archivo anterior.
Interfaces que el proveedor ya expone, pensadas para un consumidor específico y con un modelo de datos propio.
Granularidad que no coincide con la del recurso FHIR, límites de paginación y concurrencia no documentados, y cambios de contrato que llegan sin aviso.
Estudios e informes de imagen, donde el metadato vive en el equipamiento y en el PACS antes que en el registro clínico.
Identificadores de paciente distintos a los del expediente, informes en texto libre dentro del estudio y volúmenes que hacen inviable materializar sin un criterio claro.
Los catálogos que sostienen procesos reales aunque no vivan en ningún sistema: servicios, profesionales, equivalencias de códigos.
Sin control de versiones, sin dueño formal y con la verdad repartida entre varias copias que no coinciden entre sí.
Es la primera decisión de arquitectura y la que determina el costo, la latencia y a quién le duele una caída. Casi nunca es una elección pura.
La capa traduce cada consulta contra el sistema origen, en el momento.
Los datos se transforman y se cargan en un repositorio FHIR que atiende las consultas.
Los extremos puros son poco frecuentes. La mayoría de las capas que operan bien son combinaciones deliberadas de ambos.
Seis etapas. La primera decide qué se puede sacar del origen sin arriesgar la operación clínica.
Antes de mapear nada, entendemos qué guarda el sistema realmente y qué se puede extraer sin poner en riesgo lo que ya funciona.
Se decide qué recurso representa cada dato, qué perfil aplica y de dónde sale cada elemento — incluido el que el origen no tiene.
Modo de entrega, alcance por dominio, seguridad y contrato con los consumidores. Aquí se fija lo que después resulta caro cambiar.
Se implementan las transformaciones, la exposición y el manejo de errores, con los casos límite tratados como parte del alcance y no como sorpresas.
La capa se prueba contra los perfiles que debe cumplir, con ejemplos válidos y con ejemplos que deben ser rechazados.
Una capa sin monitoreo falla en silencio y se descubre cuando alguien reclama un dato que nunca llegó.
La diferencia entre una capa que pasa una demostración y una que aguanta un ecosistema está en detalles que solo aparecen cuando un tercero intenta consumirla.
Se arma el JSON a mano hasta que «se ve bien» y se prueba únicamente contra el cliente propio.
Cada recurso se valida contra el perfil de la guía aplicable, en integración continua, con ejemplos que deben pasar y ejemplos que deben fallar.
Se publica un CapabilityStatement copiado que declara operaciones y búsquedas que nadie implementó.
Se declara exactamente lo que la capa soporta. Un consumidor debe poder planear su integración leyéndolo, sin descubrir a golpes qué funciona.
Se implementan dos o tres parámetros y el resto se ignora en silencio, devolviendo todo como si el filtro no existiera.
Los parámetros declarados se implementan o no se declaran. Y la paginación se prueba con los volúmenes reales del origen, no con datos de prueba.
Se usan claves internas como si fueran ids FHIR, se referencian recursos que la capa nunca expone y se mandan códigos locales sin decir de dónde vienen.
Toda referencia se resuelve o se declara como lógica, los identificadores de negocio viajan en identifier con su system, y todo código lleva declarado el suyo.
Ante un problema se devuelve un 500 genérico o, peor, un 200 con el recurso incompleto.
Los errores se devuelven como OperationOutcome, con severidad, código y una ubicación que le diga al consumidor qué corregir.
Se rellena con un valor por defecto, una fecha inventada o un código genérico para que el recurso valide.
Lo ausente se representa como ausente. Cuando la guía exige el elemento, se usan los mecanismos previstos para datos desconocidos y se documenta la brecha, en vez de fabricar el dato.
La capa en operación y todo lo necesario para consumirla, auditarla y hacerla evolucionar sin nosotros.
El servicio desplegado, con sus endpoints, su seguridad y su configuración documentada.
Correspondencia elemento a elemento entre el origen y los recursos, con las decisiones registradas.
Equivalencias declaradas entre los códigos locales y las terminologías estándar.
Lo que la capa soporta realmente: recursos, operaciones y parámetros de búsqueda.
Ejemplos válidos, ejemplos que deben fallar y las pruebas que corren en cada cambio.
Métricas de latencia, error y frescura, con alertas sobre lo que no se pudo transformar.
Cómo autenticarse, qué buscar, qué esperar y qué límites tiene la capa.
Qué se materializa después, qué dominios siguen y cuándo conviene revisar el modo de entrega.
Infraestructura FHIR construida sobre sistemas y plataformas que ya existían y siguieron funcionando.
Meddyg implementó y desplegó a producción el primer servidor FHIR que recibiría las notificaciones de enfermedades de notificación obligatoria, vacunas y resultados de laboratorio del EDUS/CCSS, y posteriormente de otros establecimientos de salud.
Parte del equipo de Meddyg participó como consultor en el diseño e implementación de la infraestructura que recibiría las notificaciones regionales de ESAVI, junto con la guía que define su formato.
Pruebas de concepto junto a la Agencia Nacional de Gobierno Digital para validar transacciones de recursos FHIR sobre la plataforma nacional X-Road, dentro de la demostración funcional de interoperabilidad de Costa Rica.
Asistencia técnica para que los equipos del Banco Central de Costa Rica habilitaran el firmado de recursos FHIR con el formato JAdES dentro de GAUDI, su plataforma de firma digital y sellado.
Los casos anteriores son infraestructura FHIR construida sobre sistemas y plataformas que ya operaban. El mismo método —análisis del origen, mapeo, elección del modo de entrega y validación de conformidad— es el que aplicamos a una fachada sobre un expediente o un sistema departamental heredado.
Todos comparten la misma restricción: el sistema de origen no se puede detener ni reemplazar en el plazo en que hay que interoperar.
Un sistema clínico que no se va a reemplazar y al que ahora le piden exponer datos, notificar o conectarse a una red.
Productos que deben demostrar capacidad FHIR ante clientes y licitaciones sin rehacer su base de datos.
Resultados e informes que deben salir hacia múltiples receptores externos con la misma estructura y los mismos códigos.
Sistemas de misión crítica que deben participar en un ecosistema nacional sin abrir su base de datos ni detener su operación.
Ecosistemas que incorporan participantes cuyos sistemas no hablan el estándar y necesitan un patrón de conexión repetible.
Intercambio con prestadores cuyos sistemas exponen formatos propios y evolucionan a su propio ritmo.
Si alguna de estas situaciones describe su organización, una capa FHIR puede resolver el intercambio sin poner en riesgo lo que ya funciona.
Una capa bien diseñada deja a los sistemas actuales participando del ecosistema, sin tocar su operación ni hipotecar la ruta de modernización.