La palabra interoperabilidad aparece en todos los pliegos de licitación de salud y en todas las presentaciones comerciales. Casi siempre sin definición. Y como nadie quiere quedar afuera, todos los sistemas dicen ser interoperables, lo cual convierte a la palabra en información sin contenido.
Conviene entonces empezar por el problema, no por la sigla.
El problema
Un paciente se atiende en un centro de atención primaria, se interna en el hospital de cabecera, se hace un laboratorio en un prestador privado y retira medicación en una farmacia. Cuatro sistemas distintos, cuatro veces el mismo paciente cargado de cero, y ningún profesional con la historia completa delante.
Interoperar es que esos sistemas puedan intercambiar información sobre el mismo paciente sin que una persona la transcriba. Eso es todo. El resto es cómo.
Qué es FHIR
FHIR (se pronuncia "fire") es un estándar de la organización HL7 para intercambiar información de salud. La idea central es simple: define un conjunto de recursos, que son las cosas de las que habla el mundo sanitario, y una forma estándar de pedirlos y devolverlos.
Un Patient es un paciente. Un Encounter es una atención. Una Condition es un diagnóstico. Una Observation es un signo vital o un resultado. Un MedicationRequest es una prescripción. Cada recurso tiene una estructura definida, y se piden por una interfaz web común, devolviendo datos en un formato que cualquier sistema moderno sabe leer.
Lo importante para una institución no es la especificación técnica, sino la consecuencia: si dos sistemas hablan FHIR, la integración entre ellos deja de ser un desarrollo a medida y pasa a ser una configuración. Y ese es exactamente el cambio que importa, porque el desarrollo a medida es lo que hace que integrar dos sistemas cueste más que comprar uno de ellos.
Por qué esto llegó a Argentina para quedarse
La estrategia nacional de salud digital adoptó FHIR como estándar de intercambio. Y la receta electrónica lo empujó desde otro lado: cuando la prescripción tiene que poder verificarse por fuera del sistema que la emitió, ya no hay integración opcional. Un recetario que no puede ser leído por nadie más no sirve.
El resultado práctico es que un sistema de gestión sanitaria sin capacidad FHIR quedó fuera de una parte creciente de los pliegos, más allá de qué tan bueno sea puertas adentro.
Las preguntas que conviene hacer
Si un proveedor dice que su sistema es interoperable, hay cinco preguntas que ordenan la conversación bastante rápido:
1. ¿Qué recursos expone? "Interoperable" sin lista de recursos no significa nada. Que exponga Patient es el mínimo. Que exponga Encounter, Condition, Observation, MedicationRequest y AllergyIntolerance ya es una respuesta seria.
2. ¿Lee, escribe o las dos cosas? No es lo mismo exponer información para que otro la consulta (lectura) que aceptar que otro sistema escriba en la base. Empezar por lectura es una decisión de diseño perfectamente razonable, y bastante más prudente. Lo que no es razonable es que no quede claro cuál de las dos es.
3. ¿Qué terminologías usa? Esta es la pregunta que separa la interoperabilidad real de la de folleto. Dos sistemas pueden intercambiar un diagnóstico perfectamente estructurado y aun así no entenderse, si uno dice "diabetes tipo 2" en texto libre y el otro espera un código. Sin vocabularios comunes (CIE-10 para diagnósticos, SNOMED para conceptos clínicos, un vademécum codificado para medicamentos), FHIR transporta texto que nadie puede procesar. El estándar es el sobre; la terminología es el idioma de la carta.
4. ¿Cómo se autentica y se audita? Una interfaz que expone historias clínicas es una superficie de acceso a datos sensibles. Quién accede, con qué permiso, a qué pacientes y con qué registro de auditoría son parte del diseño, no un agregado.
5. ¿Se puede probar? Una interfaz que existe se puede consultar. Es una pregunta desagradable y muy eficaz.
Lo que la interoperabilidad no resuelve
Conviene decirlo porque genera expectativas desmedidas. FHIR es el mecanismo de transporte y el formato. No resuelve por sí solo tres problemas que son de la institución y no del estándar:
- La identificación del paciente. Si en un sistema es un documento y en otro es un número interno, el intercambio va a mezclar personas. La identidad unívoca del paciente es un requisito previo, no un resultado.
- La calidad del dato. Un diagnóstico mal cargado sigue estando mal cargado del otro lado, ahora en formato estándar.
- El acuerdo entre las partes. Quién comparte qué con quién, con qué consentimiento y bajo qué marco es una decisión institucional y legal. La tecnología la ejecuta; no la toma.
Por dónde se empieza
La secuencia que funciona es siempre la misma, y no empieza por la integración:
- Identificar bien al paciente. Un paciente, un registro. Sin duplicados.
- Codificar. Diagnósticos con CIE-10, medicamentos contra un vademécum real. Mientras el dato sea texto libre, no hay nada que interoperar.
- Exponer lectura. Que otro sistema autorizado pueda consultar los datos del paciente.
- Recién ahí, escritura e integraciones puntuales.
Saltar los dos primeros pasos es el error más caro y el más común: se compra interoperabilidad para una base de datos que todavía no está en condiciones de ser interoperada.
En resumen
FHIR no es una función que se prende: es la consecuencia de tener los datos identificados y codificados. Para una institución, la pregunta útil no es si el sistema "es interoperable", sino qué recursos expone, con qué terminologías, con qué seguridad y si se puede probar hoy.
Inforint Salud cuenta con una capa de interoperabilidad HL7 FHIR R4 en funcionamiento, con diagnósticos codificados en CIE-10 y conceptos clínicos en SNOMED. Si su institución tiene requerimientos de integración, escríbanos y lo conversamos en concreto.