FHIR API を活用した EHR データと Salesforce Health Cloud の統合

執筆者：Salesforce 統合エンジニア

背景と応用シナリオ

現代の医療業界では、患者中心のケアモデルへの移行が加速しています。このモデルを実現するためには、電子カルテ (EHR - Electronic Health Record) 、検査システム、ウェアラブルデバイスなど、様々なソースから得られる患者データを一元的に管理し、包括的な患者像 (ペイシェント 360) を構築することが不可欠です。Salesforce Health Cloud は、このペイシェント 360 を実現するための強力なプラットフォームですが、その真価を発揮するには、基幹システムである EHR とのシームレスなデータ連携が鍵となります。

Salesforce 統合エンジニア (Salesforce Integration Engineer) としての我々の役割は、これらサイロ化されたシステム間の橋渡しをすることです。例えば、以下のようなシナリオが考えられます。

ケアコーディネーションの向上： 医師が EHR に新しい診断や処方箋を記録した際、その情報がリアルタイムで Health Cloud 上のケアプランに反映され、ケアコーディネーターや訪問看護師が即座にアクションを起こせるようにする。
患者エンゲージメントの強化： EHR から取得したアレルギー情報や過去の病歴に基づき、Health Cloud を介して患者にパーソナライズされた健康情報やリマインダーを自動送信する。
データドリブンな意思決定： 複数の EHR システムから集約した臨床データを Health Cloud 上で分析し、集団の健康状態の傾向を把握したり、特定のリスクを抱える患者群を特定したりする。

これらのシナリオを実現するためには、堅牢で標準化された統合アーキテクチャが必要です。ここで中心的な役割を果たすのが、医療情報交換の国際標準規格である FHIR (Fast Healthcare Interoperability Resources) (ファイア、医療情報交換の迅速化リソース) です。

原理説明

Salesforce Health Cloud と EHR の統合を理解するためには、Health Cloud のデータモデルと FHIR の役割を把握することが重要です。

Health Cloud の FHIR 準拠データモデル

Health Cloud は、単なる CRM ではありません。患者、医療従事者、保険情報などを管理するための標準オブジェクトに加え、臨床データを格納するために特別に設計されたデータモデルを備えています。このデータモデルは FHIR 標準に準拠しており、EHR からのデータ移行を容易にしています。

例えば、以下のような FHIR リソースに対応する Health Cloud オブジェクトが存在します。

Patient: 取引先 (Account) および取引先責任者 (Contact) オブジェクトにマッピングされ、患者の基本情報や人口統計情報を管理します。
Condition: 健康状態 (HealthCondition) オブジェクトに対応し、患者の診断名や病状を記録します。
MedicationRequest: 薬剤要求 (MedicationRequest) オブジェクトに対応し、処方された薬剤の情報を管理します。
Observation: 観察 (Observation) オブジェクトに対応し、バイタルサイン、検査結果などの測定値を記録します。

この FHIR との整合性により、統合エンジニアは EHR からエクスポートされた FHIR 形式のデータを、比較的少ない変換処理で Health Cloud に取り込むことが可能になります。

Clinical Service API (Connect API)

Health Cloud は、これらの FHIR 準拠オブジェクトを操作するために、Connect API と呼ばれる RESTful API 群を提供しています。統合エンジニアが主に使用するのは、その中の一つである Clinical Service API です。この API を使用することで、外部システムは標準的な HTTP メソッド (GET, POST, PATCH, DELETE) を用いて、Health Cloud 上の臨床データを安全かつ効率的に作成・更新・取得できます。

統合のプロセスは一般的に以下のようになります。

抽出 (Extract): EHR システムから、新規または更新された患者の臨床データを抽出します。多くの場合、データは FHIR バンドルや個別の FHIR リソース (JSON 形式)として出力されます。
変換 (Transform): 抽出した FHIR データを、Health Cloud の Clinical Service API が要求する形式に変換します。EHR 独自の拡張項目やコード体系が存在する場合、この段階で Salesforce 側で定義された値へのマッピングが必要になります。
読み込み (Load): 変換後の JSON ペイロードを HTTP リクエストのボディに含め、Clinical Service API の適切なエンドポイントに対して POST または PATCH リクエストを送信します。

このプロセスを自動化し、データの鮮度と一貫性を保つことが、統合エンジニアの重要な責務となります。

サンプルコード

ここでは、特定の患者に対して新しい診断情報 (Condition) を作成するシナリオを想定し、Clinical Service API を使用する REST API コールの例を示します。これは、EHR で新しい診断が下された際に、リアルタイムで Health Cloud に情報を連携するユースケースに相当します。

シナリオ： 患者 John Smith (Salesforce 内の ID: 001xx000003ABCDEAA) に、「2型糖尿病 (Type 2 diabetes mellitus)」という診断が追加された。

HTTP リクエスト：

POST /services/data/v58.0/connect/clinical/patient/001xx000003ABCDEAA/condition
Host: yourInstance.my.salesforce.com
Authorization: Bearer [YOUR_ACCESS_TOKEN]
Content-Type: application/json
Accept: application/json

{
  "resourceType": "Condition",
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active",
        "display": "Active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
        "code": "confirmed",
        "display": "Confirmed"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "encounter-diagnosis",
          "display": "Encounter Diagnosis"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "44054006",
        "display": "Type 2 diabetes mellitus"
      }
    ],
    "text": "Type 2 diabetes mellitus"
  },
  "subject": {
    "reference": "Patient/001xx000003ABCDEAA"
  },
  "onsetDateTime": "2023-01-15T10:30:00Z",
  "recordedDate": "2023-01-15T10:35:00Z"
}

コードの解説

エンドポイント: POST /services/data/v58.0/connect/clinical/patient/{patientId}/condition
{patientId} には、対象となる患者の Salesforce ID (この場合は取引先責任者 ID) を指定します。このエンドポイントは、指定された患者に新しい Condition レコードを作成することを示します。
ヘッダー:
Authorization: Bearer [YOUR_ACCESS_TOKEN] には、Salesforce への認証に必要な OAuth 2.0 アクセストークンを設定します。
Content-Type: application/json は、リクエストボディが JSON 形式であることを示します。
リクエストボディ (JSON ペイロード):
この JSON は FHIR R4 仕様に準拠した Condition リソースを表しています。
"resourceType": "Condition": 作成するリソースの種類を明示します。
"clinicalStatus": 臨床的な状態（例: active, recurrence, relapse, inactive, remission, resolved）を示します。
"verificationStatus": 診断の検証状態（例: unconfirmed, confirmed, refuted）を示します。
"code": 診断内容そのものをコードで表します。ここでは、医療標準コード体系の一つである SNOMED CT のコード 44054006 を使用して「2型糖尿病」を表現しています。標準化されたコード体系を使用することで、システム間の相互運用性が向上します。
"subject": この診断が誰のものであるかを指定します。reference には、Salesforce 内の患者レコードへの参照 (Patient/{Salesforce_ID}) を設定します。
"onsetDateTime": 症状が始まった日時を ISO 8601 形式で指定します。

このリクエストが成功すると、Health Cloud 内に新しい HealthCondition レコードが作成され、患者 John Smith のタイムラインやカルテにこの診断情報が反映されます。

注意事項

Health Cloud の統合を実装する際には、いくつかの重要な点に注意する必要があります。

権限 (Permissions): API を介してデータを操作するユーザーには、適切な権限が必要です。「Health Cloud Platform」権限セットライセンスと、「Health Cloud Foundation」権限セットが割り当てられていることを確認してください。また、HealthCondition や関連オブジェクトへの作成・参照・更新権限、および項目レベルセキュリティ (FLS) が正しく設定されている必要があります。

API 制限 (API Limits): Salesforce には、24時間あたりの API コール数や同時実行 API リクエスト数など、様々なガバナ制限があります。EHR から大量のデータを一度に同期する場合、これらの制限に抵触する可能性があります。特に初回のデータ移行（Initial Load）では、Bulk API 2.0 を使用して標準オブジェクトのデータをロードしたり、API コールをバッチ処理で分割実行したりするなどの戦略が求められます。Clinical Service API 自体は一度に1レコードの操作が基本となるため、大量処理にはミドルウェア側での流量制御 (Throttling) が不可欠です。

エラー処理 (Error Handling): ネットワークの問題やデータの不整合、権限不足など、API コールは様々な理由で失敗する可能性があります。統合ソリューションには、堅牢なエラーハンドリングと再試行（Retry）ロジックを実装することが不可欠です。API レスポンスの HTTP ステータスコード (例: 400 Bad Request, 403 Forbidden, 500 Internal Server Error) を適切に解釈し、エラー内容をログに記録して、問題の追跡と解決を容易にする必要があります。

HIPAA コンプライアンス: 扱うデータは保護対象保健情報 (PHI - Protected Health Information) です。統合の全過程において、データの暗号化（転送中および保存中）、アクセス制御、監査ログの取得など、HIPAA のセキュリティルールを遵守する必要があります。必要に応じて、Salesforce Shield を活用し、プラットフォーム暗号化やイベントモニタリングを強化することを検討してください。

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

Salesforce Health Cloud と EHR の統合は、患者中心のケアを実現するための技術的な基盤です。FHIR 標準と Health Cloud の Clinical Service API を活用することで、統合エンジニアはシステム間の壁を取り払い、リアルタイムで一貫性のある患者データを提供できます。

成功する統合プロジェクトのためのベストプラクティスを以下に示します。

べき等性 (Idempotency) の確保: API コールをべき等に設計し、ネットワーク障害などで同じリクエストが複数回送信された場合でも、重複したレコードが作成されないようにします。例えば、外部 ID を利用して、レコードが既に存在するかどうかを事前に確認するなどの工夫が有効です。
非同期処理パターンの採用: リアルタイム性が厳密に要求されないデータ（例：夜間のバッチ同期）については、非同期処理パターンを検討します。これにより、API 制限への到達リスクを低減し、システムの安定性を向上させることができます。
ミドルウェアの活用: MuleSoft Anypoint Platform のような統合プラットフォーム (iPaaS) を活用し、データ変換、プロトコル変換、エラー処理、モニタリングなどの複雑な処理をカプセル化します。これにより、Salesforce と EHR 間の疎結合なアーキテクチャを実現できます。
段階的な導入: 全ての臨床データを一度に統合するのではなく、まずは Patient や Condition といった重要なリソースから始め、段階的に対象を拡大していくアプローチ（フェーズドアプローチ）を取ります。これにより、リスクを管理し、早期に価値を提供することが可能になります。

統合エンジニアとして、我々は単にデータを移動させるだけではありません。技術的な障壁を取り除き、臨床データが適切なタイミングで適切な医療従事者の手に渡ることを保証することで、最終的には患者の健康アウトカムの向上に貢献しているのです。

にゃんこのSalesforce日記

このブログを検索