ハイブリッド FHIR オペレーショナルデータレイヤー

ソリューション概要

このプロジェクトでは、医療向けの FHIR ハイブリッド ODL パターンを開発します。主要な目標は、カスタマー ウェブ サービスを強化する単一で高パフォーマンスな運用保存先の作成です。さらに、この設計は、スコープのリソースの FHIR互換 エンドポイントを公開するため、新規カスタムサービスではなく、FHIR REST API を使用して将来の機能をビルドできるようになります。

本質的に、ODL は構造化された3ブロック形式の Patient または Encounter など、リソースを保存する柔軟でスケーラブルなデータベースとして、MongoDB Atlas を使用します。これには以下が含まれます。

• マッピングが存在する場合の標準的な FHIR 表現。

• アプリケーション固有の追加フィールド。

• クエリ パフォーマンス向けに最適化され、事前にインデックス化された検索フィールド。

マッピングは FHIR ファーストでマッピングされるため、FHIR に準拠したフィールドは標準構造を使用して保存され、残りの属性は別のアプリケーションブロックに保存されます。このハイブリッド構造によって、ソリューションに完全な FHIR サーバーとして動作することを強要せずに、相互運用性を維持できます。

バックエンドは FastAPI を使用し、次の2つの API ファミリーを公開します。

• アプリケーションAPI: ODL を共有バックエンドとして使用し、例検索、ケース検索、ローカル識別子サービスなどのカスタマーの運用におけるエンドポイントとなる接続されたデバイスを実装します。

• FHIR API: Patient や Encounter などの定義されたリソースのサブセットに対して FHIR 互換の検索をする機能を提供し、同じエンベロープモデルとインデックスを再利用します。これは、完全なプロファイル駆動型 FHIR サーバーではなく、実用的なFHIR ファサードとして設計されています。

フロントエンドでは Next.js を使用し、インタラクティブな API デモンストレーターが含まれているため、チームはアプリケーションのエンドポイントとなる接続されたデバイスと FHIR スタイルのクエリを一緒に試すことができます。

デモと開発向けに、ODL は合成臨床データセットを生成できるため、実際の患者データを公開することなく現実的なテストを行えます。

参照アーキテクチャ

このアーキテクチャは、カスタム運用アクセスパターンと同じデータセットでのFHIR互換アクセスをサポートする参照データモデルアプローチである FHIR Hibrid ODL に焦点を当てています。このアプローチではデータを複製するのではなく、運用クエリの重要な情報をインデックス化して、完全な FHIR リソースが維持されます。

ここのユースケースは、大規模な医療機関が複数の EHR プラットフォームを運用することに関係するカスタマーの課題に由来しています。各システムは患者に個別のアクセスサービスを提供していたため、データアクセスの分断、ロジックの重複、セマンティック相互運用性の欠落が発生していました。

これを簡素化するために、この機関は ODL を導入し、既存のアプリケーションを中断することなく、臨床データアクセスを一元化し、MDM サービスの共有を実現しました。

このような状況は、データ構造やセマンティックを一から再定義する代わりに、FHIR を共通言語として採用することで業界のベストプラクティスに移行するための機会を創造しました。ODL データモデルを FHIR ファーストとして設計することで、組織は患者や診療などの本質的概念を「一から作り直す」ことを回避できました。また、これは標準的なリソース定義とも一致するため、この分野の他の部分に対する潜在的なモデルになっています。

この参照アーキテクチャでは、MongoDB Atlas を使用して、医療会社がさまざまなデータソースを統合し、カスタムプロセスをサポートし、高パフォーマンス API を提供する方法を示します。インターフェースはタブに分割され、各タブはアーキテクチャの特定の機能を示しています。

図 1. FHIR Hybrid ODL 参照アーキテクチャ

まず、マッピングセクションでは、過去の医療データフィールドが、FHIR 中心のスキーマに基づいて設計された ODL データモデルにマッピングされる方法を示しています。各ドキュメントには以下が保存されます。

• 標準的な FHIR リソース（FHIR マッピングが存在する場合）

• 現在のワークフローに必要なアプリケーション固有のフィールド

• API で使用される検索用に最適化されたフィールド

ユーザーはインタラクティブな表にある Patient やEncounter などのエンティティ間でフィールドマッピングの完全なセットを閲覧できます。これにより、FHIR 仕様からのフィールドや、アプリケーションまたは検索フィールドとしてモデル化されたフィールドを理解することができます。このマッピング戦略を活用すると、データ系統を追跡し、基準への適合性を評価するのが容易になります。

図 2. ハイブリッド FHIR ODL デモのマッピングタブ

このプラットフォームには、保存とテスト取得向けに合成臨床データを作成する組み込みのジェネレータが含まれており、チームはこれを使用して機能をテストできます。ユーザーは、患者数、患者あたりの診察、医療提供者、ケアチームなどの合成コンテンツをカスタマイズできます。

図 3. 合成臨床データ作成者

データが生成されると、ユーザーは「データビューア」セクションで MongoDB に保存された FHIR リソースを探索できます。標準の FHIR コンテンツと追加の ODL フィールドが1か所に表示されるため、標準データと運用データがどのように共存するかが明確になります。

カスタマー API セクションは、レガシー医療システムをプラットフォームと統合します。API テスターを使用すると、ユーザーはカスタマー固有の MDM と運用エンドポイントを呼び出すことができます。エンドポイントを選択し、必要なパラメータを入力することで、ユーザーはクエリを実行しカスタムシステムが期待するとおりの形式化された応答を表示できます。

最後に、FHIR API テスターセクションでは、基礎のデータセットに対して FHIR 標準の検索を実行できます。結果には、 MongoDB クエリパイプラインと FHIR 応答が表示されます。このビューでは、プラットフォームが FHIR 標準準拠の出力を維持し、パフォーマンスに関するインサイトを提供し、デバッグの詳細を提供する方法が強調されています。

データモデルアプローチ

アーキテクチャは、MongoDB に保存されている FHIR 中心の ODLスキーマに基づいてビルドされます。患者データと診察データを多くの表にまたがって散在させる代わりに、各レコードは3つのセクションで単一のドキュメントとして保存されます。各セクションは、ODL 内で特定の目的を果たします。

• resource 標準 FHIR コンテンツの場合: Patient や Encounter など、有効な R4 FHIR オブジェクト が含まれます。このブロックは、追加の変換なしで FHIRスタイルのエンドポイントによって直接返されます。

• app アプリケーションメタデータ用: ワークフローで必要とされ、基本 FHIRリソースの一部であるフィールドを保持します。これには、内部コード、分類フラグ、その他のカスタマー固有の属性などのフィールドが含まれます。

• search 非正規化されたクエリ表現用: 名前、主要な日付、組織、ロケーション参照などの識別子を含む、クエリで最も頻繁に使用される属性を平坦化します。また、関係キーは、インデックスを簡単に作成して API レイヤーで使用するためのフィールドに変換されます。

以下は、Encounter リソースのコメント付き JSON の例です。

{
   "_id": "ObjectId",
   "tenant": "tenant-1",
   "resourceType": "Encounter",
   // 1 Canonical FHIR block
   "resource": {
      "resourceType": "Encounter",
      "id": "036fcfcd-797c-4ae2-a30f-49226357deb2",
      ...,
      "status": "onhold",
      "class": {
         "code": "EMER"
      },
      "serviceType": {
         ...
      },
      "period": {
         "start": "2025-10-31T17:43:00",
         "end": "2025-11-02T17:43:00"
      },
      "serviceProvider": {},
      "hospitalization": {},
      "participant": [],
      "location": [],
      "type": [
         { ... }
      ]
   },
   // 2 Application block
   "app": {
      "caseNum": "QH-1761928980-83",
      "doctorCode": "DR100",
      "specialistCode": "DR100",
      ...,
      "sourceIndicator": "SELF",
      "patientGroup": "G2"
   },
   // 3 Search block
   "search": {
      "start": "2025-10-31T17:43:00",
      "end": "2025-11-02T17:43:00",
      "local_id": "A108548(0)",
      ...,
      "caseNum": "QH-1761928980-83",
      "statusCode": "onhold",
      "caseType": "E"
   }
}

ソリューションのビルド

詳細な設定手順については、この GitHub リポジトリの README に記載されている手順に従ってください。このリポジトリは、このデモのバックエンドとフロントエンドをホストしています。

このデモを自分の環境で再現するには、次の手順に従います。

git clone https://github.com/mongodb-industry-solutions/hybrid-fhir-odl.git
cd hybrid-odl

MONGODB_URI=mongodb+srv://<user>:<password>@<cluster-url>/?retryWrites=true&w=majority
MONGODB_DB=fhir_demo
MONGODB_COLLECTION=fhir
MONGODB_TENANT=tenant-1

NEXT_PUBLIC_ENABLE_FHIR = true
BACKEND_URL=http://localhost:3100

make install

make backend

make frontend

キーポイント

• レガシー医療システムの最新化: このソリューションは、病院が運用ワークフローを放棄することなく、臨床データインフラストラクチャを更新するための方法を示しています。このアプローチを使用すると、医療機関は完全にカスタマイズされたサービスを維持したり、完全に FHIR に切り替えたりすることなく、これらのシステムを段階的に統合できます。データは FHIR リソースとして引き続き利用可能であり、カスタムアプリケーションエンドポイントと既存のクエリパターンは、アプリケーション API レイヤーを通じて引き続き機能します。このソリューションを使用する病院は、インフラストラクチャを段階的に最新化し、臨床チームとパートナーシステムを自己のペースで移行させることができます。

• 医療データのパフォーマンスを最適化: このアプローチを利用すると、FHIR データに変更を加えることなく標準コンプライアンスのリソースブロックに保存することができ、アプリケーション情報は使用頻度の高い属性に保存され、迅速な検索パフォーマンスを実現するためにインデックス化されます。このシステムは、リアルタイム臨床ダッシュボード、運用分析に加えて、登録、トリアージ、ベッド管理中のクイック検索に適しています。

• 相互運用性と開発者の生産性を加速: デュアル API アーキテクチャ、組み込みの合成データ生成、インタラクティブな API テストツールは、既存の病院プロセスを中断することなく、チームが FHIR 準拠ソリューションを迅速にプロトタイプ化、検証、配置するのに役立ちます。

作成者

• パトリシア・レナート・カルニセロ、MongoDB

• Francesc Mateu Amengual, MongoDB

詳細

• MongoDB と Microsoft による AI を活用したヘルスケア

• AI を活用した小売業: パーソナライズと精度

• 技術ドキュメントのためのコンテキストを認識するための RG