Imaginá un grupo chico de consultorios. Los turnos viven en un programa, los resultados de laboratorio llegan como PDF por mail, las facturas se preparan en una tercera herramienta y los pacientes reciben recordatorios desde una cuarta. Todas las mañanas alguien de recepción copia un nombre, una fecha de nacimiento y un teléfono de una pantalla a otra. Nadie lo planeó así. Simplemente fue creciendo, una compra sensata a la vez.
Si te suena, ya conocés el problema de la interoperabilidad. Tiene nombre técnico, pero el costo es muy humano: tipear de nuevo, errores y horas de personal dedicadas a ser el cable entre dos programas.
Por qué los sistemas de salud no se hablan entre sí
La mayoría de los sistemas los hicieron empresas distintas, en momentos distintos, para tareas distintas. Cada uno guarda al paciente a su manera, con sus propios nombres de campos, sus propios formatos y su propia idea de qué contiene un "turno". Dos programas pueden ser excelentes y aun así no compartir idioma.
La solución habitual es una conexión a medida entre cada par de sistemas. Funciona, hasta que uno de los lados cambia algo. Entonces la conexión se rompe, casi siempre un lunes con mucho trabajo, y nadie se acuerda de quién la hizo.
Qué son HL7 y FHIR, sin jerga
HL7 es una organización que publica estándares para intercambiar información de salud. FHIR, sigla de Fast Healthcare Interoperability Resources, es uno de sus estándares. El propio sitio de HL7 lo describe como un estándar para el intercambio de datos de atención de la salud.
La idea clave está en la palabra "recursos". En FHIR, todo lo que se puede intercambiar está definido como un recurso: por ejemplo, el paciente tiene una definición acordada que cubre la información administrativa básica de una persona que recibe atención. Si dos sistemas coinciden en cómo es un "Patient", necesitan mucha menos traducción privada para cada par.
Pensalo como un formulario común que las dos partes acuerdan completar de la misma manera.
Qué significa "tenemos una API FHIR" para vos
Una API es una puerta que permite que un programa hable con otro sin una persona en el medio. La API REST de FHIR describe un conjunto estándar de operaciones para esa puerta sobre sus recursos: leer un registro, buscar registros que cumplan ciertos criterios, crear uno nuevo, actualizar uno existente.
En criollo: un sistema con API FHIR puede responder a algo como "buscá a este paciente" de una forma que otro programa compatible con FHIR ya entiende, en lugar de que pagues una traducción única.
Dos aclaraciones honestas. Primero, una API FHIR no significa que todo esté conectado. La documentación de HL7 indica que cada servidor declara qué interacciones soporta, así que un producto puede permitirte solo leer datos y otro también escribirlos. Segundo, el estándar tiene versiones numeradas, así que "soporta FHIR" es una frase incompleta hasta que sepas cuál versión y para qué datos.
Qué hace un sistema a medida al respecto
Un buen sistema a medida no necesita doblar todo su diseño alrededor de un estándar. Un enfoque sensato es lo contrario: mantener un modelo interno que encaje con cómo trabaja tu consultorio y sumar una capa de traducción en el borde. Esa capa convierte tus datos hacia y desde un formato estándar cuando necesitás intercambiarlos con un laboratorio, un hospital o el sistema de otro prestador.
La ventaja es que el resto de tu software no queda atado al formato de otro. Si un socio cambia de versión o de formato, modificás una capa, no todo el sistema.
También significa que vos decidís qué sale de tu casa. La capa se puede configurar para compartir solo lo que cada socio necesita, con registro de quién pidió qué. Con datos de salud eso no es un detalle.
Además, cuidado con prometer más de lo que el estándar promete. Si un laboratorio, una obra social o un organismo de tu país puede o debe intercambiar datos por FHIR depende de las normas locales y de los sistemas de esa organización. Preguntales. No lo des por hecho.
Preguntas para hacerle a un proveedor o desarrollador
No hace falta entender la especificación para hacer buenas preguntas:
- ¿Qué versión de FHIR soportan, y para qué tipos de registros (pacientes, turnos, resultados...)?
- ¿Solo puedo leer datos a través de la conexión, o también agregar y modificar?
- ¿Quién puede usar la conexión, y cómo se controla y registra el acceso?
- ¿Hay un entorno de prueba para probar la conexión primero con pacientes falsos?
- ¿Qué pasa cuando un mensaje falla: nos enteramos, o desaparece?
- ¿Quién mantiene la conexión cuando cualquiera de los dos lados actualiza, y cuánto cuesta?
- Si te dejamos, ¿podemos sacar todos nuestros datos en un formato utilizable?
Las respuestas vagas a estas preguntas dicen más que cualquier folleto.
Empezá por lo que se vuelve a tipear
No necesitás una estrategia de interoperabilidad para arrancar. Durante una semana, anotá cada vez que alguien copia información de un programa a otro: un resultado, una derivación, los datos de un paciente. Contá cuántas veces pasa y cuánto tarda.
Esa lista es tu requisito real. Normalmente dos o tres de esos traspasos concentran casi todo el dolor, y son los que conviene conectar primero, de la forma más simple que sea segura y mantenible.