Salesforce Health Cloud：アーキテクトのための技術的詳細解説

日付:

背景と適用シナリオ

Salesforce Health Cloudは、医療機関、保険会社、製薬企業などが患者や会員との関係を管理し、よりパーソナライズされたケアを提供するために設計された、業界特化型のソリューションです。従来の電子カルテ（EHR - Electronic Health Record）が診療記録の保管を主目的とするのに対し、Health Cloudは患者中心（Patient-centric）のアプローチをとり、患者の全体像を360度で可視化することに重点を置いています。

主な適用シナリオとしては、以下のようなものが挙げられます。

ケアコーディネーション： 複数の専門医、看護師、ソーシャルワーカーなどが関わる複雑な治療計画（ケアプラン）を一元管理し、チーム全体で患者の進捗をリアルタイムに共有します。これにより、治療の重複や漏れを防ぎ、より効率的で質の高いケアを実現します。

患者エンゲージメント： 患者のプロファイル、コミュニケーション履歴、治療計画、さらにはウェアラブルデバイスからのデータを統合し、個々の患者に合わせた情報提供やリマインダーを自動化します。これにより、患者の治療への積極的な参加を促します。

慢性疾患管理： 糖尿病や高血圧などの慢性疾患を持つ患者に対して、標準化されたケアプログラム（Care Program）を適用し、継続的なモニタリングと介入を行います。

原理説明

Health Cloudの技術的な核心は、Salesforceプラットフォーム上に構築された特殊なデータモデルと、外部システムとの連携を容易にするための標準規格への準拠にあります。

Health Cloudデータモデル

Health Cloudは、標準のSalesforceオブジェクト（Account、Contactなど）を拡張し、医療特有の要件に対応するためのカスタムオブジェクト群を含む管理パッケージとして提供されます。このデータモデルは、患者だけでなく、その患者を取り巻く全ての関係者や情報を関連付けるように設計されています。

Person Account（個人取引先）: 患者や保険会員を表すために、標準で個人取引先モデルが利用されます。これにより、一人の人間をB2Cの顧客としてシンプルに管理できます。

Care Plan（ケアプラン）: 患者の治療目標、課題、タスクを管理する中心的なオブジェクトです。`CarePlan`, `CarePlanProblem`, `CarePlanGoal`, `CarePlanTask` といったオブジェクト群で構成され、複雑な治療計画を構造的に表現します。

Clinical Data Model: 患者の臨床データを格納するためのオブジェクト群です。例えば、`Condition`（病状）、`Medication`（薬剤）、`Observation`（観察結果）などがあり、これらは国際的な医療データ標準である FHIR (Fast Healthcare Interoperability Resources、高速ヘルスケア相互運用性リソース) の仕様に準拠、または整合性が高くなるように設計されています。

Care Team and Household: `CareTeamMember`（ケアチームメンバー）や`AccountContactRelation`（取引先-取引先責任者リレーション）などを活用し、主治医、専門医、家族、介護者といった患者のケアに関わる全ての関係者を「ケアチーム」として定義し、患者との関係性を可視化します。

EHRとの連携とFHIR

Health Cloudの価値を最大化するには、病院の基幹システムであるEHRとのデータ連携が不可欠です。この連携を円滑にするために、Health Cloudは医療情報交換の標準規格であるFHIRをサポートしています。

FHIRは、RESTful APIをベースとしたモダンなプロトコルであり、異なるシステム間でのデータ交換を容易にします。多くのEHRシステムはFHIRをサポートしており、MuleSoftなどの連携プラットフォームを介して、EHR内の患者の診断情報や処方歴などをHealth Cloudのデータモデルにマッピングし、同期することが一般的です。Salesforceは、この連携を支援するためのFHIR準拠のAPIを提供しており、セキュアなデータ連携を実現します。

示例代码

Health Cloudでは、APIを利用して外部システムから患者データを作成・更新するケースが頻繁にあります。ここでは、一人の患者（個人取引先）、その患者のケアプラン、そしてケアプランに含まれる問題を一度のAPIコールで作成する例として、Composite Graph API を使用します。このAPIは、複数の関連レコードを単一のトランザクションで作成・更新できるため、APIコール数を削減し、データの一貫性を保つのに非常に有効です。

以下のJSONペイロードは、`graph/vXX.X/composite` エンドポイントにPOSTするリクエストボディの例です。 

{
  "graphs": [
    {
      "graphId": "patientCarePlanGraph",
      "compositeRequest": [
        {
          "method": "POST",
          "url": "/services/data/v58.0/sobjects/Account",
          "referenceId": "newPatientAccount",
          "body": {
            "FirstName": "Satomi",
            "LastName": "Takahashi",
            "RecordTypeId": "012xx0000000001AAA"
          }
        },
        {
          "method": "POST",
          "url": "/services/data/v58.0/sobjects/CarePlan",
          "referenceId": "newCarePlan",
          "body": {
            "SubjectId": "@{newPatientAccount.id}",
            "Status": "Active",
            "StartDate": "2023-10-27T00:00:00.000Z",
            "Title": "糖尿病管理プログラム"
          }
        },
        {
          "method": "POST",
          "url": "/services/data/v58.0/sobjects/CarePlanProblem",
          "referenceId": "newCarePlanProblem",
          "body": {
            "CarePlanId": "@{newCarePlan.id}",
            "Name": "高血糖モニタリング"
          }
        }
      ]
    }
  ]
}

コード解説

このJSONは、3つの独立したリクエストを1つのグラフ（トランザクション）として定義しています。

1. `newPatientAccount` (患者の作成):

`Account` オブジェクトにPOSTリクエストを送信し、新しい患者を作成します。`referenceId` は、このトランザクション内でこのレコードを一意に識別するためのIDです。`RecordTypeId` には、個人取引先のレコードタイプIDを事前に取得して指定する必要があります。

2. `newCarePlan` (ケアプランの作成):

`CarePlan` オブジェクトにPOSTリクエストを送信します。`SubjectId` 項目には、`"@{newPatientAccount.id}"` という特殊な構文を使用しています。これは、同じトランザクション内で先に作成された `newPatientAccount` レコードのIDを参照することを意味します。これにより、作成されたケアプランが正しい患者に関連付けられます。

3. `newCarePlanProblem` (ケアプランの問題の作成):

`CarePlanProblem` オブジェクトにPOSTリクエストを送信します。同様に、`CarePlanId` 項目で `"@{newCarePlan.id}"` を使用し、直前に作成されたケアプランのIDを参照して関連付けを行っています。

このリクエストが成功すると、これら3つのレコードがすべて作成されます。もし、いずれか1つの作成に失敗した場合、トランザクション全体がロールバックされ、データが不整合な状態になるのを防ぎます。

注意事項

権限と共有設定

Health Cloudは、HIPAA (Health Insurance Portability and Accountability Act、医療保険の相互運用性と説明責任に関する法律) のような厳しいプライバシー規制に準拠する必要があります。そのため、権限設定には細心の注意が必要です。Health Cloudには `Health Cloud Foundation` や `Health Cloud Permission Set License` といった専用の権限セットが用意されており、これらを適切に割り当てる必要があります。また、患者データへのアクセスは、ケアチームのメンバーに限定するなど、厳格な共有ルールを定義することが不可欠です。機密性の高いデータ項目には、Shield Platform Encryption を利用した保存データの暗号化を検討すべきです。

API制限

EHRから大量の臨床データを同期する場合、Salesforceの標準的なガバナ制限（特にAPIコール数）に抵触する可能性があります。インテグレーションを設計する際は、Bulk APIや前述のComposite Graph APIを活用して、APIコール数を効率化することが重要です。また、リアルタイム同期とバッチ同期のどちらが適切か、ビジネス要件と技術的制約を考慮して判断する必要があります。

データ整合性

患者データは複数のシステム（EHR、CRM、保険請求システムなど）に分散していることが多く、重複や不整合が発生しやすいです。Health Cloudを導入する際は、患者IDの名寄せ（Master Data Management）戦略を立て、信頼できる唯一の情報源（Single Source of Truth）を確立することがプロジェクト成功の鍵となります。

まとめとベストプラクティス

Salesforce Health Cloudは、単なるCRMではなく、患者中心のケアを実現するための強力なプラットフォームです。その中心には、FHIR標準に整合した堅牢なデータモデルと、外部システムとの連携を前提としたアーキテクチャがあります。

Health Cloudを導入する上でのベストプラクティスは以下の通りです。

1. データモデルを深く理解する: カスタマイズを行う前に、まずHealth Cloudの標準オブジェクトとそのリレーションを十分に理解し、可能な限り標準機能を活用します。

2. 連携戦略を最優先に: EHRとの連携はプロジェクトの最重要課題です。FHIRやMuleSoftなどの標準技術とツールを活用し、スケーラブルで保守性の高い連携アーキテクチャを設計します。

3. セキュリティとコンプライアンスを設計に組み込む: 開発の初期段階から、HIPAA要件を満たすための権限設定、共有モデル、暗号化を考慮に入れます。

4. 標準コンポーネントを活用する: 患者タイムラインやケアチームビューなど、Health Cloudが提供する標準のLightning Web Componentsを最大限に活用し、開発を加速させます。

5. 大規模データへの備え: 将来的なデータ量の増加を見越して、パフォーマンスとガバナ制限を考慮した設計を行います。

これらの技術的な原理とベストプラクティスを理解することで、Salesforce Health Cloudのポテンシャルを最大限に引き出し、医療業界のデジタルトランスフォーメーションを成功に導くことができます。

コメント

コメントを投稿