openEHR es un conjunto de especificaciones para los componentes de plataformas de información clínica, que incluye múltiples características deseables:

• Neutral del Proveedor
• Independiente de la Tecnología
• Mantenible
• Interoperable
• Datos Estandarizados
• Especificaciones Computables de Datos
• Datos Versionables
• Impulsado por Expertos del Dominio (Clínicos)
• Admite cualquier Terminología/Tesauro/Sistema de Codificación
• Semánticamente Coherente

El mantenimiento de las especificaciones de openEHR es realizado por el Comité Editorial del Estándar (SEC), utilizando un proceso de gobernanza similar al de los proyectos de código abierto. Las especificaciones de openEHR están disponibles de forma libre y gratuita para que cualquiera pueda implementarlas. Por esto decimos que openEHR es una "especificación de código abierto", pero esto no debe confundirse con "software de código abierto": openEHR no es un software, es una guía detallada de cómo construir plataformas de información clínica.

La propiedad intelectual del estándar openEHR es gestionada por la Fundación openEHR, una organización sin fines de lucro localizada en el Reino Unido.

La Metodología de openEHR

Para una implementación exitosa de las especificaciones de openEHR, nosotros recomendamos hacer foco en tres procesos generales:

• Gobernanza
• Modelado Clínico
• Ingeniería

Gobernanza openEHR

Cualquier proyecto openEHR debería contar con un proceso de governanza bien definido, el cual incluye como gestionar diferentes profesionales, procesos, materiales, insumos, y tecnologías involucradas en la implementación de las especificaciones de openEHR.

Planificar y gestionar cada aspecto de la implementación, y definir las estrategias de adopción de openEHR, deberían ser también partes del proceso de governanza. Para definir y ejecutar estos procesos de forma exitosa, es clave contar con el asesoramiento de expertos en openEHR, tanto en las áreas clínicas como informáticas, cubriendo desde la gestión hasta la implementación.

Modelado Clínico con openEHR

openEHR define el enfoque de "modelo dual", dónde separa la gestión de artefactos de conocimiento y datos clínicos, de la gestión de las tecnologías de implementación. Este es un aspecto central en el paradigma de desarrollo de sistemas con openEHR y es lo que aporta a la gran mantenibilidad de los sistemas: los cambios en el contenido clínico no afectan al software, y los cambios en el software no afectan al contenido y datos clínicos. Este es el principal diferenciador que tienen los sistemas basados en openEHR en comparación con el tradicional enfoque monolítico de los sistemas de información en salud.

El modelo dual de openEHR implica la creación y mantenimiento de definiciones de contenido clínico por fuera, y de forma independiente, a la implementación técnica de la plataforma de historias clínicas. Esto contribuye a la separación entre los proceso de ingeniería y gestión tecnológica, de los proceso de gestión de la información clínica, permitiendo que los profesionales clínicos e informáticos gestionen cada uno de esos aspectos de forma independiente y más eficiente.

Ingeniería openEHR

Este proceso incluye la implementación técnica de las especificaciones de openEHR en un stack tecnológico concreto, la gestión de modificaciones y correcciones, la integración con distintos protocolos de comunicación, formatos de mensajería y estándares de intercambio de información, la gestión de herramientas openEHR para modelado y gestión de modelos de manera eficiente.

Arquitectura openEHR

Otro aspecto de las especificaciones de openEHR es la arquitectura de software propuesta. Los componentes centrales incluyen un repositorio de datos clínicos y un repositorio de datos demográficos. Como consecuencia, en una plataforma openEHR, los datos clínicos residen en un lugar físico distinto al de los datos de identificación y localización de los pacientes y clínicos.

Este aspecto implica algunas medidas de seguridad incluidas por diseño, por ejemplo la posibilidad de utilizar la información clínica para usos secundarios (no clínicos), sin la necesidad de agregar más medidas de seguridad a la implementación del repositorio de información clínica. Esto es también compatible con la norma HIPAA de Estados Unidos.

Por lo tanto, un repositorio de datos clínicos openEHR puede ser utilizado fuera de un entorno estrictamente clínico, como pueden ser el de salud pública y el de investigación clínica. Es decir que el alcance de openEHR excede los límites de las historias clínicas, pudiendo ser utilizado a distintos niveles y contextos: organizacional, federal, regional, nacional e internacional.

La arquitectura en capas de openEHR

La arquitectura propuesta por openEHR tiene un diseño en capas, un patrón que permite definir, gestionar y utilizar diferentes niveles semánticos en estructuras de datos clínicos, lo que facilita la implementación estandarizadas de distintas funcionalidades: almacenamiento y consulta de datos, intercambio de datos, análisis de datos, validación de datos, generación de interfaces de usuario, etc.

El núcleo de las especificaciones de openEHR es el Modelo de Información de Referencia (RM), que es la capa inferior de la arquitectura de capas antes mencionada. El RM es un modelo de información genérico para datos clínicos, demográficos, de versionado y auditoría. El RM no incluye ninguna estructura de datos específica del dominio, por lo tanto el RM define el nivel más abstracto de la información a ser gestionada en la plataforma.

La segunda capa está definida por el Modelo de Arquetipos, el cual permite definir restricciones sobre el RM para especificar conceptos de dominio atómicos. Por ejemplo, un arquetipo puede utilizarse para definir el concepto de Presión Arterial, Frecuencia Cardíaca, Solicitud de Estudios de Laboratorio, Diagnosis, Prescripción de Medicación, Ejecución de Procedimientos, Resumen Obstétrico, Plan de Cuidados, Puntuación de Apgar, etc. pero solo un concepto por cada arquetipo. Un arquetipo incluye la definición de: 1. estructura de datos, 2. restricciones de validación de datos, 3. terminología, 4. metadatos para gestión.

La tercera capa es el Modelo de Plantillas, el cual permite unir distintos arquetipos en una estructura de información compleja, para ser utilizada en un contexto particular. Por ejemplo, una plantilla puede utilizarse para definir un documento clínico de consulta cardiológica. Una plantilla puede contener referencias a múltiples arquetipos, definir qué partes de esos arquetipos utilizar, y definir más restricciones de las presentes en los arquetipos, siempre y cuándo esas restricciones no violen las de los arquetipos.

Sobre la capa de plantillas, otras muchas capas semánticas pueden ser definidas:

• Apoyo a la Decisión Clínica
• Especificación de Interfaces de Usuario
• Consulta/Acceso a Datos
• Mapeo de Datos
• Flujos de Trabajo

Los elemento definidos por esas capas en la arquitectura de openEHR deben contar con una representación formal y computable, lo que permite que el software pueda consumir esos elementos como "metadatos" que modifican el comportamiento del propio sistema. Esto implica un cambio de paradigma en el desarrollo de sistemas de información clínica: el software basado en openEHR es genérico, adaptable y mantenible por diseño. Entonces, los mismos componentes de software pueden ser utilizados/reutilizados para crear diferentes tipos de sistemas, solamente modificando los elementos definidos por openEHR.

Preparado para el futuro y costo-efectivo

En el mundo de las historias clínicas, la mayoría de los proyectos requieren de 2 a 5 años de implementación e integración de diversos sistemas, los cuales van a ser mantenidos por unos 15 a 20 años más, hasta que un proceso de reingeniería requiera una actualización a nuevas tecnologías. La mayoría de las personas hacen foco en los costos de implementación, mientras que la gran mayoría de los costos se encuentran en la etapa de mantenimiento.

Los sistemas de historía clínica actuales, con enfoques monolíticos, no fueron diseñados para ser modificables con facilidad, lo que acarrea altos costos de mantenimiento ante nuevos requisitos funcionales, debido a que cada cambio, por pequeño que este sea, implica modificaciones a múltiples capas del software, desde las bases de datos, hasta la capa de presentación. Además, cada cambio al software requiere un proceso formal de verificación, testing y aseguramiento de la calidad, lo que, aparte de aumentar los costos, enlentece el despliegue de nuevas funcionalidades.

Las especificaciones de openEHR, con su la arquitectura en múltiples capas, el modelado dual, y las herramientas disponibles, fueron diseñadas para que toda implementación de openEHR sea facilmente modificable. Esto se debe a que en la metodología de modelado dual, la mayoría de los nuevos requisitos de registro, almacenamiento, y consulta de información se implementan como modificaciones en los modelos clínicos (arquetipos, plantillas, etc.), no como cambios al software, es decir que las actualizaciones al sistema pasan a ser responsabilidad de los expertos del dominio clínico, en lugar de ser responsabilidad de los informáticos.

Este nivel de modificabilidad de los sistemas basados en openEHR permiten reducir los costos de mantenimiento al mínimo, y tienen el potencial de reducir también los costos de reingeniería y migración de datos, debido a que separa el conocimiento y datos clínicos de la tecnología. Lo importante en una implementación de openEHR son las definiciones de contenido y los datos, no la tecnología.