ドキュメントファーストのopenEHR永続化レイヤー

臨床クエリファミリーの調整

このソリューションは、MongoDB上のドキュメントファーストでセミフラット化された永続化モデルにより、この課題に対応します。セミフラット化とは、各要素を配列内のノードとしてフラット化しつつも、それぞれが元の構造における完全なJSONペイロードを保持することを意味します。ドキュメントファーストとは、各openEHRコンポジションを、アーキタイプごとに1テーブルやパスごとに1行に分解するのではなく、1つのMongoDBドキュメントとして保持することを意味します。同時に、コンポジションは再構成可能なノード配列としてマテリアライズされ、運用単位としてのコンポジションを維持しながら、パスベースの効率的なクエリを可能にします。

各格納ノードは、次の主要要素を保持します。

• ローカルな臨床サブツリーにより、元の意味とコンテキストが保持されます。

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

• 逆順のAQLパスにより、可変深度のパス制約の効率的なマッチングが可能になります。

この逆順パスは、患者単位および患者横断の両方の実行経路において構造的述語を効率的に評価するために使用される汎用的なクエリキーです。正規表現ベースのマッチングやワイルドカード形式のパス解決（検索インデックス内）を含む、さまざまな実行戦略におけるパス制約付きマッチングをサポートします。述語が他のテキストパス要素やテキスト条件を使用する場合でも、同じクエリパターンを適用できます。

このモデルでは、AQL句をMongoDBのクエリステージに決定的にコンパイルできます。FROM、CONTAINS、WHEREの制約は、ノードパスおよび値に対するターゲット化された述語になります。このアプローチでは、主要な臨床コンテナとしてのコンポジションを維持したまま、大規模環境においても運用上の取得を実用的に実現します。

図1。各ノードが自身のコンテキストと値に加えて逆順のAQLパスを保持する、セミフラット化されたコンポジションの表現

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

多くのリポジトリでは、単一のセミフラット化コレクションとワイルドカードインデックスで十分です。より大規模なデプロイメントでは、このモデルは、広範な患者横断フィルタリングに必要なデータのみを含むスリムなサーチプロジェクションを使用できます。クエリ実行はその後、スコープに基づいてルーティングされます。スリムな検索プロジェクションは、広範な患者横断フィルタリングに必要なノードフィールドのみを格納する、より小さな派生コレクションです。これはメインのコンポジションドキュメントを置き換えるものではありません。これにより、広範な運用クエリにおけるインデックスの広がりと検索コストが削減されます。

したがって、次のモダリティが提供されます。

• 患者単位のクエリは、メインのコンポジションコレクション上で実行され、ehr_idやreversed_pathといったフィールドに対する複合インデックスなどのターゲット化されたインデックスを使用します。

• 患者横断クエリは、よりスリムなプロジェクションに対して実行され、パス制約は逆順パスに対するワイルドカードまたはマッチ条件にコンパイルされ、値の述語は等価、範囲、または検索オペレーターにコンパイルされます。

この実行モデルは単一のクエリインターフェースを提供し、ワークロードの規模や選択性に応じて異なる物理的アクセスパスを可能にします。

運用コホートクエリのサポートが重要な理由

現代の臨床アプリケーションでは、同一のプラットフォーム上で両方のクエリファミリーを必要とするケースが増えています。臨床医は、1人の患者の記録を即座に開き、次のような問いを発する必要がある場合があります。

• どの患者が特定の期間内に特定の投薬を受けましたか。

• どの患者がプロトコルまたは安全ルールに適合しますか。

• どの過去症例が本症例と臨床的に類似していますか。

これらの運用上の問いには、データを別のシステムに分離して繰り返しETL処理にかけることなく、回答できる必要があります。

ドキュメントファーストでセミフラット化されたモデルは、openEHRの強みを維持しつつ、これらのワークロードを実用的に実現します。これは、コンポジションを権威ある運用単位として維持し、再構成可能な構造によって臨床的忠実性を保ちつつ、アプリケーションチームに対して患者中心ストアと別個の患者横断プラットフォームのいずれかを選択させることを回避します。小規模なリポジトリでは、1つのセミフラット化コレクションでシンプルに運用できます。大規模なリポジトリでは、広範な運用フィルタリングのコストを削減するために、より小さなプロジェクションを追加できます。

当社の評価では、このアプローチは両方のワークロードタイプにおいて低いエンドツーエンドのレイテンシを維持し、患者単位および患者横断クエリのいずれにおいても、大規模環境下でも低い応答時間を実現しました。この効率性は、運用取得、来歴認識処理、セマンティックエンリッチメント、およびAI主導のワークフローを単一のプラットフォームでサポートする必要があるopenEHRリポジトリにとって、実用的な基盤であることを裏付けています。

このパターンは、ドキュメントファーストの臨床データ戦略向けの実験的なリファレンスランタイムおよびツールキットであるkehrnelを使用して検証できます。

このアプローチにより、次の実用的な利点が得られます。

• コンポジションの忠実性を維持する再構成可能なセミフラット化モデル。

• 臨床ドキュメントをリレーショナルに分割することなく実現される、効率的な患者単位クエリ。

• ウェアハウスファーストのアーキテクチャに依存することなく、患者横断の運用取得をサポート。

• 重複したストアや分断されたロジックの代わりに、アプリケーションチームに単一の運用クエリサーフェスを提供。

• ETLのオーバーヘッド、ガバナンスドリフト、および総所有コストの低減につながるアプローチ。

Kehrnelとは何か、なぜ使用するのか

Kehrnelは、ヘルスケアデータモデルを運用機能へと変換する戦略ランタイムです。Kehrnelが存在する理由は、ヘルスケアデータモデルを定義するだけでは不十分だからです。チームには、データを検証し、運用表現へと変換し、取り込み、クエリし、維持し、要件の変化に応じて進化させるための、再現可能な手段も必要です。そのような実行レイヤーがなければ、モデルは単なるドキュメント、ストレージスキーマ、または孤立した仕様のままにとどまることが多くなります。

目標は、openEHRエンジンを構築することにとどまりません。Kehrnelは、ヘルスケアデータモデルを実行可能で検証可能、かつ再利用可能にするための、再現可能なドキュメントファーストのアプローチを提供し、API、ツール群、およびAIワークフロー全体で活用できます。時間の経過とともに、同一のランタイムパターンは、FHIR、合成データワークフロー、セマンティックカタログ、自然言語検索、およびその他のドメイン固有ツールを含む、他のモデルファミリーや運用戦略もサポートできるようになります。

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

KehrnelはopenEHRから開始されます。これは、openEHRが要求の厳しいセマンティックに豊富なモデルであるためです。これには、アーキタイプ、テンプレート、パス、用語、および複雑なクエリ動作が含まれます。これにより、モデル駆動型ランタイムアプローチを実証するための強固な基盤が形成されます。

このソリューションでは、Kehrnelはドキュメントファーストの永続化パターンのためのリファレンスランタイムおよびツールキットとして機能します。

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

本ドキュメントの読み方

1つのMongoDBドキュメントは、1つのopenEHRコンポジションを表します。cn配列には、そのコンポジションから抽出されたクエリ可能なノードが格納されます。各ノードは、data内にローカルな臨床サブツリー、p内に逆順パスキー、およびkp、pi、およびbkといった位置メタデータを保持し、元の構造を再構築できるようになっています。

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

反転パスエンコーディング

格納されたパスフィールドは、主要な最適化を表します。リファレンスモデルの属性およびアーキタイプノード識別子は、openEHRパスを構築します。このソリューションでは、逆順で格納されたパスを使用し、先頭のワイルドカードスキャンではなくプレフィックスフレンドリーなマッチングで包含制約を評価できるようにします。この設定は、患者単位ルートでは標準的な正規表現ベースのマッチングと組み合わせて機能し、検索ルートではワイルドカード形式のマッチングと組み合わせて機能します。

決定的なAQLから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句は必要なopenEHR構造を定義し、この場合は管理クラスターと投薬アクションを含むワクチン接種コンポジションを指します。WHERE句は、アクション時間、実施者識別子、および管理コードに対する述語を追加します。

このクエリタイプは決定的なコンパイルの利点を享受します。これは階層的な臨床構造とノードローカル値に関する条件を表します。

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

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

• トップレベルのehr_idフィルターはクエリを患者に関連付けられたスコープにします。

• $all句は、AQLで記述されたすべての構造分岐が同一のコンポジション内に存在することを要求します。

• 各$elemMatchは、パス述語およびその値述語を同一の格納ノードにバインドします。

• pに対する述語は、構造的なCONTAINSロジックのコンパイル結果です。

• data配下の述語は、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"
                  }
               }
            ]
         }
      }
   }
]);

同じロジックが検索ルートへどのように適用されるか

論理的な変換は、患者横断ルートでも同じまま維持されます。違いは物理的な実行にあります。メインのコンポジションコレクションでマッチングする代わりに、コンパイラはスリムな検索プロジェクションを対象とします。逆順パスに対する構造的制約はワイルドカードフィルターとなり、値の述語は範囲および等価フィルターになります。

次の例は、単一患者に限定されない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"
                              }
                           }
                        ]
                     }
                  }
               }
            }
         ]
      }
   }
}

繰り返し構造と同一パスの兄弟要素

一部のopenEHR構造には、同一の有効パスを持つ繰り返しの兄弟ノード（例えば、繰り返されるEVENTs）が含まれる場合があります。これらのケースでは、条件が同一の繰り返し要素によって満たされるように、コンパイラが述語をより深いレベルへプッシュする必要があります。標準的な集約では、これはより深くネストされた$elemMatchを意味します。検索ルートでは、対応するのはembeddedDocumentであり、複数の条件を同一の埋め込み配列要素にバインドします。