FHIR comparado con openEHR

El siguiente post es una traducción al castellano del magnífico artículo de Thomas Beale "FHIR compared to openEHR". Me parece que deja bastante claras las cosas así que espero que con esta traducción pueda llegar a más gente.

--------------------

Cada vez más personas y organizaciones se hacen la vieja pregunta de cómo se comparan estándares entre ellos, hoy en día en la forma de: ¿Cómo se comparan o se relacionan HL7 FHIR y openEHR?

Siempre es entretenido revisar esta cuestión cada cierto tiempo, especialmente cuando algunos de los que preguntan son lo suficientemente jóvenes y afortunados para no conocer demasiado la historia de los estándares en salud. Para entender la pregunta hace falta revisar unos cuantos conceptos básicos de la informática médica. Este texto trata de ser lo más objetivo posible, pero es obvio que conozco con mucho más detalle openEHR que FHIR.

¿Cómo se soluciona la necesidad de interoperabilidad?

La respuesta traditional, y la base de HL7, EDIFACT, etc. es decir que no podemos controlar lo que hay en los sistemas, por lo que necesitamos imponer estándares en el flujo de datos entre sistemas (esto es, mensajes). Esto ha funcionado de modo satisfactorio por muchos años para cierto tipo de datos bien definidos, particularmente resultados de pruebas de laboratorio y prescripciones. De hecho muchos sistemas todavía bombean millones de HL7v2.3 o v2.5 mientras escribimos esto.

Sin embargo, diría (y creo que la mayoría de la comunidad de openEHR, 13606 y HL7 CIMI están de acuerdo) que:

• En los últimos 20 años, el rango de la semántica y datos que necesitan ser compartidos para permitir una historia de salud electrónica es mucho mayor que el que puede ser acomodado por mensajes que capturan conjuntos de datos específicos, y de hecho el tamaño y la complejidad de esta semántica es tal que es simplemente insostenible tenerlos descritos o bien dentro de productos de comerciales específicos (en forma de formularios en pantalla) o incluso en formatos de mensaje específicos, lo que implicaría tener que volver a expresarlos para cada nuevo formato (interfaces de usuario, captura de datos en dispositivos móviles, varios formatos de documento, etc.) y tecnología (diferentes tipos de bases de datos, Javascript, etc.).
• A diferencia de hace 20 años cuando muchas soluciones no eran más que pantallas sobre tablas en una base de datos, los creadores de sistemas de hoy en día son muy conscientes de la semántica que necesitan en el interior de sus sistemas.
• La gente que entiende la semántica del dominio no son el personal de IT, son profesionales del dominio y expertos en informática médica con un conocimiento profundo del dominio (aquí otro artículo tratando este punto).

Mi punto de vista es que el único modo escalable para crear especificaciones con semántica es que éstos sean artefactos externos tanto para los productos comerciales como para formatos específicos de comunicación. Esto conlleva una aproximación basada en modelos comunes, con los modelos existiendo en su propio formalismo, herramientas y comunidades. Ejemplos de estos ‘modelos’ incluyen terminologías como CIE (ICD), SNOMED, CIF (ICF), etc.; arquetipos y plantillas de openEHR y de otros grupos como HL7 CIMI, guías clínicas, diccionarios de medicamentos y así sucesivamente. Todos estos modelos diferentes (incluyendo los de openEHR) tienen dos características claves:

• Son creados directamente por personas que entienden la semántica del dominio.
• Pueden ser transformados por computadoras en cualquier formato razonable, incluyendo formatos de mensajes.
   

Este artículo sobre escalabilidad semántica proporciona algunas figuras sobre la necesidad de esta aproximación a un modelo común de base.

Teoría de mensaje frente a teoría de sistema

La aproximación anterior puede ser llamada la teoría de sistema de la interoperabilidad: La semántica es formalizada por el dominio y convertida automáticamente a formatos concretos (como por ejemplo XSD, formatos basados en JSON, etc.) usables por sistemas y aplicaciones, incluyendo mensajería u otras serializaciones.

En la teoría de mensaje de la interoperabilidad, el contenido del mensaje (no solamente estructuras genéricas o protocolos de comunicación) se estandariza y se convierte en un/el requisito de conformidad para los sistemas, o cuanto menos para alguno de sus canales de comunicación.

Esto está potencialmente bien desde el punto de vista de al menos algunos de los consumidores de datos de esos sistemas, pero para sistemas que quieren exportar su semántica nativa o basada en modelos, se convierte en casi un escollo. Esto es porque para comunicarse en un canal de mensajería preestandarizado, se tienen que ingeniar transformaciones entre sus datos y las estructuras requeridas por los mensajes. Estos pueden ser bastante diferentes y el mapeo requerido puede no ser trivial - y siempre que existe un mapeo hay riesgos de pérdida de rendimiento, corrección y seguridad del paciente. Si el conjunto de datos del mensaje es pequeño y simple, habrá pocos problemas, pero si ampliamos la casuística para permitir ‘comunicar cualquier cosa’, entonces podemos estar ante un grave problema.

Sin embargo, seguimos necesitando ser capaces de serializar datos y enviarlos a distintos lugares. La teoría de sistema aborda estos problemas definiendo primero los modelos – para nosotros, plantillas de openEHR, que incluyen enlace terminológico – y para generar automáticamente definiciones de mensajes de ellas. Hoy en día esta es una operación trivial, y de hecho lo ha sido desde los tiempos del RPCgen. Consecuentemente, los ecosistemas basados en modelos no necesitan mensajes, solamente necesitan una tecnología genérica de mensajería. Cabe destacar que en esta aproximación, no hay un único formato posible: puede ser cualquier tipo de XML genérico, JSON, binario o incluso formatos de documento como PDF, openDoc, etc.

Por tanto en estas dos aproximaciones teóricas a la interoperabilidad, los modelos están en dos lugares diferentes. En la aproximación de ‘sistema’, que es la que usa openEHR, los modelos están fuera de los productos y formatos concretos de comunicación. Por otro lado, en la aproximación de mensaje están incluídos en un formato de comunicación particular.

Hacerlo basado en sistemas es más difícil técnicamente, pero mucho más escalable y a prueba de futuro. Hacerlo basado en mensajes produce resultados más rápidos, pero se encontrarán problemas cuando el mensaje necesita cambiarse o el tamaño del espacio de contenidos es crece hasta ser demasiado grande.

Más sobre las limitaciones de la aproximación basada en mensajes en este artículo reciente.

El mundo ideal – modelos universales

Una aproximación ideal al mundo de la salud digital sería desarrollar un conjunto universal de modelos clínicos (como antes, ‘modelos’ incluye terminología, subsets, arquetipos, plantillas, guías, etc.) y herramientas que pueden convertirlos en artefactos usables para la creación de componentes del sistema, bases de datos, mensajes, etc. Este mundo ideal fue claramente descrito por el Dr Stan Huff en la creación de CIMI en 2011. Ha sido nuestro ideal desde finales de los 90 y desde siempre de Stan en Intermountain Healthcare. (desde entonces, CIMI ha pasado a convertirse en un comité técnico de HL7, pero creo que todavía persigue los mismos objetivos).

En una realidad alternativa, la aproximación a ‘hacer mensajes’ debería de haber sido ‘hacer modelos’ y entonces generar cualquier tipo de mensaje u otro formato de serialización que se ajuste a circunstancias específicas.

Sin embargo, politiqueos en los estándares internacionales, diferentes necesidades, restricciones temporales y muchas otras presiones lo han impedido, incluso siendo técnicamente posible y estando ya implementado (aunque no de forma universal).

Añadiré que la forma ideal de este tipo de trabajo no es vía diseño por comité (design-by-committee) tal y como se hace en las organizaciones de desarrollos de estándares (SDO) tradicionales, sino vía ingeniería, desarrollada en un estilo de proyecto ampliamente open source (o un conjunto de dichos proyectos en cooperación). Esta es la aproximación que tomamos en openEHR.

El mundo real

En el mundo real en el que vivimos, las cosas son más complicadas. Por un lado la gente intenta resolver diferentes problemas. Uno de los problemas – sin dudas estadísticamente todavía el más prevalente – es extraer datos de sistemas opacos que no quieren darlos (generalmente por razones contractuales o de IP) y contienen interfaces propietarias muy limitadas o incluso simples tablas relacionales en bruto. Otro caso distinto es el de construir una nueva generación de sistemas y componentes que encarnan una comprensión moderna de la semántica sanitaria, esto es, información, procesos, reglas de negocio, CDS, etc. Estos retos corresponden a diferentes aproximaciones.

En el mundo de los estándares sanitarios, HL7 aparcó el esfuerzo invertido en HL7 v3 tras 15 años (demasiado complejo, poco adaptado a las nuevas tecnologías, HL7v2 funcionaba bastante bien) y empezó a trabajar en FHIR alrededor de 2012.

Nosotros por nuestra parte en openEHR continuamos con la aproximación de ‘sistemas’ descrita anteriormente. La norma relacionada ISO13606 y más recientemente la comunidad CIMI han trabajado usando la misma base, como lo han hecho, tácitamente, IHTSDO, editores de bases de datos de medicamentos, algunos emisores de guías clínicas, etc. (i.e., dichas organizaciones producen artefactos cuyo contenido es independiente de los productos particulares de cualquier vendedor y de formatos de comunicación concretos).

¿Cómo se compara FHIR a openEHR?

El principal objetivo de FHIR es solucionar la comunicación de sistema-a-sistema (B2B) y sistema-a-aplicación (B2C), sin hacer ninguna asunción sobre los sistemas. La parte B2B es básicamente la aproximación de la mensajería para el siglo 21; La parte de B2C supone la creación de unas APIs adecuadas para los programas y aborda una necesidad primordial – hacer sencillo construir aplicaciones modernas sanitarias. El reto está en que lo segundo claramente hace asunciones sobre la lógica de negocio y el contenido que incluyen los sistemas subyacentes. 

La intención principal de openEHR es resolver el reto de los de salud de los pacientes – un historial de paciente longevo, versionado, distribuido y computable – y hacerlo de un modo robusto a los cambios futuros, exponiendo la semántica usando una arquitectura de plataforma. Vemos la interoperabilidad como una consecuencia técnica natural de una plataforma basada en una semántica formalizada. Por supuesto, openEHR en si misma solo propone algunos elementos de dicha plataforma – necesita ser usado en conjunción con terminologías, ontologías, bases de datos de medicamentos, interfaces de servicio y demás.

Representación Técnica

FHIR se define a partir de una biblioteca de ‘recursos’ (micro-formatos de datos de la red) y una aproximación técnica al desarrollo de ‘perfiles’ y ‘extensiones’ para soportar la localización (estos términos están todos definidos en el sitio web de FHIR). En otras palabras, hay un cierto nivel de ‘modelado clínico’, pero está dentro del formalismo principal XML de FHIR. Los recursos están diseñados para ser instanciados y accedidos mediante APIs REST.

En openEHR usamos un Modelo de Referencia estándar, y varias capas de modelos sobre él, incluyendo arquetipos, plantillas y subconjuntos terminológicos. El Modelo de Referencia de openEHR es estándar para todo el mundo, y todo los datos basados en openEHR, no importa dónde estén o de dónde vengan lo siguen al pie de la letra. En openEHR y otras comunidades basadas en ADL, los modelos están al margen de la mensajería o de los micro-formatos web y en su lugar son transformados de forma automática a cualquiera de esas formas cuando sea necesario. Esto claramente significa más herramientas: por ejemplo, herramientas para generar XML, JSON, el protocolo de buffer de Google, o cualquier otro, pero la realidad es que estos formatos concretos cambian continuamente – en los 5 años que lleva existiendo FHIR la preferencia principal ya ha evolucionado de XML a JSON.

Los arquetipos openEHR se representan en Archetype Definition Language (ADL) / Archetype Object Model (AOM, un estándar ISO). ADL is también la representación de los modelos de HL7 CIMI. Soporta la composición, especialización y redefinición, permitiendo adaptar los modelos generales en otros más específicos y localizados.

También hay diferencias en el estilo de los modelos que se construyen. En openEHR y tecnologías relacionadas, generalmente son construidos por comunidades de expertos en el dominio clínico, basado en requisitos (‘como nos gustaría que fuera’). En FHIR, la estrategia es producir cada recurso FHIR como un superset de los datos que se pueden encontrar en sistemas legacy, y así satisfacer las necesidades de los desarrolladores. Esto lleva a diferentes resultados – Los modelos FHIR son usables directamente por los desarrolladores, pero difícilmente serán reusables en diferentes tecnologías, como por ejemplo generar formularios en una interfaz de usuario. OpenEHR usa herramientas para generar XSD, JSON, Xforms y otros formatos que los desarrolladores puedan querer. 

Además, en openEHR tenemos una base teórica para la HCE bastante extensa, que nutre al Modelo de Referencia sobre los que se construyen. No soy consciente de que exista algo equivalente en FHIR. Creo que esto importará en gran manera en la interoperabilidad de procesos clínicos entre infraestructuras de e-Salud..

Hay más detalles para los fans de FHIR sobre openEHR en otro post reciente, base técnica de openEHR para usuarios de  HL7 y FHIR.

Alcance de la plataforma

Si estamos de acuerdo en la idea general que una plataforma técnica consiste en modelos de información, modelos semánticos, APIs y consultas, podemos establecer comparativas adicionales.

openEHR tiene una cobertura extensiva de la información de paciente (su Modelo de Referencia define numerosos tipos de estructuras), una cobertura significativa del área de modelos semánticos (creemos que quizás sobre el 25% de la medicina general), y una cobertura limitada en el área de APIs de aplicación (ejemplo), aunque con algunas buenas herramientas, aún sin estandarizar. Esta es una de las principales áreas en las que estamos trabajando durante 2017, junto con una nueva especificación de procesos (acaba de proponerse para comentarios una nueva especificación para la planificación de tareas).

La cobertura de APIs en FHIR es sustancialmente mayor, siendo como es una de sus especialidades, y de hecho el proyecto FHIR podría seguramente afirmar haber hecho un trabajo innovador y pionero en cómo construir APIs para datos complejos e interacciones.

Sin embargo, su cobertura de la semántica del dominio y los modelos de información es más difícil de determinar – depende sobre todo de lo que uno piense que son los recursos FHIR – ¿algo como los arquetipos?¿un tipo de Modelo de Referencia?¿quizás algo intermedio?. Mi lectura particular es que son como una biblioteca de plantillas de openEHR, que disponen de reuso y especialización para la extensión, más un conjunto de recursos genéricos para identificadores, tipos de datos, estructuras genéricas, recursos demográficos y otros tipos para infraestructura. Una diferencia entre los dos es que recursos más complejos, como por ejemplo el recurso Risk Assessment, es su propia estructura de datos, mientras en openEHR  Health risk assessment es un arquetipo de la clase Evaluación del Modelo de Referencia. Añadir un nuevo contenido clínico en openEHR acaba siendo simplemente añadir un nuevo arquetipo (i.e. no es necesario cambiar el Modelo de Referencia); en FHIR necesita nuevos recursos, o si no crear un perfil sobre un recurso existente. Esto implica nuevo software para cada nuevo recurso.

Un área que creo que openEHR tiene bien cubierta son las consultas semánticas, para lo cual usa un lenguaje portátil de query, AQL. En mi conocimiento, FHIR no tiene nada equivalente a esto. Las queries portátiles son potentes porque son completamente independientes de los esquemas del almacenamiento físico y su tecnología – solo dependen de los arquetipos.

El diferente grado de cobertura de elementos esenciales de la plataforma hace más interesante uno u otro ecosistema para diferentes tipos de desarrolladores, pero mucho de lo que usar y cómo se basa al fin y al cabo en el problema que se intenta solucionar.

Hype contra Realidad

Probablemente valga la pena mencionar brevemente el problema del ‘hype’ (altas expectativas) aunque solo sea para alertar a los desprevenidos. FHIR ha sido altamente ‘hypeado’, incluso algunos dirían ‘sobrehypeado’ como en este artículo. Esto no significa que sea culpa del proyecto FHIR, sino más bien debido a la combinación de algo común en los humanos normales como la psicología de la bala de plata (la creencia irracional que una única solución arreglará todos los problemas) y un cierto grado de desespero por encontrar un reemplazo a HL7v3 entre las agencias como la ONC. La mayoría el ‘hype’ ha sido creado por gente con alto grado de optimismo pero un conocimiento ingenuo de las restricciones y dificultades con las que las tecnologías de eSalud tienen que lidiar.

Mi recomendación aquí es simplemente el considerar cuidadosamente los requisitos e intentar entender los paradigmas que se quieren utilizar para resolverlos – por ejemplo, si quieres usar una aproximación tal como una arquitectura de plataforma que usa semántica avanzada, una solución multiusos comercial, o alguna otra aproximación. Entonces aprende cuál es el ámbito de aplicación de las distintas tecnologías disponibles – ¿qué es lo que solucionan?¿qué no solucionan? Cualquier persona racional sabe que ninguna tecnología soluciona por sí misma todos los problemas, y esto es cierto tanto para HL7 FHIR como para openEHR.

¿Pueden openEHR y FHIR trabajar conjuntamente?

Hay respuestas triviales y no triviales a esta pregunta. Si el requisito es hacer los datos de grandes sistemas legacy comerciales disponibles a aplicaciones y permitir ciertos tipos de comunicaciones B2B, FHIR es atractivo porque ese es exactamente el problema para el que fue diseñado, y puede que sea todo lo que necesitas.

Sin embargo, si el fin es construir una plataforma abierta y longeva  de salud, donde la organización proveedora quiere control sobre los datos, interfaces sobre los componentes principales y control sobre las elecciones compras y tiempos, será necesario mucho más. Bajo esta visión, la Historia Clínica Electrónica no es un producto que compras, es una capacidad que creas para gestionar los datos que posees.

Este es el escenario para el que openEHR fue diseñado – ser parte de una infrastuctura de plataforma abierta, tal y como se describe en el White Paper de openEHR. Normalmente este tipo de entorno incluye grandes sistemas legacy y EMRs (esto depende mucho del país), por tanto uno de las tareas principales que una solución openEHR tiene que realizar es la de implementar ‘puentes’ de datos e importación de mensajes, de modo que se pueda convertir las fuentes de datos necesarias en datos semánticos de gran calidad basados en modelos.

El siguiente desafío es cómo implementar unas APIs on la plataforma de modo que se permita la construcción de aplicaciones. Históricamente, la visión de las APIs en openEHR ha sido mas cercana a la de IHE y los servicios de la OMG, como por ejemplo IHE PIX, PDQ, ATNA y OMG EIS y RLUS. De un tiempo a esta parte hemos estado trabajando en una interfaz ligera REST, tanto a nivel de especificación como con herramientas como EhrScape. Esto proporciona unas APIs nativas e interfaces de mensajes en un entorno openEHR.

Si una organización quiere implementar FHIR sobre un entorno openEHR como un añadido a sus interfaces nativas será necesario un esfuerzo. Hay dos aproximaciones. La primera es la ingenua: esencialmente la misma como si se hiciera un canal de exportación del sistema en  HL7v2 o CDA, que es decir que cada recurso FHIR + API requerida, construir una interfaz a medida y un proceso base que use AQL para sacar datos de un sistema openEHR. Los costes de este tipo de aproximación son abiertos, pues cada nueva API requiere más trabajo, pero es probable que sea lo suficientemente sostenible para muchos usuarios.

Una aproximación más potente y escalable sería permitir nuevas ‘particiones de recursos’ en la plataforma de comunicación genérica de FHIR, por ejemplo para acomodar las definiciones de contenido de openEHR, ISO 13606, CDISC o cualquier otro modelo abierto. Esta aproximación se describe en detalle en el post ’Making FHIR work for Everybody’ de hace unos meses (que todo sea dicho, se encontró con una resistencia dentro de HL7 bastante fuerte). La gran ventaja de esta aproximación es que permite a los programadores hablar a openEHR (o ISO 13606, o CDISC BRIDG…) en estilo de FHIR, y usar la aproximación al desarrollo de aplicaciones de FHIR, pero con la interfaz de contenido siendo derivada automaticamente de los modelos relevantes de la fuente en lugar de los recursos nativos de FHIR – lo mejor de ambos mundos.

Mi creencia personal es que esto representa la mejor esperanza de traer juntos estos dos mundos, pero falta ver si HL7 puede convencerse del potencial de esta idea.

Espero que este artículo proporcione un contexto adecuado para aquellos que intentan entender openEHR y FHIR, y especialmente sobre cómo se pueden usar conjuntamente.

Epílogo

Me he dado cuenta de un  pensamiento implícito relevante en mi discusión debería haber de haber sido incluido al final, y es como sigue: Creo que el principal reto para los que trabajamos en eSalud (y de hecho en cualquier cualquier dominio que tenga una complejidad semántica inherente) continua siendo el desarrollo de una biblioteca universal de modelos de esa semántica. De nuevo, la palabra 'modelos' se refiere a su definición más amplia – cualquier expresión formalizada de la semántica del dominio, pero expresada de modo diferente según los productos o tecnologías de implementación con durabilidad limitada.

Algunos dirán que es imposible, porque la gente no se pondrá nunca de acuerdo. Pero existen diferentes niveles de acuerdos. Considera que los 'modelos' son en realidad formalizaciones de teorías sobre algún fenómeno (como describe este artículo). Las teorías se gestan en las mentes de unos pocos, son discutidas, desarrolladas, probadas, reformuladas y así sucesivamente, hasta que finalmente mueren o sobreviven, pero en las mentes de muchos. Los modelos no son mas que expresiones de teorías de comprensión, y el nivel de acuerdo refleja como de ampliamente esa comprensión es compartida.

Hacia donde las tecnologías en sanidad deben de evolucionar es a una completa separación de los modelos de significado (semántica) en salud y las tecnología usadas para implementar soluciones en un momento dado