驴Qu茅 es openEHR?
Especificaciones de c贸digo abierto para plataformas de historia cl铆nica preparadas para el futuro.
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.
驴Tienes alguna pregunta?
Dinos c贸mo podemos ayudarte.