Capa de persistencia de openEHR basada en documentos

Reconciliar familias de queries clínicos

Esta solución aborda ese problema con un modelo de persistencia semiaplanado y enfocado en los documentos en MongoDB: semiaplanado porque aplanamos cada elemento como un nodo de un arreglo, pero cada uno conserva la carga útil JSON completa en la estructura original; y enfocado en los documentos porque cada composición openEHR se conserva como un solo documento MongoDB, en lugar de descomponerse en una tabla por arquetipo o una fila por ruta. Al mismo tiempo, la composición se materializa como un arreglo de nodos reconstruible, lo que permite un query eficiente basada en rutas sin abandonar la composición como unidad operativa.

Cada nodo almacenado conserva los siguientes elementos clave:

• Subárbol clínico local, para que el significado y el contexto originales permanezcan disponibles.

• Metadatos posicionales, para reconstruir la estructura y el orden.

• Ruta AQL invertida, que permite la coincidencia eficiente de restricciones de ruta de profundidad variable.

La ruta invertida es una clave de query general que se utiliza para evaluar predicados estructurales de manera eficiente en las rutas de ejecución por paciente y entre pacientes. Admite la coincidencia con restricciones de ruta en diferentes estrategias de ejecución, incluida la coincidencia basada en regex y la resolución de rutas con comodín en los índices de búsqueda. Se pueden aplicar los mismos patrones de query cuando los predicados usan otros componentes de ruta textual o condiciones textuales.

Con este modelo, las cláusulas de AQL se pueden compilar de manera determinista en las etapas de query de MongoDB. Las restricciones FROM, CONTAINS y WHERE se convierten en predicados objetivo sobre rutas y valores de nodos. Este enfoque mantiene la composición intacta como contenedor clínico primario a la vez que hace que la recuperación operativa sea práctica a gran escala.

Figura 1. Representación de composiciones semiaplanadas donde cada nodo lleva su propio contexto y valores, más la ruta de AQL invertida

Enrutamiento por carga de trabajo

Para muchos repositorios, una sola colección semi-aplanada y los índices de comodines son suficientes. Para implementaciones más grandes, el modelo puede usar una proyección de búsqueda estrecha que contiene solo los datos necesarios para un filtrado amplio entre pacientes. Luego, la ejecución del query se enruta por alcance. Una proyección de búsqueda estrecha es una colección derivada más pequeña que almacena solo los campos de nodo necesarios para un filtrado amplio entre pacientes. No sustituye al documento de composición principal. Reduce la amplitud del índice y el costo de búsqueda para queries operativas amplias.

Por lo tanto, ofrece las siguientes modalidades:

• Las queries por paciente se ejecutan en la colección de la composición principal, utilizando índices dirigidos como un índice compuesto en campos como ehr_id y reversed_path.

• Las query entre pacientes se ejecutan sobre la proyección más estrecha, compilando las restricciones de ruta en comodines o coincidencias en la ruta invertida, y los predicados de valor en operadores de igualdad, rango o búsqueda.

Este modelo de ejecución proporciona una única interfaz de query, lo que permite diferentes rutas de acceso físico según el tamaño y la selectividad de la carga de trabajo.

Por qué es importante brindar soporte a las queries de cohorte de operaciones

Las aplicaciones clínicas modernas requieren cada vez más ambas familias de queries en la misma plataforma. Es posible que un médico necesite abrir el registro de un paciente inmediatamente y hacer preguntas como las siguientes:

• ¿Qué pacientes recibieron un determinado medicamento en una ventana de tiempo determinada?

• ¿Qué pacientes cumplen con un protocolo o una norma de seguridad?

• ¿Qué casos anteriores son clínicamente similares a este?

Estas preguntas operativas requieren respuestas sin procesar los datos a través de ciclos ETL repetidos en sistemas separados.

Un modelo semiaplanado centrado en documentos conserva las fortalezas de openEHR y hace que esas cargas de trabajo sean prácticas. Mantiene la composición como la unidad operativa principal, preserva la fidelidad clínica mediante una estructura reconstruible y evita que los equipos de aplicación tengan que elegir entre un almacén centrado en el paciente y una plataforma separada para múltiples pacientes. Los repositorios más pequeños pueden seguir siendo simples, con una colección semiaplanada. Los repositorios más grandes pueden agregar una proyección más pequeña para reducir el costo del filtrado operativo amplio.

En nuestra evaluación, este enfoque mantuvo una latencia de extremo a extremo baja en ambos tipos de carga de trabajo, con tiempos de respuesta bajos para las queries por paciente y entre pacientes, incluso a gran escala. Esta eficiencia lo valida como una base práctica para repositorios openEHR que debe admitir la recuperación operativa, el procesamiento atento a la procedencia, el enriquecimiento semántico y los flujos de trabajo impulsados por IA desde una sola plataforma.

Explora este patrón con kehrnel, un entorno de ejecución de referencia experimental y conjunto de herramientas para estrategias de datos clínicos centradas en los documentos.

Al seguir este enfoque obtienes los siguientes beneficios prácticos:

• Un modelo semiaplanado que se puede reconstruir y conserva la fidelidad de la composición.

• Realización de queries por paciente eficientes sin forzar un fragmento relacional del documento clínico.

• Compatibilidad con la recuperación operativa entre pacientes sin recurrir por defecto a una arquitectura centrada en el almacén de datos.

• Una superficie de query operativo para los equipos de aplicación, en lugar de almacenes duplicados y lógica fragmentada.

• Una ruta para reducir los gastos en general de ETL, la desviación de la gobernanza y el costo total de propiedad.

¿Qué es Kehrnel y por qué usarlo?

Kehrnel es un entorno de ejecución de estrategias que transforma los modelos de datos sanitarios en capacidades operativas. Existe porque definir un modelo de datos sanitarios no es suficiente. Los equipos también necesitan una forma repetible de validar datos, transformarlos en una representación operativa, ingerirlos, consultarlos, mantenerlos y mejorarlos a medida que cambian los requisitos. Sin esa capa de ejecución, los modelos a menudo se quedan en documentación, esquemas de almacenamiento o especificaciones aisladas.

El objetivo es más amplio que construir un motor openEHR. El entorno de ejecución Kehrnel proporciona un enfoque repetible centrado en los documentos para hacer que los modelos de datos sanitarios se puedan ejecutar, inspeccionar y reutilizar en las API, herramientas y flujos de trabajo de IA. Con el tiempo, el mismo patrón de entorno de ejecución puede admitir otras familias de modelos y estrategias operativas, incluidos FHIR, flujos de trabajo de datos sintéticos, catálogos semánticos, recuperación del lenguaje natural y otras herramientas específicas de dominio.

El Kehrnel está diseñado en torno a flujos de trabajo expuestos que se pueden personalizar según las necesidades de cada estrategia de persistencia. Cada estrategia puede definir sus propias operaciones de activación, validación, ingestión, transformación, consulta, datos sintéticos y mantenimiento, sin dejar de utilizar un modelo de entorno de ejecución coherente.

El kehrnel empieza con openEHR porque openEHR es un modelo exigente y con una gran riqueza semántica. Incluye arquetipos, plantillas, rutas, terminología y un comportamiento de query complejo. Esto lo convierte en una base sólida para demostrar un enfoque de entorno de ejecución impulsado en modelos.

Para esta solución, el Kehrnel sirve como entorno de ejecución de referencia y paquete de herramientas para el patrón de persistencia centrado en los documentos.

Figura 2. Captura de pantalla de la CLI de Kehrnel

Cómo leer este documento

Un documento de MongoDB representa una composición de openEHR. El arreglo cn almacena los nodos consultables extraídos de esa composición. Cada nodo mantiene un subárbol clínico local en data, una clave de ruta invertida en p y metadatos posicionales como kp, pi y bk para que se pueda reconstruir la estructura original.

El ejemplo público muestra la clave de ruta de forma legible para que la traducción sea más fácil de seguir. En producción, puedes almacenar la misma ruta como tokens compactos codificados en un diccionario para reducir el tamaño de la ruta y la huella del índice.

Codificación de ruta invertida

El campo de ruta almacenado representa la optimización clave. Los atributos del modelo de referencia y los identificadores del nodo del arquetipo compilan las rutas de openEHR. Esta solución utiliza una ruta almacenada invertida, lo que permite que las restricciones de contención se evalúen mediante coincidencias que admitan prefijos en lugar del escaneo de comodines iniciales. Esta configuración funciona con las coincidencias estándar basadas en expresiones regulares en la ruta por paciente y con las coincidencias del tipo comodín en la ruta de búsqueda.

Traducción determinista de AQL a MQL

AQL es independiente del modelo de almacenamiento, lo que hace efectiva la compilación determinista. Las cláusulas SQL se traducen a MQL de la siguiente manera:

• FROM y CONTAINS se transforman en predicados de ruta estructural.

• WHERE se convierte en predicados de valor en las cargas útiles de los nodos coincidentes.

• SELECT se convierte en proyección.

• ORDER BY se convierte en orden.

El siguiente ejemplo ilustra un query AQL.

SELECT
  e/ehr_id/value AS ehrId,
  c/uid/value AS compositionId,
  med_ac/description[at0017]/items[at0140]/items[at0141]/value/defining_code/code_string AS locationCode
FROM
  EHR e
  CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.vaccination_list.v0]
  CONTAINS (
    CLUSTER adminInfo[openEHR-EHR-CLUSTER.admin_salut.v0]
    AND SECTION[openEHR-EHR-SECTION.immunisation_list.v0]
    AND ACTION med_ac[openEHR-EHR-ACTION.medication.v1]
  )
WHERE
  med_ac/time/value >= '2000-04-13T07:54:16.345Z'
  AND med_ac/time/value <= '2026-02-13T07:54:16.345Z'
  AND adminInfo/items[at0007]/items[at0014]/value/defining_code/code_string = 'E08019820'
  AND med_ac/other_participations/performer/identifiers/id = '038321545'
ORDER BY
  med_ac/time/value DESC

Qué solicita este AQL

Este query combina restricciones estructurales y basadas en valores. La cláusula CONTAINS define las estructuras openEHR necesarias, en este caso una composición de vacunación que contiene un clúster administrativo y una acción de medicación. A continuación, la cláusula WHERE agrega predicados en la hora de la acción, el identificador del actor y un código administrativo.

Este tipo de query se beneficia de la compilación determinista. Expresa condiciones sobre estructuras clínicas jerárquicas y valores locales de nodo.

Cómo el compilador asigna AQL a MQL

El MQL compilado sigue la misma lógica que el AQL:

• El filtro ehr_id de nivel superior hace que el query sea por paciente.

• La cláusula $all requiere que todas las bifurcaciones estructurales descritas por el AQL estén presentes en la misma composición.

• Cada $elemMatch enlaza un predicado de ruta y su valor es predica del mismo nodo almacenado.

• El predicado en p es la forma compilada de la lógica CONTAINS estructural.

• Los predicados contenidos en los datos son la forma compilada de las condiciones WHERE.

• En una pipeline completa, el compilador agrega las etapas de proyección y clasificación que corresponden a SELECT y ORDER BY.

El siguiente ejemplo muestra un patrón de MQL simplificado por paciente, generado a partir del query de AQL anterior. Ilustra la lógica del compilador, no una carga de ejecución byte a byte.

// Simplified compiler output for a single-EHR query.
// Projection and sorting stages are omitted here for clarity.
db.compositions.aggregate([
   {
      "$match": {
         "ehr_id": "b416bc97-de39-43f5-9d47-712af6688947~r1",
         "cn": {
            "$all": [
               {
                  "$elemMatch": {
                     "p": {
                        "$regex": /^ACTION\.medication\.v1(?:\.[^.]+)*\.SECTION\.immunisation_list\.v0(?:\.[^.]+)*\.COMPOSITION\.vaccination_list\.v0$/
                     },
                     "data.time.value": {
                        "$gte": ISODate("2000-04-13T07:54:16.345Z"),
                        "$lte": ISODate("2026-02-13T07:54:16.345Z")
                     },
                     "data.other_participations.performer.identifiers.id": "038321545"
                  }
               },
               {
                  "$elemMatch": {
                     "p": {
                        "$regex": /^at0014\.at0007\.CLUSTER\.admin_salut\.v0(?:\.[^.]+)*\.COMPOSITION\.vaccination_list\.v0$/
                     },
                     "data.value.defining_code.code_string": "E08019820"
                  }
               }
            ]
         }
      }
   }
]);

Cómo se traslada la misma lógica a la ruta de búsqueda

La traducción lógica se mantiene igual en la ruta entre pacientes. La diferencia radica en la ejecución física. En lugar de buscar la coincidencia en la colección principal de composiciones, el compilador se centra en la proyección de búsqueda estrecha. Las restricciones estructurales en la ruta inversa se convierten en filtros de comodines, y los predicados de valor se convierten en filtros de rango e igualdad.

El siguiente ejemplo muestra un patrón MQL generado a partir de un AQL no vinculado a un paciente. Como antes, ilustra la lógica del compilador, no una carga de ejecución byte a byte.

{
   "$search": {
      "index": "search_nodes_index",
      "compound": {
         "filter": [
            {
               "embeddedDocument": {
                  "path": "sn",
                  "operator": {
                     "compound": {
                        "filter": [
                           {
                              "wildcard": {
                                 "path": "sn.p",
                                 "query": "ACTION.medication.v1*SECTION.immunisation_list.v0*COMPOSITION.vaccination_list.v0"
                              }
                           },
                           {
                              "range": {
                                 "path": "sn.data.time.value",
                                 "gte": ISODate("2000-04-13T07:54:16.345Z"),
                                 "lte": ISODate("2025-04-13T07:54:16.345Z")
                              }
                           },
                           {
                              "equals": {
                                 "path": "sn.data.other_participations.performer.identifiers.id",
                                 "value": "038321545"
                              }
                           }
                        ]
                     }
                  }
               }
            }
         ]
      }
   }
}

Estructuras repetidas y hermanos con la misma ruta

Algunas estructuras de openEHR pueden contener nodos hermanos repetidos con la misma ruta efectiva; por ejemplo, EVENTs repetidos. Estos casos requieren que el compilador eleven los predicados a niveles más profundos para que el mismo elemento repetido cumpla las condiciones. En la agregación estándar, eso indica $elemMatch anidadas a mayor profundidad. En la ruta de búsqueda, el equivalente es embeddedDocument, que vincula varias condiciones al mismo elemento de un arreglo incrustado.