El Blog de Nessy¿Qué es la interoperabilidad?
La interoperabilidad es la capacidad de 2 o más sistemas de intercambiar y utilizar información entre ellos.
Una definición más formal:
Interoperabilidad es la comunicación entre diferentes tecnologías y diferentes aplicaciones de software, que permite el intercambio de datos en forma precisa, efectiva y consistente, y que permite el uso de la información intercambiada.
Notas:
- Desde el punto de vista más técnico, un desarrollador web es experto en interoperabilidad, ya que día a día usa o crea estos “puentes” de comunicación entre aplicaciones. Esto no significa que sea experto de interoperabilidad en salud, donde hay estándares y protocolos específicos que hay que aprender.
- Tenemos un post que habla sobre interoperabilidad específicamente en salud.
¿Cuáles son los requerimientos para que un sistema sea interoperable?
- Poder intercambiar información (interoperabilidad sintáctica)
- Utilizar la información intercambiada (interoperabilidad semántica)
- Definir reglas de negocio que permitan comprender qué información y qué gatillará dicho intercambio (interoperabilidad de negocio). Es importante saber los procesos que generan los datos que estamos utilizando.
¿Qué es la “Interoperabilidad Absoluta”?
La interoperabilidad es o no es, no hay grados de interoperabilidad.
¿Por qué son importantes los estándares en la interoperabilidad?
Los equipos de informática tienen que crear las “interfaces” de comunicación entre los distintos sistemas. Pueden ponerse de acuerdo y crear “interfaces” adhoc, pero con el tiempo es difícil y costoso de mantener.
La cantidad de interfaces requeridas aumenta en forma cuadrática dependiendo del número de sistemas: nº interfaces = n(n-1)/2, donde (n = cantidad de sistemas).
Como en salud tenemos muchas instituciones y organizaciones que deben interoperar, es importante hacer que la forma en que se comunican sea estándar.
El beneficio de esto es que evitamos crear interfaces adhoc que hay que mantener con el tiempo. Tener una interfaz única hace que la cantidad de interfaces requeridas sea lineal con respecto a la cantidad de sistemas involucrados.
Notas:
- Todo parte de la base de que en salud es MUY importante que los sistemas interoperen. Por eso nace todo este movimiento de interoperabilidad y de estándares que van más allá de simplemente “construir un API” bien documentada y fácil de usar.
- Tenemos un post sobre estándares de interoperabilidad.
¿Cómo le damos significado a la información que intercambiamos?
La interoperabilidad sintáctica nos permite intercambiar información. Pero para poder utilizar esta información, los datos intercambiados deben tener un significado.
Por ejemplo, la idea es que los datos intercambiados signifiquen lo mismo para China que para USA.
En el área de salud, esto no es tan sencillo ya que un mismo concepto médico puede describirse de distintas formas, más allá del idioma.
Así que para lograr darle significado a un dato, le damos una codificación (para lo cual hay estándares de codificación 😉).
¿Cómo nacen los estándares?
- Adhoc: un grupo de personas u organizaciones interesadas se ponen de acuerdo. Ejemplo: DICOM, que es un estándar de transmisión de imágenes médicas.
- De facto: cuando una empresa domina el mercado y lo crea. Ejemplo: Microsoft.
- De juri o mandato: una agencia de gobierno crea un estándar y legisla su uso.
- Consenso: un grupo de voluntarios representantes de las partes interesadas en el estándar desarrollan el mismo en forma abierta. Ejemplo: HL7.
¿Qué es HL7?
HL7 es una organización sin fines de lucro que crea estándares para facilitar el intercambio electrónico de información clínica.
Han creado distintos estándares, como por ejemplo:
- HL7 v2: estándar de mensajería para el intercambio electrónico de datos de salud.
- HL7 v3: estándar de mensajería para el intercambio electrónico de datos de salud basada en el RIM.
- HL7 CDA: estándar de arquitectura de documentos clínicos electrónicos.
¿Cómo nace FHIR?
Un poco de contexto:
- El estándar más utilizado en el mundo es HL7 v2, el problema es que no es fácil de leer para un clínico.
- CDA es muy robusto pero solo es para intercambiar documentación clínica.
- Luego surgió HL7 v3, el cual no fue muy popular debido a la complejidad de adoptar.
El problema es que las tecnologías evolucionaron más rápido que los estándares. Nos movimos del mundo offline al mundo online, de desktop a mobile, de software a aplicaciones, de servidores al mundo cloud, de sistemas cerrados a APIs abiertas…
Mientras tanto, en el mundo de la tecnología nació REST, que es un patrón arquitectónico donde todo puede ser modelado como un recurso y donde todo puede hacerse en base a 4 simples operaciones: crear, leer, actualizar y destruir (operaciones CRUD).
REST marca los cimientos de FHIR (Fast Healthcare Interoperability Resources), permitiendo definir el mundo de la salud en recursos que puedan ser entendidos por clínicos y por informáticos.
Algunos beneficios:
- Más fácil de hacer aplicaciones.
- Curva de aprendizaje menor.
- Facilita la implementación.
Además soporta distintos tipos de arquitecturas:
- RESTful API
- Mensajes
- Documentos
- Servicios / SOA
- Bases de datos / Persistencia
Y está siendo muy adoptado en la industria.
¿Dónde podemos encontrar ejemplos y proyectos que usan HL7 FHIR?
En la página simplifier podemos encontrar la documentación de proyectos a nivel global.
En la página existen 80 proyectos en Chile.
Preguntas y respuestas
En la sesión presencial surgieron las siguientes preguntas:
¿CDA o FHIR?
CDA es solo para intercambiar documentación clínica, y con FHIR también es posible hacerlo.
No hay una respuesta correcta, pero Sergio (profesor) recomienda FHIR porque va de la mano con el avance tecnológico.
¿Vale la pena aprender HL7 v2?
Grandes compañías como Google, Microsoft, Apple y Oracle comenzaron a apostar con FHIR. Esto marca las pautas a futuro, y hará que el mercado se mueva a FHIR.
HL7 v2 hoy en día es más legado. V2 está probado, es rápido y es liviano. Incluso hay algunas tecnologías (como en laboratorios) donde todo lo exportan a HL7v2. Así que al final del día siempre va a depender del contexto.
Sin embargo, Sergio (profesor) recomienda FHIR por las razones antes mencionadas (los grandes están invirtiendo en esto, y además está en sintonía con los avances en tecnología).
¿Existe alguna normativa de parte del MINSAL?
Todavía no hay políticas de país ni de estado que fomenten la interoperabilidad.
¿Por qué usar un estándar baja la cantidad de conexiones?
No baja la cantidad de conexiones. Baja la cantidad de interfaces diferentes. Siempre existirán conexiones, un estándar tú conectas el cómo leen tu data y tu cómo la compartes (cómo escribir y cómo leer).
¿Es obligatorio usar un server FHIR o solo el estándar?
FHIR es un estándar con múltiples implementaciones. Existe un servidor llamado HAPI FHIR, el cual puedes utilizar e instalar.
Así que existen muchas implementaciones en distintos lenguajes (en C, Java, etc). El estándar da la estructura, lo importante es cumplir con el estándar.
Es posible hacerlo de cero, pero existen herramientas creadas que podemos usar (y que son de software libre).
¿Quién está usando FHIR?
Algunas menciones: Araucanía sur, Iquique, El ministerio de salud, UC Christus, el metropolitano sur oriente y La clínica Alemana.
¿Existen casos de éxito de instituciones países que usen FHIR?
Algunos ejemplos:
- En Perú, Roche está migrando mucho a guías de implementación de FHIR.
- USA y Canada muy de la mano con la tecnología.
- Colombia tiene algunos ejemplos con FHIR (algunas clínicas).
- Argentina.