ハイブリッド FHIR 運用データレイヤー

ソリューション概要

このプロジェクトでは、ヘルスチェック用の FHIR ハイブリッド ODL パターンを開発しています。主な目的は、カスタマーウェブ サービスを強化する単一の高パフォーマンスの運用ストアを作成することです。さらに、この設計はスコープ内のリソースに対して FHIR 互換の エンドポイントを公開するため、新しいカスタム サービスの代わりに FHIR REST API を使用して将来の機能を構築できます。

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

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

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

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

マッピングは FHIR 先で定義されるため、FHIR に整合されたフィールドは標準構造を使用して保存されますが、残りの属性は別個のアプリケーションブロックに保持されます。このハイブリッド構造により、ソリューションは完全な FHIRサーバーとして動作するよう強制されることなく、相互運用性が維持されます。

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

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

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

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

デモおよび開発用に、ODL は合成診断データセットを生成できるため、実際の対象データを公開することなく実際のテストが可能になります。

参照アーキテクチャ

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

このユースケースは、複数の EHP プラットフォームを運用する大規模な医療機関に関係する、実際のカスタマーチャレンジに基づきます。各システムは個別にクライアントにアクセスするサービスを提供するため、 断片化されたデータアクセス、重複するロジック、およびセマンティック相互運用性が存在しませんでした。

これを簡素化するために、この組織は ODL を導入して、医療データアクセスを一元化し、既存のアプリケーションを中断することなく共有 MDM サービスを提供します。

この状況により、データ構造とセマンティクスを何も再定義しない代わりに、 FHIR を 共通言語として採用することで、業界のベストプラクティスに移行する機会が生じました。 ODLデータモデルをFHIR ファーストで設計することで、組織はインスタンスやエンタープライズなどの主要概念のロールの再生成を回避しました。標準のリソース定義にも一致するため、フィールドの他のリソースの潜在的なモデルにもなります。

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

図の 1。 FHIR ハイブリッド 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 コンテンツの場合: 有効なR4 FHIRオブジェクトが含まれています（ PatientやEncounter など）。このブロックは、追加の変換なしで 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"
   }
}

ソリューションのビルド

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

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

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 準拠のソリューションを迅速にプロトタイプ化、検証、配置するのに役立ちます。

作成者

• Atlas または 3 つ、 MongoDB

• Francesc Mateu Amengual, MongoDB

詳細

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

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

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