OpenEHR el estándar abierto para historias clinicas electronicas

Este es el primer artículo de la serie sobre estándares en Informática Médica.

El objetivo de esta serie es presentar distintos estándares desde un punto de vista práctico y muy crítico, ya que muchas veces nos llega mucho ruido de quienes promueven sus propios estándares, pero no contamos con una mirada independiente que nos ayude a entender si nos quieren "vender un buzón" o si realmente usando lo que nos dicen podemos solucionar los problemas que plantea la Informática Médica.

¿Buscas capacitación en openEHR? Encuéntrala en CaboLabs

Un posible punto de introducción al tema: http://es.wikipedia.org/wiki/OpenEHR

OpenEHR en pocas palabras:

• Estándar abierto que define un modelo de información y un modelo de conocimiento clínico.
• Propone el enfoque de sistemas informáticos "orientados a la gestión del conocimiento clínico".
• Objetivo: ayudar a crear sistemas "semánticamente abiertos", durables en el tiempo, y económicamente viables.

Explicando las "pocas palabras":

Estándar abierto: es generado, mantenido, probado y validado por una comunidad de usuarios dividida en dos grandes grupos: los expertos clínicos y los expertos en TICs (Tecnologías de la Información y las Comunicaciones). Para formar parte de la comunidad no es necesario pagar, toda la información es libre y para participar en las discusiones solo es necesario registrarse en su lista de correo.

Define un modelo de información clínica:

El modelo de información de OpenEHR es una especificación UML (orientada a objetos), y es la parte del estándar que debe implementarse dentro del software. La principal característica es que es un modelo genérico, es decir, que permite representar toda la información que se genera en la asistencia médica, pero no especifica la semántica de cada concepto clínico particular, solo contiene conceptos clínicos generales, como son: observaciones, evaluaciones, instrucciones y acciones. Luego profundizaremos más en los detalles del modelo de información clínica.

Define un modelo de conocimiento clínico:

El modelo de conocimiento de OpenEHR es básicamente una especificación de unos artefactos llamados "arquetipos". Los arquetipos son simples archivos de texto plano, que cumplen una sintaxis llamada ADL (Archetype Definition Language). El objetivo de los arquetipos es representar conceptos clínicos particulares y residen fuera del software (al contrario del modelo de información que representa conceptos clínicos generales y reside dentro del software). Los conceptos clínicos particulares son representados como un conjunto de restricciones sobre el modelo de información genérico. Luego veremos algún ejemplo.

Orientación a la gestión del conocimiento clínico:

La idea de que los conceptos clínicos particulares residan fuera de la aplicación de software, es en si un cambio de paradigma. Hoy en día, los Sistemas de Información en Salud son fabricados de forma que el conocimiento clínico está definido de forma "dura" en el software. Esto quiere decir, que si cambia el conocimiento clínico que maneja el software, se debe cambiar la aplicación de software (en el sentido que necesita adaptarse a los cambios en el conocimiento clínico). Esto hace que cada cambio sea muy costoso.

Por el contrario, si el conocimiento clínico es definido y gestionado por fuera del software, como la aplicación de software es genérica, los cambios en el conocimiento no repercuten en el software, ahorrando costos innecesarios. Este paradigma de "gestión del conocimiento clínico" no solo tiene ventajas en ahorro de costos, si no que puede tener implicancias más profundas en los proyectos de TICs en salud.

Hoy, para crear un sistema de software en salud, un grupo de analistas informáticos tiene una o varias reuniones con un grupo de médicos que les expresan sus necesidades (requerimientos sobre el software). La experiencia indica que este proceso es en general infructuoso. Por ejemplo, una historia que se repite es: cuando el grupo de analistas está convencido de que ha extraído todos los requerimientos, se comienzan a construir prototipos. Una vez finalizados, éstos les son mostrados a los médicos, los cuales comentan cosas como "esto no es lo que pedimos", "esto no me sirve", "yo no te dije esto", o directamente "esto es una porquería". Entonces se tira todo y se vuelve a empezar. Esto se repite unas cuantas veces, hasta que se logra lo que los médicos quieren. La regla del dedo indica: los informáticos no entienden a los médicos y viceversa. Uno de los problemas surge de que en este proceso, los informáticos deben gestionar el conocimiento clínico extraído de los médicos, tarea para lo que no estamos preparados (no somos expertos en el dominio clínico, los médicos si).

La pregunta clave: ¿porqué no hacer algo que permita que los médicos puedan gestionar el conocimiento clínico directamente sin tener que pasar por los analistas? ¿no nos ahorraríamos muchos dolores de cabeza, tiempo y dinero?. Bueno, esta es la clave de la "orientación a la gestión del conocimiento. Dado que el conocimiento clínico es definido fuera del software, si pudiéramos enseñarles a los médicos a usar una herramienta para generar arquetipos, los médicos podrían definir el contenido de la Historia Clínica Electrónica sin siquiera tener que hablar con un informático. Mientras, con el tiempo ganado, los informáticos podemos crear mejores sistemas de software, más genéricos y más inteligentes, que permitan cargar los arquetipos que definen los médicos y generar el sistema de información en base a ellos.

Esto tiene varias implicancias. Primero, es el médico quien decide que poner o no poner en un arquetipo, por transitiva, está decidiendo que va y que no va en la historia clínica. Por lo tanto, se evitan las quejas de que el sistema no registra lo que el médico necesita, porque está definiendo justamente lo que necesita. Segundo, se le da a los médicos un rol más preponderante en los desarrollos de TICs en salud. Con el enfoque actual, los informáticos hacemos "uso" de los médicos solo cuando los necesitamos, luego ellos pierden visibilidad del proyecto. Tercero, debido a la satisfacción del médico por haber sido él quien creó la historia clínica y por haber participado activamente en el desarrollo, se facilita el cambio cultural que involucra la inserción de las TICs en salud, evitando rechazos y ganando adeptos que pueden contagiar a los demás en usar el sistema. De esta forma deja de ser un proyecto informático y pasa a ser un proyecto médico.

Sistemas semánticamente abiertos

Los arquetipos son definiciones semánticas de conceptos clínicos particulares. Esto quiere decir que cada arquetipo expresa un concepto clínico, junto con su propósito, para qué se debería usar, para que no se debería usar, cual es su estructura interna, qué vínculos con codificaciones y vocabularios controlados tiene, entre otros elementos.

Los arquetipos pueden traducirse, esto quiere decir que puedo definir un arquetipo junto a sus contexto expresado en múltiples idiomas. Un arquetipo puede compartirse, de modo que si defino un arquetipo para el concepto "presión arterial" en español, puedo traducirlo a inglés y enviárselo a una institución sanitaria en Inglaterra, y ellos podrán entender lo que representa ese arquetipo. Incluso, sus sistemas informáticos podrían hacer uso de ese arquetipo, de modo que si les envío información referente a la presión arterial de un paciente desde Uruguay, ellos la podrían validar e interpretar utilizando el arquetipo.

Sistemas durables en el tiempo:

Con el enfoque de "gestión del conocimiento clínico", el conocimiento clínico reside por fuera de la aplicación de software, por lo tanto, a medida que avanza la medicina, el conocimiento puede gestionarse y actualizarse, sin necesidad de modificar la aplicación de software. Por otro lado, las tecnologías cambian, y la aplicación de software podría modificarse sin necesidad de modificar el conocimiento clínico. Esto quiere decir que los procesos de gestión del conocimiento y de gestión del software son independientes. Es más, son ejecutados por roles distintos: expertos en el dominio clínico (médicos, enfermeras, técnicos) y expertos en TICs (ingenieros, analistas, programadores), respectivamente. De esta forma, aunque la tecnología cambie, el conocimiento y la información deben sobrevivir el paso del tiempo, lo importante es mantener estos durante toda la vida del paciente, y aún más tiempo (podríamos hablar de que la información clínica debe durar unos 120 años).

Sistemas económicamente viables:

Debido a que ya no es necesario que los analistas extraigan requerimientos y se creen prototipos que los médicos van a rechazar, simplificamos el proceso de desarrollo, y estamos ahorrando en tiempo y dinero. Gracias al enfoque de "orientación a la gestión del conocimiento", el software no necesita modificarse con cada cambio en el conocimiento clínico (que ahora es gestionado de forma independiente por los expertos en el dominio clínico), y considerando que el mayor costo de los proyectos está en el mantenimiento y adaptación del software, este costo se reduce enormemente.

Dentro del modelo de información genérico:

El modelo de información de OpenEHR es básicamente un árbol, donde la raíz de éste es la estructura de más alto nivel, llamada "composición". La "composición" puede ser vista como un formulario de registro en papel, el cual está formado por partes más pequeñas que se "componen" para crear la hoja de registro.

Esas partes más pequeñas son llamadas "entradas" de la historia clínica. Estas entradas no son campos donde se ingresan datos, si no que son grandes conjuntos de campos donde se ingresan datos, que a su vez tienen alguna relación entre ellos, esa relación está contenido en cada "entrada".

Para no hacer una descripción de todo el modelo de información, vamos a concentrarnos en el modelo de entradas, que me parece fundamental para entender tanto el modelo de información como el modelo de conocimiento. En la figura 1 podemos ver el proceso de resolución de problemas clínicos. En éste vemos que cuando un médico recibe a un paciente, lo primero que hace es observarlo, medirlo, preguntarle. La información que surge de esas observaciones, se debe registrar. Luego el médico realiza evaluaciones, plantea objetivos y planes de cuidado, esto en base a su conocimiento y a fuentes de conocimiento externas. Esta información de las evaluaciones también debe ser registrada. El paso siguiente es dar instrucciones, indicaciones, órdenes. Desde solicitar que se haga un estudio de laboratorio, hasta darle indicaciones al paciente en el alta. Por último, cerramos el ciclo con la ejecución de las instrucciones, lo que vemos aquí como "acciones". Si el paciente no es dado de alta, el ciclo vuelve a ejecutarse. Todo debe quedar registrado.

Figura 1: proceso de resolución de problemas clínicos.

Indirectamente, lo que vemos es que toda la información clínica generada en la atención del paciente puede catalogarse en grandes clases, las cuales son: observaciones, evaluaciones, instrucciones y acciones. En la figura 2 vemos el modelo UML de estas clases. Lo central del diagrama, aunque parezca complejo, es ver que todas las entradas tienen una superclase abstracta "Entry". Luego tenemos dos subclases "Admin Entry" y "Care Entry", entradas administrativas y entradas de cuidado, respectivamente.Por último, dentro de las entradas de cuidado tenemos cuatro subclases "Observation", "Evaluation", "Instruction" y "Action". Lo que estamos viendo aquí es el corazón de la Historia Clínica Electrónica.

Figura 2: modelo UML de entradas OpenEHR

Algunos detalles del modelo de entradas. Podemos ver que una "instrucción" tiene varias "actividades" relacionadas. Esto modela que las tareas a realizar pueden ser complejas e involucrar varias actividades para ser realizadas, las actividades pueden verse como una lista de pasos para realizar la tarea. Por lo tanto, con una "instrucción" se podría modelar por ejemplo una guía clínica o un protocolo clínico.
A su vez, vemos que una "acción" puede tener relacionada los detalles de una instrucción, esto es para indicar que la acción fue realizada porque tal "instrucción" y tal "actividad" así lo indicaban. Por último, la "acción" también tiene asociada una "transición en una máquina de estados", esto sirve por ejemplo, en acciones que no son puntuales, si no que se ejecutan durante un período de tiempo (como dar una medicación durante 2 horas), para expresar que se comenzó a ejecutar la acción, se que finalizó, que se canceló, que se suspendió, etc. Todos esos son estados y están asociados a una máquina de estados con transiciones definidas, por ejemplo: no se puede cancelar la administración de un medicamento si todavía no se ha empezado a administrar.

Previamente comentábamos de que el modelo de información era genérico. ¿Pero donde está lo genérico? Imaginemos que necesitamos representar el concepto clínico "toma de la presión arterial". En el modelo de información no hay ninguna clase particular que represente ese concepto, por el contrario, existe una clase que agrupa todos los conceptos clínicos que sirven para medir cosas sobre el paciente, la "observación". Bien, entonces el concepto "toma de presión arterial" es una "observación", pero necesitamos definir particularidades para esta "observación" específica, eso lo hacemos con los arquetipos.

Ejemplos de conceptos clínicos particulares y con que clases del modelo de información se corresponden.

• Toma de presión arterial: observación
• Frecuencia cardíaca: observación
• Frecuencia respiratoria: observación
• Resultado de un estudio de laboratorio: observación
• Evaluación de vía aérea: evaluación
• Clasificación de gravedad del paciente (triage): evaluación
• Evaluación de disfunción neurológica: evaluación
• Diagnósticos: evaluación
• Orden de estudios de laboratorio: instrucción
• Indicaciones para el paciente: instrucción
• Colocación de vía venosa central: acción
• Administración de sustancias: acción

Uso concreto de OpenEHR: Open EHR-Gen Framework

En un año de trabajo, junto a mi colega Leandro Carrasco, hemos desarrollado una herramienta que implementa el modelo de información de OpenEHR. Esta herramienta toma arquetipos, o sea conceptos clínicos particulares, y genera automáticamente las pantallas de registro para que los médicos ingresen datos. También genera automáticamente las estructuras de información que se deben almacenar en la base de datos, a partir de los datos ingresados por los médicos. Además, valida automáticamente los datos ingresados por los médicos, contra las restricciones definidas en los arquetipos.

En definitiva, es un sistema de información para la salud, que se genera automáticamente a partir de lo que los médicos definan en los arquetipos. Este tipo de herramientas nos permite pensar en otras formas de construir los sistemas de información para el ámbito de la salud, en formas que se adapten a lo que el médico realmente necesita.

Además de que estamos hablando de sistemas dinámicos, que no necesitan cambios antes nuevas necesidades de registro por parte de los médicos. Son ellos quienes definen le registro a partir de los arquetipos. Estamos hablando de enormes ahorros potenciales tanto en tiempo como en dinero.

Lo malo en OpenEHR:

Esta es la sección donde me pongo duro con la crítica. Hasta ahora no he mencionado nada "malo" de este estándar, y hasta parece una excelente solución para muchos de los problemas que nos enfrentamos día a día quienes construimos sistemas de información en salud. La verdad es que OpenEHR agrega un montón de conceptos que realmente nos ayudan, pero nada es gratis.

El proceso

Vimos que el proceso de desarrollo puede simplificarse, en la medida de que los médicos, enfermeras y técnicos (expertos en el dominio clínico) definan sus necesidades mediante arquetipos. Para esto es necesario una capacitación, la cual no todos estarán de acuerdo en hacer. Muchos querrán seguir expresándole sus necesidades a los analistas informáticos. Esto es un problema, no directamente de OpenEHR, pero si de su aplicación práctica.

Por otro lado, se necesita un proceso definido y controlado en cuanto a la creación corrección y actualización de los arquetipos. Si los médicos empiezan a definir sus arquetipos sin control, muchas veces se llegarán a inconsistencias. Por ejemplo, es necesario un comité médico que evalúe la calidad del arquetipo y que proponga mejoras, antes de integrarlo al registro médico. Una cosa que puede pasar es que un médico defina en parte de un arquetipo, un concepto clínico que ya está modelado con un arquetipo, en lugar de reutilizar el arquetipo existente.

Limitaciones de los arquetipos

Los arquetipos son buenos para expresar estructuras de información y restricciones puntuales sobre esa información, pero no es suficiente para expresar restricciones complejas como: si es un hombre entonces no puede estar embarazado. Las restricciones complejas pueden referenciar a varios conceptos clínicos (arquetipo) y no pueden ser definidas dentro de un arquetipo, por lo que se debe buscar una estructura de mayor nivel donde definirlas.

Esto en sí no es un problema de los arquetipos, si no que los arquetipos no fueron diseñados para expresar esas restricciones complejas, que en cambio, si necesitamos en la práctica. Lo bueno es que teniendo los conceptos clínicos formalizados mediante arquetipos, la definición de esas restricciones complejas puede hacerse de forma sencilla, referenciando a esos arquetipos y sus nodos internos.

Actualización de las herramientas

Si bien la comunidad de OpenEHR provee un conjunto de herramientas libres y gratuitas, estas presentan algunos problemas que no parece que puedan ser solucionados a corto plazo. Obviamente, detrás de las herramientas hay personas, que muchas veces utilizan su tiempo libre en corregir y actualizar las mismas, y no reciben remuneración por hacerlo. Por un lado, es difícil exigirle algo a alguien en este esquema. Por otro lado, que estos proyectos queden estáticos, dificulta la introducción de nuevos adeptos al estándar, por que los desanima al momento en que prueban una herramienta y encuentran un problema.

La clave es que al ser herramientas de código abierto, la comunidad debería participar en mejorar y actualizar el código, tal como pasa con otros proyectos de código abierto. Pero esto no está pasando con las herramientas de la comunidad de OpenEHR. Muchos esperamos que otro solucione los problemas y nos sentamos a ver que pasa. Este es un problema más de la comunidad que del estándar en sí.

Estándar no oficial (de facto)

OpenEHR no es respaldado por una organización como ISO o ANSI, organizaciones creadoras de estándares respetadas en el mundo, por lo tanto OpenEHR es visto por los burócratas como un estándar no formal, o simplemente como que no es un estándar. DICOM también es un estándar abierto, pero es soportado por toda la industria en el área de diagnóstico por imágenes, lo cual lo hace el "estándar de facto" en el área de la imagenología digital. Tal vez, con mayor soporte de la industria, OpenEHR pueda ser el "estándar de facto" para crear sistemas de información en salud.


Conclusión

OpenEHR es un muy buen estándar y propone soluciones a problemas reales. Su aplicación puede tener serias dificultades, pero con un retorno de inversión potencial enorme. Requiere si un cambio cultural, tanto en los médicos como en los informáticos, ya que requiere cambiar (mejorar) el proceso de creación de los sistemas de información en salud. Y muchos de los problemas que hoy tiene la difusión y adopción del estándar, son debido a una comunidad que pide más de lo que da, y como en el mundo nada es gratis, es bueno que si tomamos algo del estándar, aportemos algo a la comunidad: creando una herramienta, corrigiendo las que ya existen, difundiendo el estándar entre otros, haciendo cursos, exponiendo en congresos, creando sistemas basados en el estándar, publicando artículos en blogs, etc.


Para ternimar, los invito a participar en el grupo de discusión en español sobre OpenEHR: http://groups.google.com.uy/group/openehr-es