Fundamentos de openEHR

Entender openEHR no es un ejercicio académico — es lo que marca la diferencia entre un modelo de datos que sobrevive a tu primer cambio en producción y uno que requiere un sprint de desarrollo cada vez que se agrega un campo.

Atomik está construido sobre openEHR. Cuanto más entiendas el estándar, más le sacarás a la plataforma. Esta guía cubre los conceptos que encontrarás a diario: los modelos de información, la separación de los datos del código de la aplicación, y el sistema de arquetipos/plantillas que hace posible el almacenamiento clínico sin esquema fijo.

openEHR es un estándar abierto con más de 20 años de especificaciones, una comunidad global y adopción creciente — particularmente en sistemas nacionales de salud de Europa, Australia y América Latina. Captura requisitos, patrones y buenas prácticas para Sistemas de Información en Salud que la mayoría de las implementaciones a medida descubren de la forma difícil, después de años en producción.

openEHR traza una distinción clara entre la información relacionada con el EHR y la información demográfica, y ofrece especificaciones para ambas. El Modelo de Información del EHR cubre estas entidades:

• EHR representa la historia clínica completa y única de un paciente
• CONTRIBUTION representa un conjunto de cambios para un EHR
• COMPOSITION representa un registro o documento que pertenece a un EHR; las COMPOSITIONs se agregan a un EHR contenidas en una CONTRIBUTION
• FOLDER representa una estructura organizacional que puede contener documentos y otras carpetas
• VERSION representa una versión de un registro o documento, en general es una versión de una COMPOSITION o FOLDER
• ENTRY representa una declaración clínica individual, e incluye estructuras de datos y campos de datos
• DATA VALUE representa el tipo de un campo o punto de dato específico (texto, código, fecha, booleano, multimedia, etc.)

El Modelo Demográfico de openEHR hace lo mismo con estas entidades:

• PERSON representa una parte de tipo persona
• ORGANIZATION representa una parte de tipo organización, como un hospital
• GROUP representa un grupo de partes, por ejemplo un equipo quirúrgico
• ROLE representa un rol que puede desempeñar una parte, por ejemplo una persona podría ser médico o podría ser paciente, dos roles distintos
• PARTY RELATIONSHIP representa cualquier tipo de relación entre dos partes, por ejemplo una relación familiar entre dos personas
• PARTY IDENTITY representa información de identidad de una parte
• CONTACT representa información de contacto de una parte, incluyendo la dirección

openEHR recomienda repositorios separados para los datos de EHR y demográficos. Atomik soporta ambos patrones: ejecutarlos juntos en una sola instancia (configuración más simple, mantenimiento compartido, prototipado más rápido) o separarlos en instancias distintas para ajustarse a la arquitectura estricta de openEHR. De cualquier forma, ambas usan la misma base de código.

Separación de los datos y la aplicación

Este es el concepto más importante en openEHR — y el que tiene mayor impacto en tu velocidad de entrega.

Esto es posible gracias al enfoque de doble modelado de openEHR: un Modelo de Información de Referencia estable que el software genérico puede implementar una sola vez, y una capa separada de Arquetipos y Plantillas que los expertos de dominio gestionan sin tocar el software. El proceso de modelado estandarizado también implica que las definiciones de información se gobiernan formalmente a largo plazo — sin inconsistencias silenciosas que se acumulen con los años.

El Modelo de Arquetipos de openEHR describe los artefactos usados para definir, gestionar y compartir definiciones de información de salud. Estas definiciones incluyen: estructura, restricciones y terminología. Estas definiciones te permiten expresar cualquier tipo de información que quieras almacenar y gestionar en un sistema de información en salud, y todas las definiciones usan los mismos elementos estandarizados (Arquetipos y Plantillas) para crear estructuras de datos complejas. Esta flexibilidad viene del Modelo de Información de Referencia subyacente, porque todos los elementos usados en estas definiciones provienen de él.

El Modelo de Información de Referencia está compuesto principalmente por las especificaciones mencionadas arriba (EHR y Demographic), y define estructuras de datos genéricas que pueden configurarse de distintas formas para expresar cualquier tipo de estructura de datos. Esa "configuración" del Modelo de Información la realizan los Arquetipos y Plantillas.

Arquetipos y Plantillas

Estos son los modelos openEHR usados para describir estructuras de información. La recomendación de openEHR es que estos modelos sean creados por Expertos de Dominio, sí, son clínicos, no personas de TI. Esta recomendación tiene algunas consecuencias positivas. Primero, la información clínica es definida y gestionada por profesionales que realmente saben de qué están hablando. Segundo, nosotros, la gente de TI, podemos confiar en estos Expertos de Dominio para las definiciones de información, mientras nos enfocamos en resolver problemas de ingeniería puros (lidiar con conocimiento clínico no es uno de ellos).

Los Expertos de Dominio usarán herramientas de modelado para crear, gestionar y compartir Arquetipos y Plantillas. Hay muchas herramientas de modelado disponibles y la curva de aprendizaje no es tan pronunciada. Ofrecemos un curso de formación específico para aprender Modelado de Información Clínica con openEHR, que incluye la metodología y las herramientas necesarias para crear tus propios modelos.

Cuando los Expertos de Dominio crean estos modelos de información, primero empiezan creando todos los Arquetipos necesarios que definen las estructuras básicas que serán partes reutilizables en distintos documentos, como Presión Arterial, Pulso, Temperatura Corporal, Orden de Medicación, Procedimiento, etc. Cada uno de esos conceptos tendrá sus estructuras de datos asociadas en un Arquetipo cada uno.

Otra opción, en lugar de crear todos los Arquetipos desde cero, es tomar los que están disponibles en el Clinical Knowledge Manager (CKM) internacional. Una característica interesante de los Arquetipos es que, dado que incluyen terminología sobre el concepto que el Arquetipo representa, puedes traducir un Arquetipo a distintos idiomas, para que tus definiciones de documentos puedan estar en varios idiomas. Muchos Arquetipos en el CKM ya están traducidos, y si necesitas usar un Arquetipo de allí que no está traducido a un idioma en particular, puedes contribuir con la traducción. Así funciona la Comunidad de Modelado Clínico: mediante contribuciones.

Finalmente, cuando tienes todos los Arquetipos que necesita cierto documento, esos Arquetipos se combinan en una Plantilla. Una Plantilla de openEHR es básicamente un gran Arquetipo que representa un documento clínico. Nota que aquí usamos el término "clínico" de forma laxa, ya que en una Plantilla de openEHR puedes representar registros que contienen muchos conceptos (Arquetipos) pero que podrían no ser para un contexto estrictamente "clínico"; por ejemplo, una Plantilla podría definir las estructuras de datos necesarias para registrar Seguimiento de Ejercicio, Consentimientos de Procedimiento, datos administrativos básicos, etc.

Entonces el resultado del proceso de Modelado Clínico ejecutado por los Expertos de Dominio es una Plantilla en una forma que puede ser consumida por sistemas de software. Esa forma final se llama Plantilla Operacional (OPT). El OPT es simplemente un archivo XML que contiene todas las definiciones de estructura, restricciones de datos y terminología de todos los Arquetipos referenciados por la Plantilla. Los OPTs son en realidad lo que los Modeladores Clínicos entregarán al equipo de TI para implementar la interfaz de usuario, la lógica de aplicación y la persistencia correspondientes que permitirán a un sistema de software almacenar y recuperar datos definidos por el OPT.

Dado que Atomik es un sistema basado en openEHR, sigue ese proceso: necesitas subir los OPTs usados por tus aplicaciones para que sepa cómo lucirán los datos, y luego Atomik sabrá cómo procesarlos y almacenarlos cuando tu aplicación envíe datos a Atomik.

Modelos a prueba de futuro

Una última cosa que hay que saber sobre openEHR es que los modelos de conocimiento (Arquetipos y Plantillas) y los datos almacenados con base en esos modelos son todos versionables. Supongamos que tienes un Arquetipo, por ejemplo Presión Arterial, que será la primera versión del Arquetipo. Luego en el futuro se necesita algún requisito adicional sobre Presión Arterial, entonces modificas el Arquetipo y publicas la segunda versión del Arquetipo. De ahí en adelante, todos los datos de Presión Arterial seguirán el Arquetipo v2, mientras que los datos actuales siguen la v1. Eso es normal en los sistemas de salud, pero la mayoría de los sistemas no tienen este requisito formalmente definido. Entonces, cuando se consultan y recuperan datos de Presión Arterial, se devolverán los datos registrados tanto para la v1 como para la v2 del Arquetipo.

Además, los datos en sí son versionables. Eso significa que, cuando se necesita una modificación, enmienda o incluso eliminación de datos existentes, en openEHR los datos actuales no se modifican, sino que se crea una nueva versión de los datos y se vincula con la versión anterior. Esto mantiene un registro de auditoría coherente de todos los cambios realizados a los datos, creando un historial que puede navegarse, y cada elemento del historial de datos tiene un registro de auditoría que incluye el tipo de cambio, el momento, la razón y el responsable del cambio, respondiendo todas las preguntas básicas de un sistema de registro de auditoría.

Formación en openEHR

En CaboLabs ofrecemos formación formal en distintos aspectos de openEHR, desde entender las especificaciones hasta la implementación, incluyendo modelado clínico para expertos de dominio. Puedes encontrar más en nuestro sitio web de educación.