Arquetipos openEHR: La Capa de Contenido Clínico de un CDR con Futuro
Los arquetipos son los bloques constructivos del enfoque de modelado en dos niveles de openEHR: definiciones formales, reutilizables y computables de conceptos clínicos —una medición de presión arterial, un peso corporal, una orden de medicación— expresadas en el Archetype Definition Language (ADL), neutral al proveedor [2]. Bajo este enfoque, un modelo de referencia estable constituye el primer nivel, definiendo estructuras de datos genéricas (composiciones, entradas, valores de datos) que nunca cambian con el contenido clínico, mientras que los arquetipos y las plantillas forman el segundo nivel, expresando significado clínico como restricciones sobre ese modelo de referencia [1]. Los datos en tiempo de ejecución son conformes dos veces: concretamente con el modelo de referencia y semánticamente con los arquetipos.
Cada arquetipo es desarrollado de forma colaborativa por expertos clínicos y técnicos a través del Clinical Knowledge Manager (CKM) — el repositorio internacional de la Fundación openEHR, que gestiona el ciclo de vida completo de arquetipos y plantillas mediante un proceso formalizado de revisión y publicación, y proporciona gobernanza sobre la base de conocimiento compartida [3]. El resultado es un activo genuinamente inusual en la informática de la salud: una biblioteca global y con licencia abierta de definiciones de datos validadas clínicamente que cualquier plataforma conformante puede consumir.
Por Qué Dos Niveles Cambian la Economía de un CDR
El beneficio arquitectónico de separar el modelo de referencia de la capa de contenido clínico es contundente: el mismo esquema de persistencia puede almacenar cualquier concepto clínico sin cambios estructurales. Dado que la semántica clínica vive en los arquetipos y no en tablas de base de datos o código de aplicación, desplegar un nuevo concepto —una nueva escala de evaluación, una nueva medición de dispositivo, un checklist de síntomas pandémico— significa cargar un nuevo arquetipo y plantilla en el CDR, no programar una versión de software y una migración de esquema. La documentación de arquitectura de openEHR describe exactamente este contraste con los sistemas "clásicos", donde la semántica del dominio está codificada en algún lugar del software o la base de datos y cada cambio clínico se convierte en un cambio de ingeniería [1].
Para un CTO, esto reformula la pregunta de construir versus evolucionar. En nuestra experiencia, el costo total de una plataforma de datos clínicos no está dominado por la construcción inicial sino por la década de cambios en el modelo clínico que sigue — y el modelado en dos niveles mueve ese trabajo desde el backlog de ingeniería hacia el flujo de trabajo de modelado (mucho más económico y rápido). Las consultas siguen la misma lógica: las consultas AQL de openEHR acceden a los datos por rutas de arquetipo en lugar del esquema físico, por lo que el desacoplamiento es completo.
Lo Que los Arquitectos Deben Comprender: Versionado, Especialización, Slots
- Versionado: Los identificadores de arquetipo llevan su versión mayor (p. ej.,
openEHR-EHR-OBSERVATION.blood_pressure.v2), y el CKM gestiona el ciclo de vida desde borrador hasta publicado [4]. Los datos confirmados contra una versión de arquetipo permanecen válidos contra ella para siempre — por lo que una estrategia de actualización para la capa de modelado (qué versiones de arquetipos están en producción, cómo se adoptan nuevas versiones mayores, cómo las consultas abarcan versiones) pertenece a tu arquitectura, no a una página de wiki descubierta más tarde. - Especialización: Cuando los requisitos locales genuinamente superan un arquetipo publicado, la especialización es el mecanismo de extensión controlado: un arquetipo hijo agrega o estrecha restricciones mientras permanece conforme a su padre, de modo que los datos capturados con el arquetipo especializado pueden ser procesados y consultados por cualquier cosa que entienda el padre. Notablemente, el soporte mejorado para especialización y redefinición es uno de los avances principales de ADL 2 sobre ADL 1.4 — la versión en la que creció la mayoría de las herramientas y plataformas, y la base del estándar ISO 13606-2 [2].
- Slots y plantillas: Los arquetipos se componen: un slot es un punto de inserción definido donde un arquetipo permite que otros se conecten (por ejemplo, una observación de presión arterial que incorpora un cluster de dispositivo). Las plantillas luego ensamblan y restringen aún más los arquetipos para un caso de uso concreto — un formulario específico, documento o carga útil de API — produciendo las estructuras operacionales contra las que un CDR valida las composiciones al confirmar. Arquitectónicamente, los arquetipos son tu vocabulario reutilizable; las plantillas son las oraciones que tus sistemas realmente intercambian.
El Stack de Modelado de openEHR de un Vistazo
| Capa | Qué Define | Quién la Gobierna | Velocidad de Cambio |
|---|---|---|---|
| Modelo de Referencia | Estructuras genéricas y estables: composiciones, entradas, tipos de datos, versionado, auditoría | Programa de especificaciones de openEHR | Muy lento — medido en años |
| Arquetipos | Definiciones máximas y reutilizables de conceptos clínicos como restricciones sobre el RM | Revisión y publicación de la comunidad CKM (instancias internacionales y nacionales) | Moderado — ciclo de vida versionado y gobernado |
| Plantillas | Ensamblajes de arquetipos para casos de uso: formularios, documentos, cargas útiles de API | Proyecto local / organización | Rápido — desplegable en tiempo de ejecución, sin nueva versión de software |
Estrategia de Selección: Primero Reutilizar, Luego Especializar, Inventar al Final
Al seleccionar o diseñar arquetipos para un despliegue, el orden que maximiza la interoperabilidad es consistente: adoptar primero los arquetipos publicados en el CKM — cada arquetipo publicado que se reutiliza es una definición de datos compartida con todo otro despliegue openEHR del mundo, sin costo de modelado. Cuando un arquetipo publicado casi encaja, participar en el proceso del CKM (solicitudes de cambio, revisiones) en lugar de hacer un fork local; el modelo federado de instancias internacionales y nacionales del CKM existe precisamente para que las necesidades locales puedan retroalimentar los activos compartidos [4]. Cuando los requisitos locales son genuinamente locales, especializar en lugar de inventar, preservando la compatibilidad con el padre. Solo cuando un concepto no tiene ancestro publicado se debe crear desde cero — y entonces considerar contribuirlo de vuelta.
Las herramientas dan soporte a este flujo de trabajo de extremo a extremo: herramientas de modelado web como el Archetype Designer de Better, junto con el compilador de referencia ADL Workbench y el ecosistema más amplio catalogado por la Fundación openEHR [5], producen artefactos ADL 1.4 o ADL 2 adecuados para cargar en plataformas CDR conformantes. En nuestra experiencia, las herramientas raramente son el cuello de botella — la gobernanza del modelado lo es: decidir quién posee la selección de arquetipos, quién aprueba las especializaciones y cómo los cambios de plantilla llegan a producción es lo que separa los programas openEHR disciplinados de la proliferación de arquetipos.
El Rol de CaboLabs
Los arquetipos son donde vive CaboLabs. Hemos pasado años diseñando sistemas basados en openEHR — modelado clínico, diseño de plantillas, implementación de CDR e integración con ecosistemas FHIR y HL7 — y construimos nuestro repositorio de datos clínicos, Atomik, nativo en openEHR desde la base: valida cada composición contra sus plantillas al confirmar, almacena cualquier concepto definido por arquetipo sin cambios de esquema, y hace consultables los datos clínicos a través de rutas de arquetipo. Eso es el modelado en dos niveles entregado como infraestructura funcional, no como una promesa en diapositivas.
Si estás evaluando openEHR para una plataforma de datos clínicos, definiendo tu gobernanza de arquetipos y flujo de modelado, o buscando un CDR que convierta los arquetipos publicados en datos de producción, habla con nosotros en cabolabs.com — te ayudaremos a construir sobre los modelos clínicos que el mundo ya acordó.