mcpField
F
fasten-ehr-integration

fasten-ehr-integration

github.com/stanfordspezi開発2614 回インストール4 週間前に更新
リポジトリ

fasten-ehr-integration について

fasten-ehr-integrationは、Fasten Connectを介して患者の同意に基づくEHRデータをデジタルヘルスアプリに取り込む開発者向けスキルです。読み取り専用のFHIR連携を段階ごとに検証し、プライバシーとアーキテクチャの決定事項を記録します。

主な機能

  1. 01Fasten Connectの設定ガイド
  2. 02患者同意に基づくFHIR取り込み
  3. 03Webhook経由のエクスポート取得
  4. 04段階ごとの連携検証
  5. 05プライバシーと設計の概要書

活用シーン

  1. 01患者記録のヘルスアプリへの取り込み
  2. 02EHRサンドボックスでの連携テスト

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/stanfordspezi/spezivibe --skill fasten-ehr-integration

インストール後、Claude Code で/fasten-ehr-integrationを入力して読み込まれたか確認します。

詳細

Fasten EHR 統合

Fasten Connect を使って、アプリを実際の電子カルテ(EHR)データに接続する手順を、開発者アカウントの作成から、患者の FHIR レコードをアプリ独自のストレージにダウンロードする動作確認済みの統合の実現まで案内します。また、プライバシーとアーキテクチャに関する決定事項をまとめた簡潔な文書(docs/planning/ehr-connection-brief.md)も保存します。このアーキテクチャでは、最終的にユーザーのアプリに医療データが保存されるため、その管理責任はアプリ側にあります。プライバシーについての確認を済ませずに統合をリリースしないでください。

使用する場面

次のようなことをユーザーが希望する場合に、このスキルを使います。

  • 患者が自分の医療記録をデジタルヘルスアプリに取り込めるようにする
  • 医療システムごとの個別統合を行わずに、実際の FHIR データ(病状、薬、検査結果、文書)を取得する
  • 本番稼働前に、現実的な EHR サンドボックスを使ってプロトタイプを作成する

次の場合は、このスキルを使わないでください。

  • アプリから EHR にデータを書き込む必要がある、または臨床医が EHR 内からアプリを起動する場合。これは SMART on FHIR/ベンダーマーケットプレイスの領域です。
  • データソースがウェアラブル端末または HealthKit の場合。health-data-model-planning を使ってください。
  • 合成 FHIR データで十分な場合。Fasten はサンプルの EHI エクスポート(Epic サンドボックス、JSONL)を公開しています。また、Synthea や公開 SMART サンドボックスはアカウント不要で利用できます。

背景

Fasten Connect は、患者の同意に基づく医療記録アグリゲーターです。EHR ベンダーや医療システムごとに個別に統合する代わりに、アプリにウィジェットを埋め込み、患者自身がアクセスを許可します。

Patient ──logs into their own patient portal──▶ Provider EHR
   │                                                │
   ▼                                                ▼
Your app ◀──FHIR records (webhook + download)── Fasten Connect
  1. アプリに Fasten のStitch ウィジェットを埋め込みます。患者は医療システムを検索し、自分の患者ポータル(例:MyChart)にサインインします。認証情報は医療機関に送信され、アプリには送信されません。
  2. 認証済みの接続は org_connection_id として返され、バックエンドに保存されます。これが永続的な同意を示す識別子です。
  3. バックエンドは一括 EHI エクスポートをリクエストします。Fasten が記録を取得し、NDJSON/JSONL 形式の FHIR リソースとしてまとめます(1 行につき 1 リソース。主要な EHR 患者アクセス API では、実際には R4 が使われています)。
  4. Fasten はダウンロードリンクをウェブフックでバックエンドに通知し、バックエンドがファイルをダウンロードします。Fasten は 24 時間後に自社ストレージからエクスポートを削除するため、このフローではアプリのコピーが唯一のコピーになります。

これは消費者主導の情報交換です。患者は HIPAA に基づくアクセス権を行使し、記録をアプリに送信します。読み取り専用であり、EHR への書き戻しはありません。Fasten はポータルへのログインの代わりに本人確認(CLEAR/ID.me)を行う TEFCA 個人アクセスサービスの経路もサポートしています。API の仕様は同じです。

計画優先の初回実施

このスキルを計画中、つまりアプリがまだ存在しない段階で実行する場合(build-an-app オーケストレーターがこの方法を使用します)、ステップ 2~7 の検証ゲートはまだ実行できません。この場合は、回答可能な範囲でステップ 1 を進め、データプライバシーのセクションをすべて確認し、Current mode: not started と記載した出力用ブリーフを作成してください。開発者アカウントの作成とステップ 2~7 は、計画でこの統合用に設定した実装マイルストーンで後から行います。その時点でこのスキルに戻り、検証ゲートを含めて最後まで実施してください。

作業方法

あなたは統合を専門に案内するエキスパートです。段階ごとに進め、次へ進む前に、各段階が実際に動作することを確認してください。この統合の中核は非同期処理とウェブフック駆動の仕組みです。最後にまとめてデバッグするよりも、順を追って各接続を確認するほうがはるかに簡単です。最初から質問をまとめて投げかけないでください。意外な点があれば公式ドキュメントと照らし合わせてください。API の詳細は変わることがあり、このスキルよりもドキュメントを優先してください。


ステップ 1:アプリを理解する

プロジェクトから判断できないことを確認します。

  1. 「バックエンドのスタックは何ですか? また、パブリック HTTPS リクエストを受信できますか? それともローカルで開発していますか?」
  2. 「ダウンロードしたレコードはどこに保存しますか? ローカルディスク、データベース、クラウドバケットのいずれですか? また、誰がそれらを閲覧できる想定ですか?」
  3. 「まずはサンドボックスから始めますか? それとも、すでにライブモードを利用できますか?」
回答判断する内容
バックエンドのスタックと到達可能性すべての Fasten API 呼び出しと秘密鍵はサーバー側で処理します。Webhook の配信には、パブリック URL またはローカル開発用の代替手段が必要です(ステップ 5)
レコードの保存先「データプライバシー」セクションで説明するプライバシー対策(保存、暗号化、アクセス、削除)
テストかライブかテストキーでは約 24 のサンドボックス(FooClinic、Epic、Cerner、支払者のサンドボックス)に接続でき、ライブキーでは実際の医療機関に接続できます

必ずテストモードから始めてください。接続可能な医療機関が異なる点を除き、フローはライブモードと同じです。

次に進む前に確認してください: バックエンドと保存先を把握し、テストモードから始めることを確認します。


ステップ 2:開発者アカウントとキー

ユーザー自身に作業してもらってください。ユーザー本人のアカウントであり、認証情報を扱ってはいけません。

  1. Fasten Connect 開発者ポータルで登録します。
  2. テストモードのキーペア(パブリック ID(public_test_…)と秘密鍵(private_test_…))をコピーします。秘密鍵が表示されるのは一度だけなので、すぐに保存してください。
  3. ポータルではリダイレクト URLが必要です。これは、リンクが成功した後に Fasten がリダイレクトする URL であり、クエリパラメーターとして接続パラメーターも受け取ります。標準的な Stitch ポップアップ/モーダルフローでは、ウィジェットのイベントを通じて結果がページ内にも届くため、ほとんどのインテグレーションではイベントを処理します。そのため、ここにはアプリのベース URLを指定するのが適切です。(リダイレクトモードやモバイルのディープリンクフローでは、URL を直接使用します。アプリの構成に該当する場合は、ドキュメントを参照してください。)

次に、プロジェクトを設定します。

  • 両方のキーをサーバー側の環境設定(例:.env.local)に格納し、Git の追跡対象から除外します。値は引用符で囲んでください。秘密鍵にはシェルで特殊な意味を持つ文字が含まれることがあり、環境ファイルのパーサーや dotenv-expand によって値が改変される場合があります。
  • パブリック ID は公開を前提に設計されています(クライアント側のウィジェットに埋め込まれます)。秘密鍵をクライアントに渡してはいけません。NEXT_PUBLIC_/EXPO_PUBLIC_形式のプレフィックスを付けず、クライアントバンドルやモバイルアプリのバイナリにも含めないでください。

API 認証は https://api.connect.fastenhealth.com/v1 に対する HTTP Basic 認証です。ユーザー名にパブリック ID、パスワードに秘密鍵を指定します。テストとライブで同じベース URL を使用し、モードはキーによって決まります。

次に進む前に確認してください: 任意の認証済み GET リクエスト(例:ダミー ID を使用したエクスポートステータスエンドポイント)でキーをスモークテストします。401 が返る場合は、キーが間違っているか、改変されています。404または JSON エラーが返る場合は、認証に成功しています。このテストで、後の手順で表面化するはずだった引用符の指定ミスを事前に発見できます。


ステップ 3:Connect ウィジェットを埋め込む

患者が医療機関に接続する場所に、Stitch v4 ウィジェットを追加します。Web コンポーネント(任意のフレームワーク):

<link rel="stylesheet" href="https://cdn.fastenhealth.com/connect/v4/fasten-stitch-element.css">
<script type="module" src="https://cdn.fastenhealth.com/connect/v4/fasten-stitch-element.js"></script>

<fasten-stitch-element public-id="public_test_…">Connect a provider</fasten-stitch-element>

React SDK(@fastenhealth/fasten-stitch-element-react)と React Native のサポートもあります。Stitch v4 のドキュメントを参照してください。

要素の eventBus DOM イベントをリッスンします。ペイロードは event.detail.data にJSON 文字列として届くため、パースしてください。

document.querySelector('fasten-stitch-element')
  .addEventListener('eventBus', (event) => {
    const payload = JSON.parse(event.detail.data);
    if (payload.event_type === 'widget.complete') {
      // payload.data: [{ org_connection_id, platform_type, connection_status, … }]
      // POST it to YOUR backend and persist org_connection_id
    }
  });

すべての org_connection_id を、タイムスタンプおよび接続メタデータとともにサーバー側に保存します。これはエクスポート用の API ハンドルであると同時に、アプリの同意監査証跡の起点でもあります。(EHR から通知される場合は consent_expires_at を含む、より詳細な接続メタデータが patient.connection_success Webhook を通じて届きます。ステップ 5 を参照してください。)

次に進む前に確認してください: サンドボックスの医療機関に接続します。最初の実行には、ステップ 7 の表にある FooClinic と [email protected] / f00clinic を使うのが最も手早い方法です。org_connection_id がバックエンドのストレージに保存されることを確認してください。


ステップ 4:エクスポートをリクエストする

バックエンドからのみ実行します。

POST https://api.connect.fastenhealth.com/v1/bridge/fhir/ehi-export
Authorization: Basic base64(public_id:private_key)
Content-Type: application/json

{"org_connection_id": "…"}

レスポンスには task_id が含まれます。処理は非同期です(数秒から数分かかり、タスクがタイムアウトすることもあります。その場合は patient.ehi_export_failed webhook が届くため、上限を設けて再試行してください。failure_reason は省略されることが多いため、バックオフを挟んで少数回リクエストし、停止してユーザーまたは Fasten サポートに通知します)。

ユーザーに次の点を必ず伝えてください。

  • ダウンロードリンクは webhook 経由でのみ配信されます。 ステータスエンドポイント(GET /v1/bridge/fhir/ehi-export/{task_id})は、情報提供のために pending/success/failed を返しますが、リンクは返しません。また、Fasten のドキュメントではポーリングを明確に推奨していません。webhook エンドポイントが登録されていない場合、エクスポートを取得できません。
  • エンドポイントは org_connection_id ごとに冪等です。 再リクエストすると、既存のタスクが返されます。webhook の配信を受け取れなかった場合に利用できる、ドキュメントに記載された復旧手段は、Fasten による自動再試行(約 24 時間に最大 4 回)、ポータルの Delivery Logs(ペイロードは 15 日間閲覧可能)、テストモードの Webhook Simulator です。(実際には、再リクエストによって完了 webhook が再配信された事例が確認されていますが、この動作はドキュメントに記載されていないため、これを前提に実装しないでください。)
  • 実行順序に関する注意: 最初のエクスポートを行う前に webhook エンドポイントを登録してください(ステップ 5)。登録していないと、最初の完了通知はどこにも届きません。サンドボックスでは冪等な再リクエストで安全に復旧できます。

次に進む前に確認: task_id が記録されており、その task_id に対してステータスエンドポイントが pending または success を返すこと。


ステップ 5:Webhook を受信してダウンロードする

次のような Webhook エンドポイント(例:POST /api/webhooks/fasten)を実装します。

  1. 署名を検証します。 Fasten は Standard Webhooks の仕様に準拠しています。Standard Webhooks ライブラリと、ポータルで確認できるエンドポイントの署名シークレットを使って検証してください。これは、どちらのモードでも、すべての Webhook エンドポイントで必要となる基本的なセキュリティ対策です。注:シークレットはエンドポイントごと、モードごとに異なります。Fasten の FAQ では、テスト用とライブ用にそれぞれ異なる Webhook URL を用意し、各 URL に独自の署名シークレットを設定する必要があるとされています。
  2. 次のイベントを処理します(各ペイロードのエンベロープには api_mode、冪等性のための安定した id、type、data が含まれます)。
    • patient.ehi_export_success — data には task_id、org_connection_id、download_links[](url、export_type、content_type)、およびリソースタイプごとの件数を示す stats が含まれます。自動的に購読されます。
    • patient.ehi_export_failed — 実際のエラーに PHI が含まれる可能性があるため、failure_reason は多くの場合 suppressed_please_contact になります。自動的に購読されます。
    • patient.connection_success および patient.authorization_revoked — デフォルトでは有効になっていません。ポータルでエンドポイントの設定を切り替えて有効にしてください。失効イベントは一括で届く場合があります。
  3. すぐにダウンロードします。 各 download_links[].url に同じ Basic 認証を使ってアクセスします。API は署名付き URL へのリダイレクトを返します(有効期間は約 10 分です。新しい URL が必要な場合は再リクエストしてください)。リンクは Webhook の受信から 24 時間有効です。Fasten は 24 時間後にエクスポートを削除します。 Webhook の受信時点で、アプリがデータを引き受けたものとして扱ってください。エクスポートのサイズは、数 MB から、記録の多い場合は数 GB に及びます。メモリにバッファリングするのではなく、ストレージにストリーミングしてください。
  4. 速やかに 2xx を返し、重い処理は受信確認後に実行します。配信に失敗した場合は、同じイベント id で再試行されます。

ポータルの Webhook 設定でエンドポイント URL を登録します。

ローカル開発 — Webhook が開発者のマシンに届く必要があります。

方法手順備考
トンネル(推奨)cloudflared tunnel --url http://localhost:PORT(アカウント不要)または ngrok http PORT を実行し、https://<tunnel>/api/webhooks/fasten を登録しますすべて自動で行われます。Quick Tunnel の URL は再起動のたびに変わるため、ポータルを更新してください。また、新しいエンドポイントには新しい署名シークレットが割り当てられるため、環境変数も更新してください(既存のエンドポイントの URL をその場で編集すれば、シークレットは維持されます)。
手動で貼り付け到達不能な場合でもポータルにエンドポイント URL を登録します(配信は試行され、ログに記録されます)。その後、Webhooks → Delivery Logs から patient.ehi_export_success のペイロードをコピーし、同じダウンロード処理を実行するアプリ内の小さな取り込みエンドポイントに貼り付けますトンネルは不要です。サンドボックスでの開発には十分です。
ホスト型インボックス(smee.io、requestbin)Fasten の公式ドキュメントでは、一時的なテスト用としてこれらが提案されていますサンドボックス専用です。ライブの患者データを含む Webhook トラフィックを、サードパーティのインボックス経由でルーティングしないでください。

先に進む前に確認してください: ポータルの Webhook Simulator から webhook.test イベントを配信し、エンドポイントに届くことを確認します(シミュレーターのイベントは通常の配信経路を通るため、署名検証もテストされます)。手動で貼り付ける方法の場合は、コピーしたペイロードを取り込みエンドポイントに渡し、ファイルがストレージに保存されることを確認してください。その後、サンドボックスで実際のエクスポートを最初から最後まで実行します。


ステップ 6:解析して表示する

エクスポートファイルは NDJSON/JSONL 形式で、1 行につき 1 つの FHIR リソースが含まれています。実際のレコードには乱れがあるため、寛容に解析します。

  • ファイル全体の処理を失敗させるのではなく、不正な形式の行はスキップします。また、Bundle は安全にエントリーへ展開します。
  • resourceType ごとにグループ化します。一般的なエクスポートには、Patient、Condition、MedicationRequest、AllergyIntolerance、Observation(通常は大部分を占める検査値やバイタルサイン)、DiagnosticReport、Immunization、Procedure、Encounter、DocumentReference/Binary(PDF が多い)、参照データの Practitioner/Organization/Location が含まれます。
  • 名前、コード、日付は安全に描画します。.text を優先し、なければ coding[].display → code の順にフォールバックします。日付は effectiveDateTime、onsetDateTime、authoredOn、issued、period.start などに分散しています。
  • キーがまだなくても、Fasten のサンプルエクスポートの gist を使って、このレイヤー全体を構築し、テストできます。
  • アプリに正式なスキーマが必要な場合は、fhir-data-model-design を実行し、受信したリソースをその出力にマッピングします。

ステップ 7:エンドツーエンドでテストする

テストモードで利用できるサンドボックス(認証情報の完全な一覧はテスト患者の認証情報を参照):

サンドボックス認証情報適した用途
FooClinic(サンドボックス)— Fasten 独自のサンドボックス、16 のペルソナ[email protected] / f00clinic(11 個のリソース);[email protected] / f00clinic(3,500 件以上のリソースを含む腫瘍学記録)初回実行;データ量のテスト
Epic サンドボックスfhircamila / epicepic1Epic 形式の現実的なデータ
Cerner、athenahealth、支払者のサンドボックス(Aetna、Cigna、Medicare、VA)認証情報ガイドを参照プラットフォームの種類をまたいだ網羅的なテスト

完全なフローの検証 — 統合が完了する前に、すべての項目に合格する必要があります。

  • ウィジェットがサンドボックスのプロバイダーに接続し、org_connection_id がサーバー側に永続化されている
  • エクスポートをバックエンドからリクエストし、task_id を記録している
  • 署名を検証したうえで Webhook を受信し、ファイルをアプリのストレージにストリーミングしている
  • レコードを解析し、アプリの UI に表示している
  • patient.ehi_export_failed を処理している:ポータルの Webhook Simulator からハンドラーを実行する(またはエンドポイントに署名付きの合成ペイロードを送信する);上限付きの再試行経路がある
  • ポータルで patient.authorization_revoked を有効にし、アプリの同意ポリシーに従って処理している — 同じ方法でテストする(サンドボックスでの方法はシミュレーターであり、実際の取り消しは任意のタイミングで発生させられない)
  • クライアントバンドルとバージョン管理システムに秘密鍵が含まれていない

データプライバシー:医療データの保存先

この表を使って、ユーザーに明確に説明してください。イノベーターが見落とし、後悔するのはここです。これは製品に関するガイダンスであり、法的助言ではありません。本番環境へのリリース前に、弁護士、コンプライアンス担当者、または組織のプライバシーチームに確認するよう伝えてください。

ステージ健康データを保持する主体備考
ポータルへのログインプロバイダーのみ患者の認証情報はプロバイダー独自のポータルに入力します。このフローでは、アプリもFastenも認証情報を保存しません
取得とパッケージ化Fastenのクラウド(AWS。サブプロセッサーはtrust.fastenhealth.comに記載。すべて米国と表示)Fastenは、データは転送中および保存時に暗号化され、送信成功後24時間以内に一時コピーが自動削除されると説明しています
エクスポートの保存(Fasten)Fasten、24時間以内保持期間の終了後に削除されます。ダウンロードリンクもそれに伴い無効になります
Webhookペイロードアプリのバックエンド(および経路上のトンネルや受信トレイ)識別子、統計情報、ダウンロードリンクが含まれます。リンクの利用には引き続きAPIキーが必要ですが、ペイロードは機密情報として扱ってください。ライブモードではサードパーティの受信トレイは使用しません
ダウンロードアプリのバックエンドBasic認証+有効期間の短い署名付きURL(約10分)
アプリでの保存アプリチーム — 無期限これがアーキテクチャの要点です。アプリが記録を保持します。暗号化、アクセス制御、保持、削除、侵害への対応は、すべてアプリ側の責任になります

ライブモードの開始前に必ず決定する事項(ブリーフの「出力」セクションに記録してください):

  • ダウンロード時点で管理責任が移ります。 24 時間後、このフローで唯一残るコピーはアプリ側のコピーです。実際の記録を扱う前に、記録の保管場所、アクセスできる人、暗号化方法、患者が削除を依頼する方法を決めてください。
  • 規制上の扱いは、アプリの対象者によって異なります。 確認すべき分岐は 3 つです。
    • 消費者主導の場合: アクセス権とヘルスアプリに関する HHS OCR のガイダンスによると、対象事業体でも業務提携先でもないアプリに個人が提供を指示した記録は、HIPAA 規則の対象外になります。ただし、FTC Health Breach Notification Rule と州の医療プライバシー法(例:消費者向け医療記録アプリを医療提供者として扱うカリフォルニア州の CMIA、Washington My Health My Data)は適用される可能性が高く、FTC Act Section 5 はアプリが掲げるあらゆるプライバシー上の約束に適用されます。Fasten の資料では HBNR について扱っていません。この分析はアプリチーム独自のものです。
    • 対象事業体の代理として利用する場合: アプリは業務提携先となる可能性が高く、Fasten との契約も含め、BAA が必要です。Fasten のポリシーでは、一部のクライアントについて「業務提携先に該当する可能性がある」と記載されています。Fasten が BAA に署名するかどうかは公開情報に記載されていません。Fasten に直接問い合わせてください。
    • 研究目的で利用する場合: 記録を研究に使用するなら、ライブモードにする前に IRB に相談し、接続や同意のタイミングを研究参加のインフォームド・コンセントと調整してください。また、所属機関が対象事業体に該当するか、データガバナンス規則(データリスク分類、承認済みの保存環境など。大学医療センターでは一般的です)によって、保存要件やアクセス要件が変わるかどうかを確認してください。 全体の分析には digital-health-compliance-planning を実行してください。
  • ベンダーの主張は検証が必要です。 Fasten は自社を SOC 2 認証済みと説明し、マーケティングでは「SOC2 & HIPAA-compliant」と述べていますが、プライバシーポリシーでは自社を「HIPAA の直接の適用対象ではない」IAS プロバイダーとしています。SOC 2 レポートと HIPAA 評価書は、同社のトラストセンターで請求しないと入手できません。本格的に導入する場合は、これらの資料を請求してください。アプリ独自のプライバシー説明で、マーケティング上の主張をそのまま繰り返さないでください。
  • 同意は患者が管理し、有効期限があります。 接続メタデータには consent_expires_at が含まれる場合があります。Fasten のドキュメントによると、EHR が情報を報告する場合に限られます(2026 年 1 月に発効する HTI-2 の義務を挙げていますが、EHR の対応状況にはばらつきがあります)。患者は同意を撤回できます。撤回すると以後の取得は停止しますが、過去の開示が取り消されるわけではありません。すでにダウンロードしたデータについて、撤回後に現実的に選べる対応は、削除するか、アーカイブして利用を停止するかです(法的保全や監査の場合など)。開示の有無にかかわらず、撤回されたデータを引き続き製品で利用することは、以下の「以後の利用を停止する」義務に抵触する可能性が高いです。
  • Fasten の同意条件はアプリにも適用されます。 Fasten のプライバシーポリシーでは、CARIN Alliance Code of Conduct の署名者として、同社がすべての顧客に要件を「遵守させる」としています。その要件は、同意された用途に限った利用、簡単な同意撤回、AI/ML の利用と第三者への共有の開示です。Fasten Connect の登録時に、具体的にどの要件がアプリにも適用されるか確認してください。アプリのプライバシーポリシーと実際の動作は、それらの要件を満たす必要があります。
  • 秘密鍵がセキュリティ境界です。 秘密鍵はすべてのエクスポートとダウンロードを認証します。サーバー側だけで使用し、gitignore に追加し、漏えいした場合はローテーションし、環境ごとに別のキーペアを使用してください。
  • 保持するデータは最小限にしてください。 エクスポートには、多くの製品で必要とされる以上の情報が含まれます。特に自由記述のメモや Binary 文書が該当します。また、慎重な取り扱いが求められるカテゴリー(42 CFR Part 2 プログラムに由来する物質使用記録、生殖医療に関する情報、青少年の機密記録)が含まれる場合もあり、保持や将来の共有のリスクが高まります。取り込むかどうかを明確に決めてください。

出力

後続のスキル(例:app-build-planner、digital-health-compliance-planning)が利用できるよう、決定事項を docs/planning/ehr-connection-brief.md に保存してください。

# EHR Connection Brief: [App Name]

> Generated by `fasten-ehr-integration`. Save as `docs/planning/ehr-connection-brief.md`.
> Use this document as context for `app-build-planner`, `digital-health-compliance-planning`, or any follow-up implementation work.

## Architecture
- Backend / where the integration runs: [stack, hosting]
- Webhook endpoint & delivery strategy: [public URL / tunnel / manual]
- Record storage destination: [where, encrypted how, who has access]

## Mode & Scope
- Current mode: [not started / test / live] — prerequisites remaining: [list]
- Data ingested vs. discarded: [resource types kept, minimization decisions, sensitive-category handling]

## Privacy Decisions
- Regulatory posture: [likely / possible / unlikely for each: consumer-directed · business associate · research/IRB — rationale, counsel review status]
- Retention & deletion policy: [duration, patient deletion path]
- Revocation handling: [delete / archive-and-stop-using — rationale]
- Fasten attestations reviewed: [SOC 2 / HIPAA assessment / BAA status]

このアプリ固有の詳細を記入して、すべてのセクションを埋めてください。プレースホルダーのテキストを残さないでください。

ガードレール

  • 認証情報は絶対に扱わないでください。 ユーザー自身が開発者アカウントを作成します。患者はポータルの認証情報を医療機関が提供するログイン画面にのみ入力します。誰かに代わって認証情報を入力するよう求められた場合は、断り、キーボードを人間に渡してください。
  • 常にサンドボックスを優先してください。 テストモードでステップ 7 のチェックリストに合格するまで、ライブモードは使用しないでください。
  • Webhook は必須です。 ポーリングのみの連携ではエクスポートを取得できず、Fasten の利用ガイドラインにも違反します。
  • 法的な判断を確定事項として提示しないでください。 「必ず必要です」より「評価が必要になる可能性があります」を優先してください。HIPAA/BAA/HBNR/IRB に関する質問は、法律顧問および機関審査に回してください。
  • プライバシーのウォークスルーは必須です。 ユーザーが連携のみを求めている場合でも、データフローテーブルとブリーフを提示するまでは完了としないでください。

参考リンク

コメント