Cada cierto tiempo vuelve a circular la misma infografía: dos hospitales a los lados, un bus de integración al centro, unas flechas que van y vienen y, encima de todo, el logo de HL7 FHIR como sello de garantía. El mensaje implícito es sencillo: instale esto y sus sistemas interoperarán.
He participado en guías de implementación FHIR nacionales y regionales. Precisamente por eso puedo decirlo sin rodeos: esa infografía no describe una arquitectura de interoperabilidad. Describe, en el mejor de los casos, una tubería.
Pongámosla a prueba con un caso cotidiano. Una mujer de 67 años con insuficiencia cardíaca, atendida durante años en un hospital privado, llega a las dos de la mañana a la urgencia de un hospital público. El médico de turno necesita su resumen clínico: diagnósticos, medicamentos, alergias. Tiene cinco minutos.
En el hospital privado está registrada con su número de cédula. En el público, con un número de expediente y el segundo apellido mal escrito. ¿Quién decide que son la misma persona? Nadie en el hospital público sabe que existe un resumen en el privado, ni en qué servicio está disponible.
Cuando la consulta llegue, el hospital privado tendrá que saber quién la hace, si es un profesional habilitado, desde qué organización y con qué propósito. Tendrá que saber si ella autorizó compartir su información y quién evalúa esa autorización. Su furosemida tendrá que significar lo mismo en los dos sistemas. Y mañana alguien tendrá que poder demostrar quién vio qué, cuándo y por qué.
Las flechas de la infografía no responden ninguna de esas preguntas. Y ninguna se resuelve eligiendo el recurso FHIR correcto.
Lo que FHIR sí es
Conviene ser precisos, porque la crítica fácil también es humo. FHIR no es "solo sintaxis". Define recursos con semántica clínica, interacciones REST, mensajería y documentos. También define mecanismos de conformidad, vínculos con terminologías y hasta recursos para consentimiento, procedencia y auditoría. Es probablemente el avance más importante en estándares de salud de las últimas dos décadas.
Pero la propia especificación es clara sobre su alcance. En su sección de perfilamiento, HL7 describe FHIR como una especificación de plataforma. Es una base común sobre la que se construyen soluciones distintas, y normalmente requiere adaptarse a cada contexto de uso mediante perfiles y guías de implementación. En su sección de seguridad, advierte que FHIR no es un protocolo de seguridad y que depende de mecanismos definidos en otros lugares.
Esa distinción tiene consecuencias prácticas:
- FHIR define el recurso
Consent, pero no decide qué política de consentimiento aplica en un país ni implementa el motor que la hace cumplir. - Define
AuditEvent, pero no garantiza que alguien audite, ni define cuánto tiempo se conserva el registro o quién lo revisa. - Define
Patient, pero no decide cuál es el identificador oficial ni cómo se resuelven los duplicados.
Por eso decir que un sistema "soporta FHIR" dice muy poco. La conformidad siempre es contra algo: una guía de implementación, un conjunto de perfiles, una versión, un CapabilityStatement. Afirmar que un sistema es interoperable porque "habla FHIR" se parece a afirmar que un contrato es válido porque está escrito en español.
Lo que el dibujo no responde
Volvamos a urgencias. Cada pregunta del caso corresponde a una capacidad que alguien tiene que diseñar, operar y gobernar.
Identidad. Antes de pedir cualquier dato, ambos hospitales necesitan saber que hablan de la misma persona. Eso exige un índice maestro de pacientes y reglas de correlación. También exige una política sobre qué identificador manda y un procedimiento para cuando el algoritmo se equivoca.
Descubrimiento. El hospital público necesita saber qué organizaciones participan, qué profesionales trabajan en ellas y dónde están sus servicios. Eso es un directorio, con reglas sobre quién lo mantiene y cómo se actualiza.
Intercambio. El resumen hay que publicarlo, encontrarlo y recuperarlo. Aquí FHIR hace el trabajo pesado, pero dentro de un contrato que dice exactamente quién envía qué a quién.
Contenido. Que el documento llegue no sirve si no se entiende. El resumen necesita una estructura acordada, como el International Patient Summary y una guía nacional que lo adapte. También necesita terminologías vinculadas: SNOMED CT, LOINC, un catálogo de medicamentos. Es la parte más "FHIR" del problema y, aun así, exige gobernanza: quién mantiene los conjuntos de valores, qué terminología es oficial, quién paga las licencias.
Acceso y consentimiento. El hospital privado tiene que verificar quién consulta, con qué derecho y si la paciente autorizó compartir. Los perfiles hacen ejecutable esa política, pero ninguno la escribe.
Trazabilidad. Cada acceso debe quedar registrado de forma verificable. Para que una auditoría tenga valor, todos los sistemas deben coincidir en la hora. Hasta el reloj tiene que estar gobernado.
IHE ha especificado cada una de estas capacidades como perfiles con actores y transacciones concretas:
| Pregunta del caso | Capacidad | Perfil IHE / guía HL7 |
|---|---|---|
| ¿Es la misma persona? | Identidad | PIXm, PDQm; PMIR para gestionarla en la comunidad |
| ¿Quién es quién y dónde está el servicio? | Directorio | mCSD |
| ¿Dónde está el resumen y cómo lo obtengo? | Intercambio de documentos | MHD (ITI-65, ITI-67, ITI-68) |
| ¿El contenido significa lo mismo? | Contenido y terminología | IPS + guía nacional; SVCM |
| ¿Quién lo pide y con qué derecho? | Autorización | IUA (OAuth 2.0); SMART App Launch |
| ¿Lo autorizó la paciente? | Consentimiento | PCF |
| ¿Queda rastro verificable? | Auditoría | ATNA, BALP |
| ¿Coinciden los relojes? | Tiempo consistente | CT |
Hay un dato que resume el argumento mejor que cualquier opinión. IHE publicó MHDS, un perfil cuyo propósito es describir los servicios mínimos de una comunidad de intercambio de documentos basada en FHIR. MHDS no inventa un estándar nuevo: agrupa MHD con identidad, directorio, auditoría y tiempo consistente, entre otros. Si un servidor FHIR bastara para intercambiar documentos entre instituciones, ese perfil no tendría razón de existir.
No todos estos perfiles son obligatorios en todos los proyectos. Lo que demuestran es que cada capacidad tiene actores, transacciones y responsabilidades que no aparecen por instalar un servidor.
Ni siquiera IHE es la arquitectura
Sería fácil convertir este artículo en "FHIR contra IHE", pero sería otra simplificación. Los perfiles IHE son contratos de integración reutilizables, y muchos están construidos sobre FHIR. Lo que un contrato no decide son las preguntas que vienen antes:
- ¿El índice de pacientes será central o federado, y quién lo opera?
- ¿Con qué base legal se comparte información sin consentimiento en una urgencia?
- ¿Qué organización certifica a los participantes?
- ¿Quién responde cuando un dato es incorrecto?
Los marcos que mejor funcionan en el mundo empiezan precisamente por ahí. OpenHIE construye su arquitectura a partir de flujos de trabajo. Los asigna a componentes compartidos y luego los mapea a perfiles IHE. Esos componentes incluyen los registros de clientes, de establecimientos y de trabajadores de salud, la terminología, el registro clínico compartido y la capa de interoperabilidad.
Las SMART Guidelines de la OMS colocan los Digital Adaptation Kits en una capa anterior a la guía FHIR. Esos kits contienen personas, procesos de negocio, diccionario de datos y lógica de decisión. Primero el proceso; después el estándar.
Estados Unidos ofrece el ejemplo más elocuente. Es el país que hizo obligatorias por regulación las APIs FHIR en la tecnología de salud certificada. Aun así, para interoperar a escala nacional necesitó TEFCA. TEFCA combina un marco de confianza, un acuerdo común firmado por los participantes y redes designadas (QHIN) con obligaciones explícitas. El intercambio entre esas redes se apoya en buena medida en perfiles IHE. El país con más FHIR desplegado del mundo no resolvió la interoperabilidad solo con FHIR: la resolvió con gobernanza.
El marco europeo refinado de interoperabilidad en salud (ReEIF) lo expresa en seis capas: legal y regulatoria, política, proceso asistencial, información, aplicaciones e infraestructura. FHIR ocupa, a lo sumo, dos de ellas. Las otras cuatro no se compran; se diseñan y se acuerdan.
El costo del atajo
Confundir una plataforma con una arquitectura no es un error teórico. Tiene costos que aparecen dos o tres años después de la compra, cuando ya es caro corregirlos.
La dependencia del proveedor. Un servidor FHIR sin guía de implementación nacional se llena de extensiones propias. Los datos quedan en FHIR, pero en un FHIR que solo entiende ese producto.
Las integraciones punto a punto disfrazadas. Un bus que conecta cada institución con reglas de transformación particulares no elimina la complejidad: la esconde. Cada nuevo participante es un proyecto nuevo, y la solución no se puede reproducir en otra región ni con otro proveedor.
La seguridad agregada al final. Cuando la autorización, el consentimiento y la auditoría no se diseñaron desde el inicio, se agregan como parches, o simplemente no se agregan. El riesgo recae en las instituciones y en los pacientes, no en quien vendió la plataforma.
El repositorio central que copia todo. Sin identidad, directorio ni localización de documentos, la salida más rápida suele ser centralizar copias de los datos de todos. Funciona en la demostración y complica todo lo demás: la responsabilidad sobre el dato, la sincronización, la privacidad y la confianza de las instituciones que deben entregar su información.
Nada se puede verificar. Este es quizá el costo más grave. Sin perfiles declarados ni pruebas de conformidad, nadie puede demostrar que dos sistemas interoperan correctamente. Solo se puede confiar en la presentación.
Antes de comprar, pregunte
Una solución puede ser completamente compatible con HL7 FHIR y, aun así, ser insuficiente para el caso para el que fue adquirida. Por eso las instituciones deberían evaluar las propuestas por las capacidades que demuestran, no por la lista de tecnologías que mencionan. Estas preguntas ayudan a separar una arquitectura de una presentación:
- ¿Contra qué guías de implementación y perfiles declara conformidad, y en qué versión de FHIR? "Soportamos FHIR" no es una respuesta.
- ¿Publica su
CapabilityStatement? - ¿Qué actores IHE implementa y qué transacciones soporta cada uno?
- ¿Qué evidencia de pruebas tiene: Connectathon, Gazelle, Inferno, validadores de la guía nacional?
- ¿Cómo se resuelve la identidad del paciente y quién gobierna el índice maestro?
- ¿Dónde se evalúa el consentimiento y dónde queda registrada la auditoría?
- ¿Qué extensiones propietarias utiliza y cómo se exportan los datos si se cambia de proveedor?
Si las respuestas son vagas, el problema no es técnico. Es que no hay arquitectura detrás.
Primero la arquitectura, después la tecnología
La paciente de urgencias no necesita un servidor FHIR. Necesita que su médico vea, en cinco minutos, la información correcta de la persona correcta. Necesita que eso ocurra con su autorización o con la base legal que la sustituya, y que quede constancia. Lograrlo exige decidir procesos, roles, responsabilidades, servicios compartidos y reglas de confianza. FHIR es indispensable para eso, pero no es suficiente.
Las instituciones que empiezan por el proceso terminan eligiendo mejor la tecnología. Las que empiezan por la tecnología suelen descubrir el proceso cuando ya firmaron el contrato.
FHIR nos proporciona un lenguaje común para intercambiar información sanitaria. La arquitectura determina quién puede utilizarlo, para qué, bajo qué condiciones y cómo ese intercambio se convierte en un proceso de salud interoperable. No confundamos hablar el mismo lenguaje con saber trabajar juntos.
Referencias
- HL7 FHIR R5, Profiling FHIR
- HL7 FHIR R5, Security
- IHE IT Infrastructure: perfiles MHD, MHDS, mCSD, PIXm, PDQm, PMIR, IUA, PCF, BALP, SVCM y CT
- OpenHIE, Architecture Specification
- Organización Mundial de la Salud, SMART Guidelines
- eHealth Network, Refined eHealth European Interoperability Framework (ReEIF)
- ONC/ASTP (EE. UU.), Trusted Exchange Framework and Common Agreement (TEFCA)
Boletín de Meddyg
Noticias, novedades de interoperabilidad y salud digital, y lo nuevo de nuestros servicios y productos.