Arquitectura de Repositorios de Datos Clínicos con openEHR: Servicios, Versionado e Identidad

Un Repositorio de Datos Clínicos (CDR) basado en openEHR se comprende mejor no como una base de datos sino como un pequeño conjunto de servicios formalmente especificados sobre un almacén versionado y dirigido por modelos. El Modelo de Servicio de Plataforma openEHR define estas interfaces de servicio de forma abstracta — como referencia estándar que los implementadores mapean sobre sus propias arquitecturas — y la API REST de openEHR les da una forma HTTP concreta y portable [1]. Tres servicios llevan la carga de trabajo central: el Servicio EHR, que gestiona los contenedores EHR de los pacientes y sus composiciones versionadas; el Servicio de Definiciones (conocimiento), que almacena y sirve plantillas operacionales y consultas registradas; y el Servicio de Consultas, que ejecuta AQL sobre los datos almacenados. A su alrededor se encuentran servicios de soporte definidos en el mismo modelo — notablemente un Servicio Demográfico para la identidad de partes y un Índice EHR para localizar registros entre sistemas.

Si estos ejecutan como una plataforma unificada o como microservicios descompuestos es una decisión de despliegue, no arquitectónica — los contratos de servicio son la arquitectura. Lo que no es negociable es la ruta de escritura: todos los datos clínicos entrantes entran como composiciones a través de la API canónica de openEHR y son validados contra su Plantilla Operacional antes de la persistencia [5]. Las capas de integración — feeds HL7 v2, fachadas FHIR, backends de aplicación — alimentan esta única puerta delantera validada en lugar de escribir directamente en el almacenamiento, lo que es precisamente lo que mantiene la confiabilidad de los datos de un CDR a escala.

El Modelo de Versionado: Nada Se Sobrescribe Jamás

La diferencia arquitectónica más profunda entre un CDR openEHR y un EHR relacional convencional es el control de cambios. Cada composición vive dentro de un objeto versionado (un registro controlado por versiones): cada confirmación crea una nueva versión inmutable vinculada a su predecesora, agrupada en una CONTRIBUTION — el objeto de conjunto de cambios que registra qué se confirmó junto, por quién, cuándo y por qué [3]. Las auditorías de confirmación son obligatorias en el modelo, y las firmas digitales y hashes están disponibles a nivel del objeto versionado para despliegues que necesitan evidencia de manipulación con fuerza criptográfica. La API REST preserva estas semánticas incluso detrás de verbos amigables: PUT, POST y DELETE sobre recursos controlados por cambios deben ejecutarse internamente como confirmaciones de versión envueltas en contribuciones — lo que significa que una "eliminación" es en sí misma una nueva versión con un estado de ciclo de vida eliminado, no una supresión [5].

Las consecuencias arquitectónicas son concretas:

• Reconstrucción en un punto del tiempo: dado que el historial completo de versiones y su pista de auditoría son datos de primera clase, cualquier registro de paciente puede reconstruirse tal como estaba en cualquier momento — una propiedad que los requisitos médico-legales y de seguridad clínica demandan cada vez más, y que está garantizada estructuralmente en lugar de reimplementarse por aplicación [4].
• Planificación de almacenamiento y respaldo: los datos nunca se sobrescriben, solo se reemplazan, por lo que los modelos de capacidad deben tener en cuenta la acumulación de versiones, y las estrategias de respaldo/restauración deben preservar la integridad de versiones y contribuciones — restaurar "solo el estado más reciente" no es una restauración fiel de un registro openEHR.
• Flujos de trabajo de enmienda y corrección: las enmiendas clínicas se mapean naturalmente en nuevas versiones con tipos de cambio de auditoría apropiados, por lo que los equipos de aplicación obtienen la semántica de corrección de la plataforma en lugar de inventar columnas de eliminación suave y tablas shadow — en nuestra experiencia una de las simplificaciones más subestimadas que openEHR aporta al diseño de aplicaciones.

Arquitectura de Identidad: IDs EHR, Sujetos y el MPI

El EHR de openEHR es un objeto raíz identificado por un ID EHR globalmente único, con su EHR_STATUS opcionalmente portando el identificador del sujeto de atención [2]. Fundamentalmente, la arquitectura separa deliberadamente el registro clínico de la demografía identificatoria — una medida de seguridad explícita de openEHR: el EHR contiene contenido clínico identificado por un UUID opaco, mientras que quién es el paciente vive en un servicio demográfico, con la referencia del sujeto en EHR_STATUS apuntando a ese espacio de nombres de identidad externo (el patrón de referencia de parte del Modelo de Referencia de openEHR, usando referencias externas con un espacio de nombres explícito).

Esta separación es un activo de privacidad y una obligación de integración. En despliegues de múltiples sistemas, el ID EHR debe vincularse consistentemente a una identidad de sujeto del índice maestro de pacientes — y en nuestra experiencia, el fracaso en establecer y gobernar ese vínculo es la causa raíz de los registros de pacientes fragmentados entre fuentes: la misma persona acumulando múltiples EHRs, o peor, dos personas compartiendo uno. En despliegues nacionales y regionales, el almacén autoritativo de sujeto es típicamente un servicio demográfico dedicado o un servidor de recursos Paciente FHIR fronteado por coincidencia MPI, con el CDR manteniendo solo la referencia cruzada. Arquitectónicamente, trata tres cosas como un único problema de diseño: la estrategia de espacio de nombres de sujeto (qué dominios de identificador existen y quién los posee), la autoridad de coincidencia (dónde se toman las decisiones de fusión/vínculo — nunca en el CDR), y el ciclo de vida del vínculo ID-EHR-a-sujeto (qué sucede en el CDR cuando el MPI fusiona o divide identidades). Decidir estos el primer día es económico; retroadaptarlos en millones de composiciones versionadas no lo es.

Poniéndolo Todo Junto

La forma de referencia para un despliegue de mediana a gran escala, entonces: las capas de integración normalizan los datos entrantes y confirman composiciones válidas según la plantilla a través del Servicio EHR; el Servicio de Definiciones gobierna qué modelos clínicos y consultas están activos, desplegables en tiempo de ejecución; el Servicio de Consultas sirve aplicaciones y analítica a través de AQL, preferiblemente mediante consultas almacenadas; y la identidad se resuelve a través de una capa demográfica/MPI que el CDR referencia pero nunca adjudica. Cada elemento en esa imagen está especificado por un estándar abierto, que es el punto estratégico — la arquitectura, no el producto de ningún proveedor, es aquello de lo que dependen tus datos.

El Rol de CaboLabs

Esta arquitectura no es teórica para nosotros — es lo que CaboLabs construye. Nuestro repositorio de datos clínicos nativo en openEHR, Atomik, implementa el patrón de extremo a extremo: gestión de EHR y composiciones con versionado completo basado en contribuciones, despliegue de plantillas en tiempo de ejecución con validación OPT en cada confirmación, consultas AQL y servicios demográficos con coincidencia de pacientes de grado MPI diseñada para despliegues de múltiples sistemas y distribuidos. Detrás está un historial que incluye EHRServer, nuestro CDR openEHR de código abierto anterior, y años de consultoría en arquitectura CDR, estrategia de identidad e integración basada en estándares entre openEHR, FHIR y HL7.

Si estás diseñando una plataforma de datos clínicos, evaluando CDRs openEHR, o desenredando la identidad de pacientes entre sistemas, habla con nosotros en cabolabs.com — hemos construido el repositorio que describe este artículo, y podemos ayudarte a construir el tuyo.