ケアの間隔検出のための臨床意思決定サポート

MongoDB Atlas: 主な機能

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

図 3 。Atlas の主な機能

柔軟な document model: patient_360 collection は、患者の完全なレコードを 1 つのドキュメントに保存します。これには、人口統計、病状、薬剤、検査、バイタルの概要、ケアの不足、アラート、パーソナライズされたスレッショルド、データの出処が含まれます。1 つのドキュメントで、FHIR ストアに対する複数のリソースの結合が必要な質問に答えることができます。

時系列コレクション: synthetic_vitals コレクションは、MongoDB のネイティブ時系列コレクションを使用してウェアラブル デバイバイス データを保存します。これらのコレクションは、自動データ バッケット化、効率的な範囲クエリ、および高頻度の時間順データの特定の目的のためにビルドされたストレージを提供します。

チェンジストリーム: プラットフォームはチェンジストリームを使用して、新しいバイタルにリアルタイムで反応します。読み取りが到着すると、システムは CDS ルールを評価し、ポーリングせずに臨床アラートを生成します。

Queryable Encryption: MongoDB Queryable Encryption は、保存されている機密性の高い患者フィールドを保護します。アプリケーションは、平文を露出せずに暗号化された PHI フィールドをクエリし、HIPAA 要件を満たし、別の暗号化レイヤーの必要性を排除します。

集計パイプライン: このフレームワークは、ダッシュボードの集計、ケアギャップの計算、バイタルの値の傾向分析、HEDISスコアリングを取り扱い、複雑な臨床クエリをミリ秒単位で解決します。

AI と分析の構造: patient_360 ドキュメントは、規格化された臨床データ、構造化された証拠、およびメタデータのプロバンスを、追加の変換なしでダウンストリームの AI および分析パイプラインに提供します。

データ生成パイプライン

初期化時、このソリューションは複数のステップからなるパイプラインを使用して CDS システムをシードして有効化します。詳細は以下に示します。

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

データ生成パイプラインは、合成された実際の臨床データを作成し、個人化されたスレッショールドとケアのギャップを計算し、リアルタイム モニタリングを開始する初期化シーケンスを推進します。パイプラインは次のように機能します。

1. FHIR 患者バンドルを生成する: 状態、薬剤、検査所見、エンカウンター、アレルギーを含む FHIR R4 トランザクションバンドルを作成します。これらのバンドルは、相互運用層として機能する FHIR データストアに保存されます。

2. バイタル履歴を生成します。患者ごとに24時間のバイタルサインの時系列を生成し、正常、悪化、または急性の生理学的パターンを表します。データはsynthetic_vitals時系列コレクションに保存されます。

3. patient_360 ドキュメントを実体化する: 各 FHIR バンドルを MongoDB Atlas の非正規化された patient_360 ドキュメントに変換します。変換には、ソース FHIR レコードにリンクする data_provenance ブロックが含まれます。

4. シード CDS ルール: 臨床意思決定支援ルール定義を cds_rules コレクションに挿入します。

5. パーソナライズされたスレッショルドを計算します: 活動中の薬剤と状態に基づいて患者ごとのバイタルサインのスレッショルドを計算します。これらの結果は patient_360 ドキュメントに保存されます。

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

7. HEDIS ケアギャップを計算する: QualityEngine を各患者の診療歴に対して実行し、構造化されたケアギャップの結果を patient_360 ドキュメントに書き込みます。

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

9. リアルタイムモニタリングを開始する: バイタルシミュレーションワーカーを有効化し、サーバーから送信されるイベントを介してライブのバイタルサインデータを臨床プラットフォームにストリーミングします。

CDS エンジン

CDS エンジンは患者データを分析し、ケアチームに実行可能なインサイトを提供します。このソリューションでは、臨床モニタリングと品質測定の計算が2つの独立したエンジンに分かれます。このアーキテクチャパターンは、ケアの相互運用性のためのHL7 FHIRアクセラレータプログラムであるDa Vinciイニシアティブに準拠しています。このプログラムでは、リアルタイムアラートとHEDISギャップロジックの分離が推奨されています。

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

ケアギャップワークフローは、ヘルスケア組織が患者の実際の臨床ケアと設定された医療ガイドラインとの不一致を特定、追跡、解決するために使用するシステマティックなプロセスとして機能します。ケアギャップ検出は、次のアクションで構成される識別からクロージャーまでの構造化されたパスをたどります。

• 評価: QualityEngineは、各患者の臨床歴史をHEDIS測定基準と照らし合わせて評価します。

• 書き込み (write)：システムは、サポートする証拠、推奨されるアクション、優先順位とともに、開いているギャップをpatient_360ドキュメントに書き込みます。

• 検討: ケアコーディネーターは、優先順位と期限過ぎ期間でソートされている臨床プラットフォーム内の開放されているギャップを検討します。

• 介入: KED や CDC-HBA などの実行可能なギャップに対して、プラットフォームは構造化された介入ワークスペースを開き、コーディネーターは検査を注文し、完了を記録し、またはフォローアップを予定します。

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

• エスカレート: AlertEngine が臨床アラートを検出すると、関連する開いているギャップの優先順位を上げ、ケアチームに通知します。関連するギャップのないアラートは、敗血症の警告のように、独立した臨床通知としてケアチームに直接ルーティングされます。

ドキュメント配列としての臨床データ

patient_360ドキュメントでは、各条件がconditions配列のエントリを表し、各医薬がmedications配列のエントリを表します。以下に示すように、ドキュメントは、別々のテーブルに分割するのではなく、使用される形式で臨床エンティティを保存 (suru)します。

{
   "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: すべてのアクティブな状態の SNOMED コード。

ケアギャップの結果にも同じアプローチを使用します。マテリアライゼーションパイプラインはケアギャップの結果を計算し、それらを patient_360 ドキュメントに直接追加します。計算された各 HEDIS 測定値は、関連する status、priority、evidence、recommended_action とともに care_gaps 配列内に保存されます。標準の FHIR とは異なり、document model はこの情報を患者の臨床レコードとともに保存します。この構造の例を以下に示します。

{
   "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 は、オペレーション ビューを保持し、そのソース データへの直接リンクを維持します。

document model 内の暗号化されたフィールド

医療規制では、アプリケーションで 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のようなマイクロサービスは、フラグ、スレッショルド、ケアギャップフィールドを読み取りますが、暗号化されたデモグラフィックフィールドは読み取りません。