Document-First openEHP 永続性レイヤー

クリティカル クエリ ファミリーの調整

このソリューションは、 MongoDBのドキュメントファーストの半フラット化された永続性モデルで問題に対処します。半フラット化とは、各要素を配列のノードとしてフラット化しますが、それぞれが元の構造で完全なJSONペイロードを保持することを意味します。ドキュメント ファーストとは、アーカイブタイプごとに 1 つのテーブルやパスごとの 1 行に分割されるのではなく、オープン EHP 構成のそれぞれが 1 つのMongoDBドキュメントとして保持されることを意味します。同時に、構成は再構築可能なノード配列としてマテリアライズドされるため、構成を操作単位として放棄することなく、効率的なパスベースのクエリが可能になります。

保存された各ノードは、次のキー要素を保持します。

• ローカル診断サブツリーなので、元の意味とコンテキストは引き続き利用できます。

• 位置メタデータ、構造と順序を再構築できます。

• 逆 AQL パス。これにより、変数深度パス制約の効率的な一致が可能になります。

逆パスは、クライアントをスコープとした実行ルートとクロスクライアントの実行ルートの両方で構造述語を効率的に評価するために使用される一般的なクエリ キーです。正規表現ベースの一致や、検索インデックスのワイルドカード スタイルのパス解決など、さまざまな実行戦略間でのパス制限された一致をサポートします。述語が他のテキストパスコンポーネントまたはテキスト条件を使用する場合でも、同じクエリ パターンを適用できます。

このモデルでは、QL 句はMongoDBクエリ ステージに確定的にコンパイルできます。 FROM、CONTAINS、WHERE の制約は、ノードパスと値を対象とする述語になります。このアプローチでは、 構成 をプライマリの診断コンテナとして完全に維持すると同時に、 操作上の取得を増やすに 実行可能にします。

図の 1。各ノードが独自のコンテキストと値、および逆方向の AQL パスを保持する半フラット化された構成の表現

ワークロードによるルーティング

多くのリポジトリでは、単一の半フラット化されたコレクションとワイルドカード インデックスで十分です。大規模な配置の場合、モデルは、クロスバッチ フィルタリングに必要なデータのみを含むストリーム検索プロジェクションを使用できます。クエリ実行はスコープによってルーティングされます。ストリーム検索プロジェクションは、広範なクロス整合性フィルタリングに必要なノードフィールドのみを保存する小規模な派生コレクションです。メインの 構成ドキュメントを置き換えるものではありません。幅広い運用クエリでインデックスの幅と検索コストが削減されます。

したがって、次のモーダルを提供します。

• クライアントスコープ クエリは、ehr_id や reversed_path などのフィールドの複合インデックスなどの ターゲット インデックス を使用して、メインの 構成コレクションで実行されます。

• クロス整合性クエリは、よりスロープロジェクションに対して実行され、パス制約をワイルドカードまたは逆パス上の一致にコンパイルし、値述語は等価、範囲、または検索演算子に変換されます。

この実行モデルは 1 つのクエリインターフェイスを提供し、ワークロードのサイズと選択性に基づいて異なる物理アクセスパスを許可します。

操作コスト クエリのサポートが重要な理由

最近の医療アプリケーションでは、同じプラットフォーム上の両方のクエリ ファミリーが必要になります。医療提供者は、1 つの診断レコードをすぐに開き、次のような質問をする必要がある場合があります。

• 特定の時間ウィンドウ内で特定の試行回数を受け取ったユーザーは？

• どのユーザーがプロトコルまたは安全性ルールに一致するか？

• このケースに開発的に類似している過去のケースはどれですか。

これらの運用上の質問では、反復されるETLサイクルを通じてデータを別個のシステムにプッシュせずに回答が必要です。

ドキュメントファーストの半フラット化モデルは、openEHP の強度を維持し、それらのワークロードを実用的にします。これにより、構成を権限のある操作単位として維持し、再構築可能な構造によって医療忠実度を維持し、アプリケーションチームにペインテッド ストアと別の クロスパッチ プラットフォームのどちらかを選択を強制するのを回避します。小規模なリポジトリはシンプルなままで、半フラット化されたコレクション1 つだけで済みます。リポジトリが大きいほど、プロジェクションが小さくなり、広範な運用フィルタリングのコストを削減できます。

評価では、このアプローチは両方のワークロードタイプにわたって終了から終了までのレイテンシが低く、 かつ 、大増やすな場合でも、ページング クエリとクロスクライアント クエリの応答時間は低くなります。この効率は、それを 1 つのプラットフォームから操作的検索、の出所対応プロセシング、セマンティック豊富化、およびAI駆動型ワークフローをサポートする必要がある OpenEHR リポジトリの実用的な基礎として検証します。

このパターンは、実験的な参照ランタイムとドキュメントプライマリデータ戦略用のツールキーであるカーネルで調べることができます。

このアプローチに従うと、次のような実用的なメリットが得られます。

• 構成の忠実度を維持する、再構築可能な半フラット化モデル。

• 医療ドキュメントのリレーショナル シャードを強制しないで、効率的なクライアント スコープのクエリ。

• 倉庫優先アーキテクチャにデフォルト設定せずに、クロスクライアント操作検索をサポートします。

• 重複したストアとフラグメント化されたロジックの代わりに、アプリケーションチームの 1 つの運用クエリ表。

• ETLオーバーヘッド、ガバナンスドリフト、総所有コストを削減するパス。

カーネルとは何であり、それを使用する理由

カーネルは、医療データモデルを運用機能に変える戦略ランタイムです。カーネルが存在するのは、ヘルスヘルスデータモデルを定義するだけでは十分ではないためです。チームは、データを検証し、運用表現に変換し、データを取り込み、クエリを実行し、維持し、要件の変化に応じて開発するための再現可能な方法も必要です。その 実行レイヤーがない場合、モデルは多くの場合、ドキュメント、ストレージスキーマ、または分離された仕様のままになります。

目的は OpenEHRエンジン を構築するよりも幅広いです。 Kernel は、API、ツール、 AIワークフロー全体で医療データモデルを実行可能、検査可能、再利用可能にするための再現可能なドキュメントファーストのアプローチを提供します。時間の経過とともに、同じランタイム パターンは、FHIR、合成データ ワークフロー、セマンティック カタログ、自然言語検索、その他のドメイン固有のツールなど、他のモデルファミリーや運用戦略をサポートすることができます。

カーネルは、それぞれの永続性戦略のニーズに合わせてカスタマイズできる公開ワークフローを基づいて設計されています。各戦略は、一貫したランタイムモデルを使用しながら、独自のアクティベーション、検証、取り込み、変換、クエリ、合成データ、およびメンテナンス操作を定義できます。

OpenEHP は要求が高く、セマンティックが多いモデルであるため、カーネルは OpenEHP で起動します。これには、アーカイブタイプ、テンプレート、パス、用語、複雑なクエリ動作が含まれます。そのため、モデル駆動型ランタイム アプローチを提供するための強力な基盤となります。

このソリューションでは、Kernel はドキュメントファーストの永続性パターンの参照ランタイムとツールキーとして機能します。

図の 2。 Kernel CLI のスクリーンショット

このドキュメントの読み方

1 つのMongoDBドキュメントは1 つのオープン EHP 構成を表します。 cn 配列は、その構成から抽出されたクエリ可能なノードを保存します。各ノードは、data にローカル診断サブツリー、p に逆パスキー、および kp、pi、bk などの位置メタデータを保持するため、元の構造を再構築できます。

公開例では、翻訳を見つけやすくするために、パスキーを読み取り可能な形式で表示しています。本番環境では、辞書でエンコードされた圧縮トークンと同じパスを保存して、パス サイズとインデックスのフットプリントを削減できます

逆パスエンコーディング

保存されたパスフィールドは、キーの最適化を表します。参照モデル属性とアーカイブタイプノード識別子はオープン EHP パスを構築します。このソリューションでは、保存されたパスの逆を使用するため、リージョン ワイルドカード スキャンではなくプレフィックス対応のマッチングで含まれ制約を評価できます。この設定は、クライアントスコープ ルートでは標準の正規表現ベースの一致と、検索ルートではワイルドカード スタイルの一致で機能します。

決定的なQLからMQLへの変換

AQL はストレージ モデルとは独立しているため、決定的なコンパイルが効果的です。 SQL句は次のようにMQLに変換されます。

• FROM と CONTAINS は構造パス述語になります。

• WHERE は、一致したノードペイロードの値述語になります。

• SELECT はプロジェクションになります。

• ORDER BY はソートになります。

次の例は、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

この AQL に求められる内容

このクエリは、構造ベースと値ベースの制約を組み合わせたものです。CONTAINS $次に、WHERE 句は、アクション時間、実行者識別子、および管理コードに関する述語を追加します。

このクエリ タイプは、決定的なコンパイルのメリットがあります。これは、階層的な診断構造とノード ローカルの値に対する条件を表します。

コンパイラーが AQL をMQLにマッピングする方法

コンパイルされたMQL は、 AQL と同じロジックに従います。

• 最上位の ehr_id フィルターにより、クエリは永続的になります。

• $all 句では、QL によって記述されるすべての構造ブランチが同じ構成要素に存在する必要があります。

• 各 $elemMatch はパス述語とその値述語を同じ保存済みノードにバインドします。

• p の述語は、構造化された CONTAINS ロジックのコンパイル済み形式です。

• データの下の述語は、WHERE 条件をコンパイルされた形式です。

• 完全なパイプラインでは、コンパイラーは SELECT と ORDER BY に対応するプロジェクションステージとソート ステージを追加します。

次の例は、上記の AQL クエリから生成された、クライアントを対象とした簡素化されたMQLパターンを示しています。これは、バイト単位のランタイムペイロードではなく、コンパイラーロジックを示します。

// 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"
                  }
               }
            ]
         }
      }
   }
]);

同じロジックが検索ルートにどのように移行するか

論理的な翻訳はクロスクライアント ルートでは同じままです。違いは物理的な実行の違いです。メインの 構成コレクションを照合する代わりに、コンパイラーは 最小検索プロジェクションを対象とします。逆パスの構造制約はワイルドカード フィルターになり、値述語は範囲フィルターと等価フィルターになります。

次の例では、1 人のユーザーにバインドされていない AQL から生成されたMQLパターンを示しています。以前と同様に、ここではバイト単位のランタイム ペイロードではなく、コンパイラー ロジックが示されます。

{
   "$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"
                              }
                           }
                        ]
                     }
                  }
               }
            }
         ]
      }
   }
}

反復される構造と同じパスのシーケンス

一部の OpenEHP 構造には、同じ有効パスを持つ繰り返しのノードを含めることができます（例、EVENTs が繰り返されるなど）。このような場合は、コンパイラーが述語をより深くプッシュして、条件が同じ反復項目によって満たされるようにする必要があります。標準の集計では、 はより深くネストされた $elemMatch を意味します。検索ルートでは、同等の は embeddedDocument です。これは複数の条件を同じ埋め込み配列要素にバインドします。