Facade o repositorio: cómo decidir el camino hacia FHIR

Para la mayoría de las instituciones de salud, la pregunta ya no es si van a adoptar HL7® FHIR®. La regulación, los proyectos nacionales de expediente único y la presión de los propios equipos clínicos cerraron esa discusión.

La pregunta que sigue abierta es cómo. Y ahí se toman decisiones de arquitectura que después cuestan mucho revertir.

El facade

Un FHIR facade es una capa que expone una API conforme al estándar sobre un sistema que no lo habla. Traduce entre el formato FHIR y el formato propio del sistema de fondo, de modo que las aplicaciones consultan sin conocer la estructura interna del sistema legado. El dato se queda donde está: cuando llega una consulta, se mapea al vuelo y se devuelve en tiempo real desde la fuente original.

Eso le da dos ventajas que el otro camino no iguala. No duplica nada, así que no hay una segunda copia de la historia clínica que mantener, respaldar y explicar ante una auditoría. Y el dato siempre está al día, porque lo que devuelve la consulta es lo que hay en el sistema en ese momento.

Para una aseguradora que necesita exponer unos pocos recursos de solo lectura a aplicaciones de terceros, el facade es la respuesta correcta. No tiene sentido mantener una copia completa de la data para servir consultas puntuales.

El costo aparece del otro lado. Cada consulta golpea al sistema de producción, así que si el HIS ya va justo de rendimiento en horario pico, ahora carga también con el tráfico FHIR. La latencia de la respuesta es la latencia del sistema legado: si esa base de datos tarda ocho segundos en una consulta compleja, el facade tarda ocho segundos. Y la conformidad se vuelve difícil de garantizar, porque la traducción ocurre en el momento de la consulta y no existe un punto donde verificar que todo el acervo cumple el perfil oficial. Los incumplimientos se descubren de uno en uno, cuando fallan.

La latencia de la respuesta es la latencia del sistema legado.

El costo mayor está en la construcción. El facade se levanta escribiendo código: implementando proveedores de recursos sobre un servidor FHIR base, o personalizando las clases de servicio del motor comercial que se haya adquirido. Hay guías completas dedicadas a construir uno desde cero con Python y una base de datos relacional.

Cuando el patrón se lleva a escala nacional, el inventario queda a la vista. La guía de implementación del FHIR Facade de Tanzania combina perfiles, modelos lógicos de las estructuras legadas, mapas de transformación en ambas direcciones, ConceptMaps, mediadores de integración, un motor de mapeo y un servidor de validación dedicado. Eso es un equipo de ingeniería sostenido en el tiempo.

El repositorio

En el modelo repositorio se crea un activo nuevo: una copia de la data almacenada de forma nativa como recursos FHIR. La conversión ocurre antes de que llegue cualquier consulta. La diferencia de fondo entre los dos modelos se reduce a dónde vive el dato.

El repositorio verifica la conformidad una sola vez y la deja demostrada. Cada recurso se valida contra el Implementation Guide oficial al momento de cargarse, de manera que cuando la autoridad sanitaria pida evidencia, existe un informe. Las consultas son rápidas y no tocan producción, porque el repositorio está diseñado para responder consultas FHIR y el HIS ni se entera. Sirve además para analítica clínica, tableros de calidad, investigación y reporte regulatorio, cosa que un facade no hace. Y absorbe múltiples fuentes de forma natural: tres sistemas de tres proveedores distintos convergen en una sola superficie consultable.

La diferencia de fondo entre los dos modelos se reduce a dónde vive el dato.

Lo que cuesta es igual de concreto. Hay una copia más de la data clínica, con todo lo que implica en seguridad, respaldo y gobernanza. Hay una ventana de desactualización entre la fuente y el repositorio, que según el caso de uso puede ser irrelevante o inaceptable.

Y hay que construir y mantener el proceso de carga. Históricamente esa ha sido la objeción fuerte contra el repositorio: el ETL hacia FHIR es en sí mismo un proyecto de desarrollo, con sus mapeos en código, su equipo especializado y su deuda técnica.

La comparación

                      FACADE                 REPOSITORIO
Dónde vive el dato    Sistema origen         Copia nativa FHIR
Cuándo se traduce     Al consultar           Antes de consultar
Actualidad del dato   Total                  Ventana de sincronización
Duplicación           Ninguna                Sí
Carga en producción   En cada consulta       Solo al sincronizar
Conformidad           Difícil de garantizar  Verificable y auditable
Múltiples fuentes     Uno por sistema        Convergen en uno solo
Uso analítico         Limitado               Natural

Lo que cambió entre las dos columnas

Si lee la comparación con honestidad, para la mayoría de las instituciones que necesitan un expediente institucional unificado, reportar a la autoridad y hacer analítica clínica, el repositorio es el destino correcto. El caso es fuerte aunque la discusión no esté cerrada.

La razón por la que muchas instituciones terminan eligiendo el facade rara vez es arquitectónica. Es que el camino al repositorio les parecía demasiado caro. Y ese costo venía de cómo se construía el proceso de carga: en código, por especialistas, uno a uno.

Muchas instituciones eligen el facade por el precio del ETL, no por la arquitectura.

Esa parte cambió. Un motor declarativo invierte la ecuación. En lugar de programar la transformación, se define de dónde sale el dato, hacia dónde va, con qué mapeo y contra qué estándar. El mapeo se arma visualmente, campo a campo, con validación contra el Implementation Guide oficial mientras se construye. La traducción de terminologías locales a vocabularios internacionales se maneja como configuración versionada y no como reglas cableadas.

La arquitectura sigue siendo la misma. Lo que baja es su costo de construcción y de mantenimiento, que era el único argumento que sostenía la decisión contraria.

¿Quién va a mantener esto en cinco años? Es la pregunta más importante y la que menos se hace.

Cinco preguntas antes de decidir

• ¿Necesita que el dato sea del segundo exacto? Si la respuesta es sí para su caso de uso crítico, el facade tiene una ventaja que el repositorio no iguala.
• ¿Cuántas fuentes tiene, y cuántas va a tener en tres años? Un facade por sistema escala mal, mientras que el repositorio absorbe fuentes nuevas.
• ¿Le van a pedir evidencia de conformidad? Si hay un mandato nacional detrás, demostrar cumplimiento recurso por recurso deja de ser opcional.
• ¿Qué tanto aguanta su sistema de producción? Si el HIS ya va apretado, sumarle tráfico de consulta en vivo tiene consecuencias operativas medibles.
• ¿Quién va a mantener esto en cinco años? Es la pregunta más importante y la que menos se hace. Si el conocimiento del mapeo vive en el código de un equipo específico, la institución queda expuesta el día que ese equipo no esté.

Sobre lo que estamos construyendo

En arco health desarrollamos Harmony, un motor declarativo de interoperabilidad que construye y mantiene repositorios FHIR sin escribir código, con validación en tiempo real contra el estándar y traducción de terminologías incluida. El procesamiento ocurre dentro de la infraestructura del cliente.

Harmony no responde a todos los casos. Cuando el caso de uso exige consulta en vivo sin copiar el dato, el camino es otro, y lo abordaremos en una próxima entrega de esta serie.

Si su institución concluyó que necesita un repositorio y se frenó por el costo de construirlo, revise ese supuesto antes de volver a presupuestar. Escríbanos a [email protected] y le mostramos Harmony funcionando con sus propios datos.

La próxima entrega entra al facade a fondo: qué hay que construir realmente y en qué casos sigue siendo la decisión correcta.

HL7® y FHIR® son marcas registradas de HL7 International.