FHIR no obliga a reconstruir su HIS

Una preocupación aparece con frecuencia cuando una organización empieza a evaluar FHIR: “Si queremos intercambiar información mediante FHIR, ¿nuestros sistemas también tendrán que almacenar internamente sus datos en FHIR?”

No necesariamente.

FHIR es un estándar publicado por HL7 para el intercambio electrónico de información sanitaria. Su especificación contempla APIs REST, mensajería, documentos y otros mecanismos de intercambio. HL7 también documenta expresamente su relación con HL7 v2 y la posibilidad de que diferentes paradigmas convivan.

La interfaz y el sistema interno no tienen que ser iguales

Un HIS puede mantener su modelo interno. Un LIS puede continuar operando sobre estructuras construidas años atrás. Una integración existente puede seguir utilizando HL7 v2.

Entre esos sistemas y los nuevos consumidores de información puede existir una capa que interprete, transforme y exponga determinados datos mediante recursos FHIR.

Arquitectónicamente, esto permite introducir FHIR sin convertir la adopción del estándar en una reconstrucción completa del hospital.

FHIR puede convertirse en una forma común de conversar sin convertirse en la forma interna de almacenar todo.

La decisión importante viene antes del estándar

Antes de preguntar cómo convertir todo a FHIR, conviene responder preguntas más concretas: qué información necesitamos intercambiar, quién la necesita, para qué proceso, cuáles son las fuentes de verdad y dónde debemos resolver identidad, semántica o reglas de negocio.

FHIR proporciona mecanismos de intercambio.

La arquitectura decide dónde utilizarlos.

Por eso, muchas veces, el primer proyecto correcto no es sustituir el HIS.

Es construir una frontera de interoperabilidad bien diseñada alrededor de lo que ya funciona.