キャパシティー ギャップ検出のためのクリティカル 決定サポート

MongoDB Atlas: キー機能

複雑な医療ワークロード用に設計されているMongoDB Atlas は、高度に最適化されたネイティブ データのエコシステムを持つレガシーシステムを置き換えます。以下は、プラットフォームがリアルタイム決定サポートを提供できるようにする主要機能の概要です。

図の 3。 Atlas キーの機能

柔軟なドキュメントモデル: patient_360 collectionは、人口統計、条件、変数、ラボ、バイパスの概要、クエリのギャップ、アラート、パーソナライズされたしきい値、データプロバイダーなど、完全なレコードを1 つのドキュメントに保存します。 FHIR ストアに対する複数リソースの結合を必要とする質問に、単一のドキュメントが答えます。

時系列コレクション: synthetic_vitalsコレクションは、 MongoDB のネイティブ時系列コレクションを使用してデバイスのデータを保存します。これらのコレクションは、自動データバケット、効率的な範囲クエリ、高頻度の時間順データ用の専用ストレージを提供します。

変更ストリーム: プラットフォームは 変更ストリーム を使用して、新しいバイマリにリアルタイムで対応します。読み取りが達すると、システムは CDS ルールを評価し、ポーリングせずに診断アラートを生成します。

クエリ可能な暗号化: MongoDB Queryable Encryption は、保管中の機密性の高いユーザー フィールドを保護します。このアプリケーションは、プレーンテキストを公開せずに暗号化された PHI フィールドをクエリするため、HIPAA 要件を満たし、別の暗号化レイヤーが不要になります。

集計パイプライン: このフレームワークは、ダッシュボード集計、キャパシティーの計算、重要な傾向分析、および HEDIS スコアリングを処理し、複雑な医療クエリをミリ秒単位で解決します。

AIと分析の構造: patient_360ドキュメントは、正規化された診断結果、構造化された証明機関、メタデータの出所を、追加の変換なしで下流のAIと分析パイプラインに提供します。

データ生成パイプライン

初期化時に、このソリューションは マルチステップパイプラインを使用して CDS システムをシードおよびアクティブ化します。次に示すように、

図の 4。データ生成パイプライン

データ生成パイプラインは、合成およびマテリアライズドの医療データを作成し、パーソナライズされたしきい値とバイナリを計算し、リアルタイムのモニタリングを開始する初期化シーケンスをドライバーします。パイプラインは、次のように動作します。

1. FHIR ユーザ バンドルを生成します。条件、医療、検査結果、エンタープライズ、エラーを含む FHIR R トランザクション4 バンドルを作成します。これらのバンドルは FHIR データ ストアに保存され、 相互運用性レイヤーとして機能します。

2. バイパス履歴を生成します: 24クライアントごとに 時間の時系列バイザーサインを生成し、正常、低下、または急激な上昇する自然パターンを表します。データはsynthetic_vitals 時系列コレクションに保存されます。

3. customer_360 ドキュメントをマテリアライズドします: patient_360MongoDB Atlasの各 FHIR バンドルを非正規化された ドキュメントに変換します。変換には、ソースdata_provenance FHIRレコードにリンクする ブロックが含まれています。

4. CDS ルールを参照してください: 診断サポートのルール定義をcds_rules コレクションに挿入します。

5. パーソナライズされたしきい値を計算します: 有効な有効期限を計算します。これらの結果はpatient_360 ドキュメントに保存されます。

6. CDS AlertEnginealertsルールを評価します。現在のバイナルに対して を実行し、生成されたアラートを コレクションに書込みます 。

7. HEDIS キャパシティー QualityEnginepatient_360ギャップを計算します。各クライアントの診断履歴に対して を実行し、構造化されたケア ギャップの結果を ドキュメントに書込みます。

8. プロバイダー属性をシード:attributions コレクションでプロバイダーと対象の属性関係を生成し、ギャップ結果とアラートを受け取るプロバイダーを決定します。

9. リアルタイムモニタリングを開始: バイナル シミュレーション ワーカーを有効にし、サーバーが送信したイベントを介してライブ バイナル サイン データを医療プラットフォームにストリーミング開始します。

CDS エンジン

CDS エンジンは対象データを分析し、医療チームに実行可能なインサイトを提供します。このソリューションは、医療モニタリングを品質測定計算から 2 つの独立したエンジンに分離します。このアーキテクチャ パターンは、リアルタイム運用性を実現するための HL7 FHIR アクティベーション プログラムであるDa MongoDB Atlas に準拠しています。

ケア ギャップ ワークフロー

ケア ワークフローは、医療組織がユーザーの実際の医療と確立された医療ガイドラインとの間の相違を識別、追跡、解決するために使用するシステム的なプロセスとして機能します。インスタンス検出のギャップは、次のアクションで構成される識別から閉じまでの構造化されたパスに従います。

• 評価: QualityEngineは、HEDS 測定基準に対して各ユーザーの診断履歴を評価します。

• 書込み: システムは、オープン ギャップをpatient_360 ドキュメントに、関連するエビクション、 推奨アクション、優先順位とともに書き込みます。

• レビュー: ケア コーディネーターは、優先順位と超過期間でソートされて、クリティカル プラットフォーム内のオープンなギャップをレビューします。

• 間隔: KED や CDC-HBA などのアクション可能なギャップの場合、プラットフォームは構造化された介入ワークスペースを開き、コーディネーターはラボを順序付け、完了を記録、または追跡スケジュールをスケジュールします。

• 閉じる: 介入が完了すると、 ドキュメント内のギャップpatient_360 ステータスが更新され、QualityEngine は次のサイクルで再評価されます。

• エスカレーション: が AlertEngine診断アラートを検出すると、関連するオープン ギャップの優先順位を引き上げ、 ケアチームに通知します。関連するギャップのないアラートは（セカンダリ警告など）、独立した診断通知として医療チームに直接ルーティングされます。

ドキュメント配列としての医療データ

patient_360ドキュメントでは、各条件は conditions 配列のエントリを表し、各内訳のドキュメントは medications 配列のエントリを表します。以下に示すように、このドキュメントにはクリティカル エンティティが別々のテーブルに分裂するのではなく、使用される形状で保存されています。

{
   "conditions": [
      {
         "code": "44054006",
         "display": "Type 2 diabetes mellitus",
         "clinical_status": "active",
         "onset_date": "2017-10-21T21:29:59.716351+00:00"
      },
      {
         "code": "433144002",
         "display": "Chronic kidney disease stage 3",
         "clinical_status": "active",
         "onset_date": "2023-09-12T21:29:59.716372+00:00"
      }
   ],
   "medications": [
      {
         "display": "Insulin glargine 100 units/mL injection",
         "dose": "20.0 units",
         "route": "subcutaneous",
         "frequency": "once daily at bedtime",
         "status": "active"
      },
      {
         "display": "Atenolol 50 mg oral tablet",
         "dose": "50.0 mg",
         "route": "oral",
         "frequency": "once daily",
         "status": "active"
      }
   ]
}

計算された操作フィールド

FHIR バンドルには標準的な相互運用性データが含まれていますが、patient_360ドキュメントには、クリティカル フラグ、キャパシティー結果、パーソナライズされたしきい値、アクティブなアラートなど、FHIR が定義していない運用フィールドが組み込まれています。

インスタンス、マテリアライズドパイプライン は、より広範なデータ生成パイプラインに埋め込まれ、FHIR バンドルから診断フラグを計算し、それを patient_360ドキュメントに直接書込みます。 AlertEngine はこれらのフラグを読み取り、次のようなクライアントに適用される CDS ルールを判断します。

• flags.has_beta_blocker: ベータ ブロックのハートレート ルールを有効にします。

• flags.has_insulin: 多要素低クラスター ルールを有効にします。

• flags.has_ckd: CKD メタデータリこの条件と置換ルールを有効にします。

• flags.condition_codes: すべてのアクティブな条件の STOPOED コード。

結果のギャップは同じアプローチを使用します。マテリアライズドパイプラインはクエリ ギャップの結果を計算し、それを直接 patient_360ドキュメントに追加します。計算された各 HEDIS 測定値は、関連付けられた status、priority、evidence、recommended_action とともに care_gaps 配列内に保存されます。標準の FHIR とは異なり、ドキュメントモデルはこの情報をユーザーの 診断レコードと一緒に保存します。この構造の例を以下に示します。

{
   "care_gaps": [
      {
         "hedis_measure": "CDC-HBA",
         "measure_name": "Comprehensive Diabetes Care — HbA1c Testing",
         "status": "open",
         "days_overdue": 34,
         "priority": "high",
         "evidence": {
            "found": ["HbA1c 5.13% (2025-10-07)"],
            "missing": []
         },
         "recommended_action": "Schedule or order an HbA1c follow-up"
      }
   ]
}

このアプローチは柔軟性を高めます。医療要件が変更された場合は、ドキュメントを拡張できます。新しい CDS ルールは、既存のフィールドに影響を与えずに新しいフィールドを同じドキュメントに書込みます。

ソース レコードへのトレーサビリティ

patient_360ドキュメントは派生操作ビュー を構成し、 FHIRレコードの置き換えではありません。マテリアライズドパイプラインは、FHIR リソースからこのビューを生成します。医療的な決定やクエリのギャップの結果を監査するために、すべてのドキュメントには data_provenance ブロックが含まれています。

{
   "data_provenance": {
      "layer": "cds_operational",
      "source_fhir_collection": "synthetic_patients",
      "source_patient_id": "1b3bbaec-def8-4b55-8e87-9d04b55d6890",
      "materialization_version": "1.0",
      "last_materialized_at": "2026-05-09T21:30:04.873754+00:00",
      "fhir_resource_count": 22
   }
}

FHIR データストアは、相互運用性のための真実の標準ソースであり続けますが、 MongoDB Atlas は運用ビューを保持し、ソースデータへの直接リンクを維持します。

ドキュメントモデル内の暗号化されたフィールド

医療機関規則では、アプリケーションは PHI を暗号化する必要があります。一般的なアプローチでは、暗号化された PHI を別のシステムに保存し、必要な場合にのみ取得します。ただし、このフレームワークでは 2 番目のデータ ストア、別の キー管理レイヤー、すべてのケースで取得されるレコードのレイテンシが増加します。

MongoDB Queryable Encryption、同じドキュメント内で PHI を維持するこのオーバーヘッドが排除されます。ユーザ名、MRN、誕生日などの機密性の高いフィールドを保護し、暗号化のキーで認可されたクライアントアプリケーションのみが読み取れるようにします。ドキュメントの残りの部分は、運用上の使用のために引き続きクエリ可能です。

{
   "demographics": {
      "name": { "$binary": { "base64": "EAXZmoXjO0re...", "subType": "06" } },
      "given": { "$binary": { "base64": "EF1RChFVFEJC...", "subType": "06" } },
      "family": { "$binary": { "base64": "EK18iT8qVki8...", "subType": "06" } },
      "birth_date": { "$binary": { "base64": "EJOsqgLJPEjI...", "subType": "06" } },
      "gender": "female",
      "age": 77
   }
}

例、AlertEngine や QualityEngine の読み取りフラグ、しきい値、クエリ ギャップ フィールドなどのマイクロサービスは、暗号化されたモニターフィールドを読み取りません。