Camada de persistência openEHR do Document-First

Reconciliar família de query médica

Esta solução aborda esse problema com um modelo de persistência semi-achatado que prioriza os documentos no MongoDB . Semi-achatado significa que achatamos cada elemento como um nó em uma array, mas cada um preserva a carga útil completa do JSON na estrutura original. Documento-primeiro significa que cada composição openEHR é preservada como um documento MongoDB , em vez de ser decomposta em uma tabela por arquetipo ou uma linha por caminho. Ao mesmo tempo, a composição é materializada como uma array de nós reconstruível, permitindo uma query eficiente baseada em caminho sem abandonar a composição como unidade operacional.

Cada nó armazenado retém os seguintes elementos principais:

• Subárvore médica local, para que o significado e contexto originais permaneçam disponíveis.

• Metadados posicionais, para que a estrutura e a ordenação possam ser reconstruídas.

• Caminho AQL invertido, que permite a correspondência eficiente de restrições de caminho de profundidade variável.

O caminho invertido é uma chave de query geral usada para avaliar predicados estruturas de forma eficiente nas rotas de execução com escopo de usuário e entre pacientes. Ele oferece suporte à correspondência restrita de caminho em diferentes estratégias de execução, incluindo a correspondência baseada em regex e a resolução de caminho no estilo curinga em índices de pesquisa. Os mesmos padrões de query podem ser aplicados quando os predicados usam outros componentes do caminho do texto ou condições do texto.

Com esse modelo, as cláusulas AQL podem ser compiladas deterministicamente nos estágios de query do MongoDB . As restrições FROM, CONTAINS e WHERE se tornam predicados direcionados sobre os caminhos e valores dos nós. Essa abordagem mantém a composição intacta como o principal contêiner analítico e, ao mesmo tempo, torna a recuperação operacional prática em escala.

figura 1. Representação de gravações semiachatadas em que cada nó carrega seu próprio contexto e valores, além do caminho inverso do AQL

Roteamento por volume de trabalho

Para muitos repositórios, uma única coleção semi-achatada e índices curinga são suficientes. Para implementações maiores, o modelo pode utilizar uma projeção de pesquisa fina que contém apenas os dados necessários para uma ampla filtragem entre pacientes. A execução da query é então roteada por escopo. Uma projeção de pesquisa limitada é uma collection derivada menor que armazena somente os campos de nó necessários para uma filtragem ampla entre pacientes. Não substitui o documento principal de composição . Ele reduz a largura do índice e o custo de pesquisa para amplas consultas operacionais.

Portanto, disponibiliza as seguintes formas:

• As queries com escopo de doente são executadas na collection de composição principal, usando índices direcionados, como um índice composto em campos como ehr_id e reversed_path.

• As queries entre pacientes são executadas na projeção mais fina , compilando restrições de caminho em curingas ou correspondências no caminho inverso, e predicados de valor em operadores de igualdade, intervalo ou pesquisa.

Esse modelo de execução fornece uma única interface de query, permitindo diferentes caminhos de acesso físico com base no tamanho e na seletividade do volume de trabalho.

Por que as queries de coorte de operações de apoio são importantes

Os aplicativos gráficos modernos precisam cada vez mais de ambas as classes de query na mesma plataforma. Um médico pode precisar abrir o registro de um doente imediatamente e fazer perguntas como:

• Quais pacientes receberam determinada preparação em determinada janela de tempo?

• Quais pacientes correspondem a um protocolo ou regra de segurança?

• Quais casos anteriores são cliticamente semelhantes a este?

Essas questões operacionais exigem respostas sem enviar dados por meio de ciclos repetidos de ETL em sistemas separados.

Um modelo semi-achatado de documentos em primeiro lugar preserva os pontos fortes do openEHR e torna essas cargas de trabalho práticas. Ele mantém a composição como a unidade operacional autoritária, preserva a fidelidade médica por meio de uma estrutura reconstruível e evita forçar as equipes de aplicação a escolher entre um armazenamento centralizado no cliente e uma plataforma separada entre pacientes. Repositórios menores podem permanecer simples, com uma coleção semi-achatada. Repositórios maiores podem adicionar uma projeção menor para reduzir o custo de uma ampla filtragem operacional.

Em nossa avaliação, essa abordagem manteve uma baixa latência de ponta a ponta em ambos os tipos de volume de trabalho, com baixos tempos de resposta para queries com escopo definido e entre pacientes, mesmo em grande escala. Essa eficiência a valida como uma base prática para repositórios openEHR que devem oferecer suporte à recuperação operacional, processamento com reconhecimento de procedência, enriquecimento semântica e fluxos de trabalho orientados por IA de uma plataforma.

Você pode explorar esse padrão com o kahrnel, um tempo de execução de referência experimental e um conjunto de ferramentas para estratégias de dados físicos que priorizam o documento.

Essa abordagem oferece os seguintes benefícios práticos:

• Um modelo semi-achatado reconstruível que preserva a fidelidade da composição.

• Query eficiente com escopo de usuário sem forçar um fragmento relacional do documento crítico.

• Suporte para recuperação operacional entre pacientes sem padronizar para uma arquitetura de armazenamento inicial.

• Uma superfície de query operacional para equipes de aplicação , em vez de armazenamentos duplicados e lógica fragmentada.

• Um caminho para reduzir a sobrecarga de ETL, reduzir os desvios de controle e reduzir o custo total de propriedade.

O que é Kerrnel e por que usá-lo?

O Kernel é um tempo de execução de estratégia que transforma modelos de dados de saúde em capacidades operacionais. A Kahrnel existe porque definir um modelo de dados de saúde não é suficiente. As equipes também precisam de uma maneira repetível para validar dados, transformá-los em uma representação operacional, ingeri-los, consultá-los, mantê-los e evoluí-los à medida que os requisitos mudam. Sem essa camada de execução, os modelos geralmente permanecem documentação, esquemas de armazenamento ou especificações isoladas.

O objetivo é mais amplo do que construir um mecanismo openEHR. A Kohrnel oferece uma abordagem repetível de documentos em primeiro lugar para tornar os modelos de dados de saúde executáveis, inspecionáveis e reutilizáveis em APIs, ferramentas e fluxos de trabalho de IA. Com o tempo, o mesmo padrão de tempo de execução pode oferecer suporte a outras família de modelos e estratégias operacionais, incluindo FHIR, fluxos de trabalho de dados sintéticos, catálogos semânticas, recuperação de linguagem natural e outras ferramentas específicas de domínio.

O Kernel foi projetado em torno de fluxos de trabalho expostos que podem ser personalizados para as necessidades de cada estratégia de persistência. Cada estratégia pode definir suas próprias operações de ativação, validação, ingestão, transformação, query, dados sintéticos e manutenção, sem deixar de usar um modelo de tempo de execução consistente.

Kernel começa com o openEHR porque o openEHR é um modelo exigente e rico em semântica. Inclui arquetipos, modelos, caminhos, terminologia e comportamento de query complexo. Isso o torna uma base sólida para provar uma abordagem de tempo de execução orientada por modelo.

Para esta solução, o Kohrnel serve como tempo de execução de referência e conjunto de ferramentas para o padrão de persistência do documento em primeiro lugar.

figura 2. Captura de tela do Keyrnel CLI

Como ler este documento

Um documento MongoDB representa uma composição openEHR. A array cn armazena os nós consultáveis extraídos dessa composição. Cada nó mantém uma subárvore médica local em data, uma chave de caminho reverso em p e metadados posicionais como kp, pi e bk para que a estrutura original possa ser reconstruída.

O exemplo público mostra a chave de caminho em um formato legível para facilitar o acompanhamento da tradução. Na produção, você pode armazenar o mesmo caminho que os tokens codificados pelo dicionário compacto para reduzir o tamanho do caminho e a pegada do índice

Codificação de caminho inverso

O campo de caminho armazenado representa a otimização da chave. Atributos do modelo de referência e identificadores de nó de arquetipo constroem caminhos openEHR. Essa solução usa um caminho armazenado inverso, permitindo que as restrições de contenção sejam avaliadas com correspondência compatível com prefixos em vez de varreduras curingas. Essa configuração funciona com a correspondência baseada em regex padrão na rota com escopo definido pelo cliente e com a correspondência no estilo curinga na rota de pesquisa.

Tradução de AQL determinístico para MQL

O AQL é independente do modelo de armazenamento, tornando a compilação determinística eficaz. As cláusulas SQL são convertidas para MQL da seguinte forma:

• FROM e CONTAINS se tornam predicados de caminho estrutural.

• WHERE tornam-se predicados de valor nas cargas úteis do nó correspondente.

• SELECT torna-se projeção.

• ORDER BY torna-se classificação.

O exemplo a seguir ilustra uma 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

O que este AQL pede

Esta query combina restrições estruturas e baseadas em valor. A cláusula CONTAINS define as estruturas openEHR necessárias, no caso, uma composição de imunização que contém um cluster administrativo e uma ação de preparação. Em seguida, a cláusula WHERE adiciona predicados no tempo de ação , no identificador do executor e um código administrativo.

Este tipo de query se beneficia da compilação determinística. Expressa condições sobre estruturas médicas hierárquicas e valores nó-local.

Como o compilador mapeia o AQL para o MQL

O MQL compilado segue a mesma lógica do AQL:

• O filtro de nível superior ehr_id torna a query com escopo definido pelo cliente.

• A cláusula $all exige que todas as ramificações estruturas descritas pela AQL estejam presentes na mesma composição.

• Cada $elemMatch vincula um predicado de caminho e seus predicados de valor ao mesmo nó armazenado.

• O predicado em p é a forma compilada da lógica estrutural CONTAINS.

• Os predicados sob dados são a forma compilada das condições WHERE.

• Em um pipeline completo, o compilador adiciona os estágios de projeção e classificação que correspondem a SELECT e ORDER BY.

O exemplo a seguir mostra um padrão simplificado de MQL com escopo de usuário gerado a partir da query AQL acima. Ele ilustra a lógica do compilador, não uma carga de tempo de execução byte-by-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"
                  }
               }
            ]
         }
      }
   }
]);

Como a mesma lógica se move para a rota de pesquisa

A tradução lógica permanece a mesma na rota entre pacientes. A diferença é a execução física. Em vez de fazer a correspondência com a coleção de composição principal, o compilador tem como alvo a projeção de pesquisa fino . As restrições estruturas no caminho inverso se tornam filtros curinga, e os predicados de valor se tornam filtros de intervalo e igualdade.

O exemplo a seguir mostra um padrão de MQL gerado a partir de um AQL não vinculado a um doente. Como antes, ele ilustra a lógica do compilador, não uma carga útil de tempo de execução byte-by-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"
                              }
                           }
                        ]
                     }
                  }
               }
            }
         ]
      }
   }
}

Estruturas repetidas e irmãos do mesmo caminho

Algumas estruturas openEHR podem conter nós irmãos repetidos com o mesmo caminho efetivo, por exemplo , EVENTs repetido. Esses casos exigem que o compilador empurre os predicados mais profundamente para que as condições sejam satisfeitas pelo mesmo item repetido. Na agregação padrão , isso significa $elemMatch aninhado mais profundo. Na rota de pesquisa, o equivalente é embeddedDocument, que vincula várias condições ao mesmo elemento de array incorporado.