El facade por dentro: qué hay que construir y cuándo vale la pena

En la entrega anterior reconocimos que el facade tiene dos ventajas que el repositorio no iguala: no duplica el dato y lo entrega al día. Esta vez lo abrimos, porque en una demostración parece una capa delgada y en producción es un servidor FHIR completo que alguien tiene que escribir y mantener durante años.

Una consulta de apariencia simple

GET /Observation?patient=123&category=laboratory&date=ge2026-01-01&_count=20

Para responderla, el facade tiene que saber qué paciente del HIS es el 123, en qué tabla están los resultados de laboratorio y cómo convertir el prefijo ge en una condición sobre la fecha. Después pagina, convierte cada fila en un Observation con su código LOINC y devuelve un enlace a la página siguiente que siga funcionando mientras el médico lee.

Eso cubre un solo parámetro de búsqueda de un solo recurso.

En una demostración parece una capa delgada. En producción es un servidor FHIR completo.

Lo que la plataforma resuelve y lo que queda de su lado

Varias plataformas de servidor FHIR ofrecen hoy un modo facade, y conviene ser preciso sobre qué aportan. Resuelven el andamiaje: la API REST, la lectura de los parámetros de búsqueda, la paginación, la seguridad y la auditoría. Eso ahorra meses de trabajo.

Lo que no resuelven es la traducción de la consulta al esquema del sistema de origen ni la conversión de cada fila en un recurso conforme al perfil. Esa mitad se escribe en el lenguaje de la plataforma elegida y la mantiene el equipo de la institución.

PIEZA                    QUIÉN LA ESCRIBE
API REST y búsqueda      La plataforma
Seguridad y auditoría    La plataforma
Traductor de consultas   Su equipo
Mapeo por recurso        Su equipo
Identidad estable        Su equipo
Terminología             Su equipo
Conformidad              Su equipo

Tres de esas piezas se subestiman casi siempre. Si el HIS cambia la clave de un paciente al fusionar dos registros, las referencias que otros sistemas ya guardaron dejan de apuntar a algo. Si una prueba del catálogo local nunca se mapeó a LOINC, sale con su código propio y el error aparece cuando el receptor reclama. Y como validar cada respuesta agrega tiempo a cada consulta, la mayoría de los facades no valida en producción: cuando la autoridad pida evidencia de cumplimiento, no hay informe que entregar.

El dilema del caché

Cada consulta al facade es una consulta al sistema de producción. Si el HIS tarda ocho segundos, el facade tarda ocho segundos más la traducción.

La salida habitual es poner un caché delante. Un caché es una copia del dato con una ventana de desactualización. En ese momento el facade perdió las dos ventajas que justificaban elegirlo y conserva todo el costo de construcción.

Un caché es una copia del dato con una ventana de desactualización.

Con la analítica pasa algo parecido. La exportación masiva de FHIR recorre la base de producción entera, así que muchas instituciones la programan de madrugada y guardan el resultado. En la práctica, es un repositorio construido sin planearlo.

Ese código depende de dos cosas que la institución no controla: el esquema del HIS, que cambia con cada versión del fabricante, y el Implementation Guide, que cambia cuando la autoridad lo actualiza.

Cuándo sigue siendo la decisión correcta

Hay casos donde el facade es la mejor opción. Cuando el valor está en el estado actual del dato, como la agenda de citas libres o la medicación activa en el punto de atención. Cuando una restricción legal impide mantener una segunda copia. Cuando la exposición es pequeña y estable: pocos recursos, solo lectura, una fuente y un consumidor.

Y antes de construir nada, conviene revisar si el fabricante del HIS ya ofrece una API FHIR nativa. Esa API es un facade que mantiene otro, y la pregunta pasa a ser si cubre los perfiles que exige la autoridad.

Fuera de esos casos, con varias fuentes y un mandato de conformidad demostrable, la lista de arriba se multiplica por cada sistema.

Lo que viene

Queda abierto un escenario: un médico que necesita ver en tiempo real la historia de un paciente atendido en cuatro establecimientos que no van a entregar su data a una base central. Ahí la pregunta pasa de cómo expone sus datos una institución a cómo se consulta una red. Volveremos sobre ese patrón en esta serie.

La próxima entrega entra en el problema que ni el facade ni el repositorio resuelven por su cuenta: la terminología, la parte de los proyectos FHIR que menos se presupuesta.

Si su institución está evaluando construir un facade, escríbanos a [email protected] y contrastamos esta lista con su caso.

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