Capa de persistencia de openEHR basada en documentos

Reconciliar familias de consultas clínicas

Esta solución aborda el problema mediante un modelo de persistencia semi-aplanado basado en documentos en MongoDB. Semi-aplanado significa que cada elemento se presenta como un nodo en un array, pero conserva la carga útil JSON completa en su estructura original. El enfoque basado en documentos implica que cada composición de openEHR se conserva como un único documento de 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 array de nodos reconstruible, lo que permite realizar consultas eficientes basadas en rutas sin abandonar la composición como unidad operativa.

Cada nodo almacenado conserva los siguientes elementos clave:

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

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

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

La ruta invertida es una clave de consulta general que se utiliza para evaluar predicados estructurales de manera eficiente tanto en rutas de ejecución específicas para cada paciente como entre diferentes pacientes. Admite la coincidencia con restricciones de ruta en distintas estrategias de ejecución, incluyendo la coincidencia basada en expresiones regulares y la resolución de rutas con comodines en los índices de búsqueda. Los mismos patrones de consulta se pueden aplicar cuando los predicados utilizan otros componentes de ruta textual o condiciones textuales.

Con este modelo, las cláusulas AQL se pueden compilar de forma determinista en las etapas de consulta de MongoDB. Las restricciones FROM, CONTAINS y WHERE se convierten en predicados específicos sobre las rutas y los valores de los nodos. Este enfoque mantiene la composición intacta como contenedor clínico principal, al tiempo que facilita la recuperación operativa a gran escala.

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

Enrutamiento por carga de trabajo

Para muchos repositorios, una única colección semiplana e índices comodín son suficientes. Para implementaciones más grandes, el modelo puede usar una proyección de búsqueda reducida que contenga solo los datos necesarios para un filtrado amplio entre pacientes. La ejecución de la consulta se enruta según el alcance. Una proyección de búsqueda reducida es una colección derivada más pequeña que almacena solo los campos de nodo necesarios para un filtrado amplio entre pacientes. No reemplaza el documento de composición principal. Reduce la amplitud del índice y el costo de búsqueda para consultas operativas amplias.

Por lo tanto, ofrece las siguientes modalidades:

• Las consultas con ámbito de paciente se ejecutan en la colección de composición principal, utilizando índices específicos como un índice compuesto en campos como ehr_id y reversed_path.

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

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

Por qué es importante brindar soporte a las consultas de la Operación Cohorte

Las aplicaciones clínicas modernas requieren cada vez más ambas familias de consultas en la misma plataforma. Un médico podría necesitar abrir el historial de un paciente de inmediato y hacer preguntas como:

• ¿Qué pacientes recibieron un determinado medicamento en un período de tiempo específico?

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

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

Estas cuestiones operativas requieren respuestas sin tener que transferir datos a través de ciclos ETL repetidos a sistemas separados.

Un modelo semiplanificado que prioriza los documentos conserva las ventajas de openEHR y hace que esas cargas de trabajo sean prácticas. Mantiene la composición como la unidad operativa autorizada, preserva la fidelidad clínica mediante una estructura reconstruible y evita que los equipos de desarrollo de aplicaciones tengan que elegir entre un repositorio centrado en el paciente y una plataforma separada para todos los pacientes. Los repositorios más pequeños pueden seguir siendo sencillos, con una colección semiplanificada. Los repositorios más grandes pueden añadir una proyección menor para reducir el coste del filtrado operativo general.

En nuestra evaluación, este enfoque mantuvo una baja latencia de extremo a extremo en ambos tipos de carga de trabajo, con tiempos de respuesta reducidos para consultas específicas de pacientes y consultas entre pacientes, incluso a gran escala. Esta eficiencia lo valida como una base práctica para los repositorios de historias clínicas electrónicas abiertas que deben admitir la recuperación operativa, el procesamiento con conocimiento de la procedencia, el enriquecimiento semántico y los flujos de trabajo basados ​​en IA desde una única plataforma.

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

Seguir este enfoque le brinda los siguientes beneficios prácticos:

• Un modelo semiplano reconstruible que conserva la fidelidad de la composición.

• Consultas eficientes centradas en el paciente sin necesidad de fragmentar la información clínica.

• Compatibilidad con la recuperación operativa entre pacientes sin recurrir por defecto a una arquitectura que priorice el almacenamiento de datos.

• Una única interfaz de consulta operativa para los equipos de aplicaciones, en lugar de almacenes duplicados y lógica fragmentada.

• Un camino hacia una menor sobrecarga de ETL, una menor desviación de la gobernanza y un menor coste total de propiedad.

¿Qué es Kehrnel y por qué usarlo?

Kehrnel es una plataforma estratégica que transforma los modelos de datos sanitarios en capacidades operativas. Kehrnel existe porque definir un modelo de datos sanitarios no es suficiente. Los equipos también necesitan una forma estandarizada de validar los datos, transformarlos en una representación operativa, ingerirlos, consultarlos, mantenerlos y adaptarlos a medida que cambian los requisitos. Sin esta capa de ejecución, los modelos suelen quedarse en documentación, esquemas de almacenamiento o especificaciones aisladas.

El objetivo va más allá de crear un motor de historias clínicas electrónicas abiertas. Kehrnel ofrece un enfoque repetible, centrado en el documento, para que los modelos de datos sanitarios sean ejecutables, inspeccionables y reutilizables en diversas API, herramientas y flujos de trabajo de IA. Con el tiempo, este mismo patrón de ejecución podrá admitir otras familias de modelos y estrategias operativas, como FHIR, flujos de trabajo de datos sintéticos, catálogos semánticos, recuperación de lenguaje natural y otras herramientas específicas del sector.

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, ingesta, transformación, consulta, datos sintéticos y mantenimiento, manteniendo un modelo de ejecución coherente.

Kehrnel parte de openEHR porque es un modelo exigente y semánticamente rico. Incluye arquetipos, plantillas, rutas, terminología y un comportamiento de consulta complejo. Esto lo convierte en una base sólida para demostrar un enfoque de ejecución basado en modelos.

Para esta solución, Kehrnel sirve como entorno de ejecución y conjunto de herramientas de referencia para el patrón de persistencia basado en el documento.

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 array cn almacena los nodos consultables extraídos de dicha composición. Cada nodo conserva 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 en un formato legible para facilitar la traducción. En producción, puede almacenar la misma ruta como tokens codificados en diccionario compacto para reducir el tamaño de la ruta y el espacio que ocupa en el índice.

Codificación de ruta inversa

El campo de ruta almacenada representa la optimización clave. Los atributos del modelo de referencia y los identificadores de nodos de arquetipo construyen las rutas de openEHR. Esta solución utiliza una ruta almacenada invertida, lo que permite evaluar las restricciones de contención con coincidencias compatibles con prefijos en lugar de escaneos con comodines iniciales. Esta configuración funciona con coincidencias estándar basadas en expresiones regulares en la ruta con ámbito de paciente y con coincidencias de estilo 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 que la compilación determinista sea efectiva. Las cláusulas SQL se traducen a MQL de la siguiente manera:

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

• WHERE se convierte en predicados de valor en las cargas útiles del nodo coincidente.

• SELECT se convierte en proyección.

• ORDER BY se convierte en clasificación.

El siguiente ejemplo ilustra una consulta 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

Lo que solicita este AQL

Esta consulta combina restricciones estructurales y basadas en valores. La cláusula CONTAINS define las estructuras de openEHR requeridas, en este caso una composición de vacunación que contiene un grupo administrativo y una acción de medicación. La cláusula WHERE agrega predicados sobre el tiempo de acción, el identificador del profesional y un código administrativo.

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

Cómo el compilador asigna AQL a MQL

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

• El filtro de nivel superior ehr_id hace que la consulta esté limitada al ámbito del paciente.

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

• Cada $elemMatch vincula un predicado de ruta y sus predicados de valor al mismo nodo almacenado.

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

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

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

El siguiente ejemplo muestra un patrón MQL simplificado, específico para cada paciente, generado a partir de la consulta AQL anterior. Ilustra la lógica del compilador, no la carga útil de tiempo 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 aplica 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 realizar la coincidencia en la colección principal de composiciones, el compilador se centra en la proyección de búsqueda reducida. Las restricciones estructurales en la ruta inversa se convierten en filtros comodín, 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 una consulta AQL no vinculada a un paciente específico. Como antes, ilustra la lógica del compilador, no la carga útil de tiempo 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 repetido. En estos casos, el compilador debe profundizar en los predicados para que las condiciones se cumplan con el mismo elemento repetido. En la agregación estándar, esto significa anidar más profundamente $elemMatch. En la ruta de búsqueda, el equivalente es embeddedDocument, que vincula múltiples condiciones al mismo elemento de matriz incrustado.