セキュリティ

SMARTアプリ起動の解説：スコープ、起動コンテキスト、PKCE、患者向けフロー

SMARTアプリ起動は、ユーザーの許可を得て、あらゆるFHIRサーバーに対してアプリを実行できるHL7仕様です。発見、EHRおよびスタンドアロン起動、PKCEによる認可コードフロー、スコープ構文、起動コンテキスト、更新トークン、バックエンドサービス、そしてSMART v2での変更点について、実際の要求とともに解説します。

著 公開日 1分で読めます

短く言うと： SMART App Launch（SMART on FHIR）は、ユーザーの代わりにFHIRサーバーへのアプリの認証済みアクセスをどのように行うかについてのHL7の仕様です。これは、FHIR固有の規約を備えたOAuth 2.0およびOpenID Connectです。具体的には、.well-known/smart-configurationにあるディスカバリードキュメント、2つの起動モード（EHRが現在の患者のコンテキストでアプリを開くEHR起動と、ユーザーがアプリを開いて患者を選択するスタンドアロン起動）、FHIRを認識する構文のスコープ（patient/Observation.rsはコンテキスト内の患者のObservationの読み取りと検索を意味します）、起動コンテキスト（トークンと共に返される患者やエンカウンター）、および署名付きJWTクライアント認証を使用したシステム間アクセス用のバックエンドサービスです。SMART v2（2021年以降）では、PKCEが必須となり、詳細なスコープと非対称クライアント認証が追加され、国のプログラムが要求するバージョンとなっています。

ステップ1：ディスカバリー

SMARTアプリ起動のディスカバリーは、アプリがFHIRサーバーの.well-known/smart-configurationドキュメントを取得することから始まります。このドキュメントには、認可エンドポイントとトークンエンドポイント、サポートされている機能（EHR起動、スタンドアロン起動、公開クライアントおよび機密クライアント、OpenID Connect、患者およびユーザーの権限）、サポートされているスコープ、PKCEコードチャレンジメソッド、および付与タイプが記載されており、アプリはユーザーをどこに送信すればよいかを知ることができます。

GET https://fhir.example-hospital.org/.well-known/smart-configuration

{
  "issuer": "https://auth.example-hospital.org",
  "authorization_endpoint": "https://auth.example-hospital.org/authorize",
  "token_endpoint": "https://auth.example-hospital.org/token",
  "introspection_endpoint": "https://auth.example-hospital.org/introspect",
  "capabilities": ["launch-ehr", "launch-standalone", "client-public", "client-confidential-asymmetric", "sso-openid-connect", "context-ehr-patient", "context-standalone-patient", "permission-patient", "permission-user", "permission-v2", "permission-offline"],
  "scopes_supported": ["openid", "fhirUser", "launch", "launch/patient", "patient/*.rs", "user/*.rs", "offline_access"],
  "code_challenge_methods_supported": ["S256"],
  "grant_types_supported": ["authorization_code", "client_credentials"]
}

アプリは、ユーザーをどこに送信するか、サーバーが何をサポートしているかを学習します。

ステップ2：起動

SMARTアプリ起動には、2つの起動モードがあります。EHR起動では、臨床医がEHR内でアプリを開き、issパラメータ（FHIRサーバー）と現在の患者およびエンカウンターをエンコードした不透明な起動トークンが渡されます。スタンドアロン起動では、ユーザーがアプリを直接開き、認可サーバーが患者を選択または確認するように求めます。

EHR起動。 臨床医がEHR内でアプリをクリックすると、EHRはアプリの起動URLを2つのパラメータ付きで開きます：iss（FHIRサーバー）とlaunch（現在の患者とエンカウンターをエンコードした不透明なトークン）。アプリは、launchスコープで認可リクエストにlaunchをエコーする必要があります。

スタンドアロン起動。 ユーザーがアプリを直接開くと、アプリはFHIRサーバー（選択または設定済み）を知っており、launch/patientでコンテキストを要求します。認可サーバーは、ユーザーに患者を選択または確認するように求めます。

ステップ3：PKCEによる認可コード

SMARTの認可ステップは、PKCEを使用したOAuth 2.0認可コードフローです。アプリは、スコープ、FHIRサーバーのaud、およびコードチャレンジとともにユーザーを認可エンドポイントに送信します。ユーザーは認証して承認します。アプリは、返されたコードとコード検証子を交換して、起動コンテキストとともに到着するアクセストークンを取得します。

GET https://auth.example-hospital.org/authorize?
  response_type=code&client_id=my-app&redirect_uri=https://app.example.org/cb
  &scope=openid%20fhirUser%20launch%20patient/Observation.rs%20patient/Condition.rs%20offline_access
  &state=af0ifjsldkj&aud=https://fhir.example-hospital.org
  &launch=xyz123&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256

ユーザーは（病院のIDプロバイダーで）認証し、スコープを承認します。サーバーはcodeと共にリダイレクトバックします。アプリはそれを交換します：

POST https://auth.example-hospital.org/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=...&redirect_uri=https://app.example.org/cb&client_id=my-app&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

{
  "access_token": "eyJhbGciOi...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "openid fhirUser launch patient/Observation.rs patient/Condition.rs offline_access",
  "refresh_token": "a8c3...",
  "id_token": "eyJhbGciOi...",
  "patient": "Patient/123",
  "encounter": "Encounter/456",
  "fhirUser": "Practitioner/42",
  "need_patient_banner": true,
  "smart_style_url": "https://ehr.example.org/styles/smart.json"
}

起動コンテキスト（patient、encounter、fhirUser）はトークンと共に到着します。公開クライアント（モバイルおよびブラウザアプリ）はPKCEを使用し、クライアントシークレットは使用しません。機密クライアントは、シークレットで認証するか、好ましくは非対称メソッドの下で署名付きJWT（private_key_jwt）で認証します。

スコープ

SMART on FHIR v2のスコープは、context/resource.permissionsという構文を使用します。ここで、contextはpatient、user、またはsystemであり、permissionsは作成（c）、読み取り（r）、更新（u）、削除（d）、および検索（s）を組み合わせて使用します。例：patient/Observation.rs。詳細なスコープはフィルターを追加し、openidとfhirUserはユーザーのIDを提供し、起動スコープはコンテキストを要求し、offline_accessは更新トークンを要求します。

SMART v2構文：<context>/<resource>.<permissions>ここで、contextはpatient（コンテキスト内の患者）、user（ユーザーが見ることができるもの）、またはsystem（バックエンド）であり、permissionsはc作成、r読み取り、u更新、d削除、s検索のいずれかであり、その順序で指定されます：patient/Observation.rs、user/Patient.rs、system/*.cruds。詳細なスコープはフィルターを追加します：patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs。openid fhirUserはIDトークンとユーザーのFHIR IDを提供します。launch、launch/patient、launch/encounterはコンテキストを要求します。offline_accessはユーザーが離れているときに使用するための更新トークン、online_accessはセッション中のみ有効なトークンです。v1構文（patient/Observation.read）は、多くのサーバーでまだ受け入れられています。

バックエンドサービス

ユーザーなしで動作するシステム（夜間エクスポート、統合エンジン）の場合、SMART Backend Servicesは、署名付きJWTアサーション（クライアントの公開鍵がJWKS URLで公開されている）とsystem/スコープを使用したclient_credentialsを使用します。ユーザーなし、起動コンテキストなし、厳格な登録。

安全な実行

SMARTアプリ起動を安全に実行するには、正確なリダイレクトURIを登録し、暗黙的なフローを絶対に使用せず、更新トークンを安全に保存およびローテーションし、IDトークンのstateとaudを検証し、API呼び出しごとにトークンを検証し、データレイヤーでスコープと患者コンテキストの両方を強制して、ある患者のトークンが別の患者のデータを読み取らないようにし、すべてのアクセスをログに記録する必要があります。

正確なリダイレクトURIを登録してください。暗黙的なフローは絶対に使用しないでください。更新トークンは安全に保存し、ローテーションしてください。stateを検証してください。IDトークンのaudを確認してください。API呼び出しごとにトークンを検証してください（イントロスペクションまたはJWT検証）。データレイヤーでスコープと患者コンテキストを強制してください。なぜなら、Patient/123のトークンは決してPatient/124を読み取るべきではないからです。すべてのアクセスをログに記録してください（セキュリティとID：マップ）。SMARTは、アプリが接続できる組織をユーザーに示す方法であるPatient Access Brandsも定義しており、患者主導の共有のためのSMART Health Linksと相互運用します。

必須とされる場所

米国の患者アクセス規則では、認定されたEHRにSMART App LaunchとBackend Servicesのサポートが義務付けられています。ヨーロッパの国のプログラムでは、アプリアクセスにそれ（オランダのMedMijは同等の規約でOAuth 2.0を使用）を採用しています。IPSおよび多くの実装ガイドはそれを想定しています。TEFCAおよび国民の電子健康記録を参照してください。

Anpherosにて

Anpheros Platformは、アプリにはPKCEを使用したOAuth 2.0、バックエンドには署名付きJWTクライアント認証を使用しており、スコープは個人の同意から派生し、すべてのリクエストで患者コンテキストが強制されます。開発者サイトでは、それに基づいた構築のための認証とSMART on FHIRバックエンドパターンを文書化しています。

関連ページ

ソース

よくある質問

SMART on FHIRはOAuth 2.0と同じですか？

FHIR固有の追加機能（ディスカバリー、起動コンテキスト、スコープ構文、バックエンドサービス）を備えたOAuth 2.0およびOpenID Connectです。どのOAuthライブラリでも機能します。SMARTの規約が、アプリをFHIRサーバー間でポータブルにするものです。

サーバーサイドアプリにPKCEは必要ですか？

SMART v2では、認可コードフローを使用するすべてのクライアントに必要です。機密クライアントは、その上にクライアント認証（シークレットまたは署名付きJWT）を追加します。

patient/とuser/スコープの違いは何ですか？

patient/は起動コンテキスト内の単一の患者へのアクセスを制限します。user/は、認証されたユーザーが見ることができるものすべて（患者を問わず）を付与します。患者向けアプリはpatient/を使用し、臨床医向けアプリはコンテキストと共にuser/をよく使用します。

SMARTアプリはレコードに書き込めますか？

スコープで作成または更新の権限（c、u）が付与され、サーバーがそれを許可した場合です。多くのデプロイメントでは、患者向けアプリに読み取りと検索のみを許可し、QuestionnaireResponseなどの特定のソースを通じて書き込みをルーティングします。

Anpheros Platform

サンドボックスで無料で試す

5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。

無料のサンドボックスを作成サンプルアプリを起動 →スターターコード（Python） →Postman コレクション →開発者ガイドを読む →

無料・合成患者30人・カード不要

このガイドは情報提供のみを目的としており、医学的アドバイスに代わるものではありません。健康に関する決定については、医師にご相談ください。緊急時は、地域の緊急通報番号（ヨーロッパでは112）に電話してください。
作成者
Anpherosチーム

Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。

Anpherosについて →

主要用語

PKCESMART on FHIRFHIRHL7EHROpenID ConnectPatientSMART Health Links

すべての用語 →

次に読む

体と健康

ビタミンとミネラル：それぞれの働き、摂取源、そしてサプリメントが有効な場合

私たちの体は、エネルギー、血液、骨、ホルモンを作るために、13種類のビタミンと約15種類のミネラルを少量ずつ必要としています。主なビタミン・ミネラルの働き、最適な食品源、不足しやすい人（ビタミンD、B12、鉄分、葉酸、ヨウ素）、サプリメントが有効な場合、そして「摂りすぎは良くない」理由を分かりやすく解説します。

2026年10月28日あなたの体の仕組み

体温調節：体が37℃を保つ仕組み、汗や震えの役割、そして暑さや寒さが危険になる時

体の中心温度は、視床下部が代謝で発生する熱と、皮膚、汗、呼吸で失われる熱のバランスをとることで、約37℃の範囲に保たれています。体の冷やし方や温め方、発熱とは何か、体が数週間かけて暑さに適応する仕組み、熱疲労、熱中症、低体温症の兆候、そして猛暑の時に記録すべきことについて説明します。

2026年10月28日体と健康

睡眠と体内時計：体のリズムの仕組みとより良い睡眠をとる方法

体は約24時間周期のリズムで動いており、睡眠、ホルモン、体温を調整しています。体内時計の仕組み、成人に必要な睡眠時間、体内時計を乱す要因（光、シフトワーク、時差ぼけ）と、睡眠を助ける習慣について、無料の就寝時間計算ツールもご紹介します。

2026年10月28日

すべてのガイド →

アプリを探す

始める

デバイス

もっと見る

自宅でできる検査

無料ツール

始める

もっと見る

Platformを探す

SDKとコード

もっと見る

ガイドを読む

解説

もっと見る

研究

もっと見る