OAuth 2.0 認証

FHIR サーバを OAuth 2.0 リソース・サーバとして設定することにより、OAuth 2.0 承認サーバから取得した有効なアクセス・トークンがない限り、クライアントの FHIR 要求を拒否できるようになります。FHIR 要求のアクセス・トークンは 2 回チェックされます。REST ハンドラによって 1 回、FHIR サーバの内部サービスに到達したときにもう 1 回です。アクセス・トークンは要求が REST ハンドラに達したときに強制されるため、要求は、相互運用プロダクションに到達したときには (FHIR サーバがプロダクションを使用するように構成されている場合)、既に検証済みです。REST ハンドラとサービスは同じクラスを使用してトークンを検証します。これは、サーバの Interactions クラスの OAuth2TokenHandlerClass パラメータで指定されたクラスです。既定の FHIR サーバでは、このトークン処理クラスは HS.FHIRServer.Util.OAuth2TokenOpens in a new tab です。

FHIR サーバをリソース・サーバとして識別する最初の手順は、[システム管理]→[セキュリティ]→[OAuth 2.0]→[クライアント] を使用して、クライアント構成を作成することです。OAuth 2.0 承認サーバ用にサーバ・デスクリプションを作成したら、FHIR サーバに新しいクライアント構成を作成し、リソース・サーバ・タイプと指定します。インターシステムズ製品にリソース・サーバを設定する方法の詳細は、"OAuth 2.0 リソース・サーバとしての InterSystems IRIS Web アプリケーションの使用法" を参照してください。

FHIR サーバのクライアント構成を定義したら、以下の手順に従います。

管理ポータルで、[Health]→[FHIR 構成]→[サーバ構成] に移動します。FHIR サーバのネームスペースにいることを確認します。
FHIR サーバのエンドポイントを選択します。
[編集] を選択します。
[OAuth クライアント名] フィールドに、管理ポータルで定義したリソース・サーバのアプリケーション名を入力します。
[更新] を選択します。

アクセス・トークンのスコープ

Note:

read/write 構文がサポートされていますが、許可は SMART on FHIR v2 スタイルの構文を使用して指定することをお勧めします。詳細は、HL7 の仕様Opens in a new tabを参照してください。

このセクションでは、FHIR サーバが、要求と共に渡される OAuth 2.0 アクセス・トークンのスコープを適用する方法について説明します。FHIR サーバでスコープを別に解釈する必要がある場合は、FHIR サーバをカスタマイズし、OAuth2TokenHandlerClass パラメータをオーバーライドしてカスタム・トークン処理クラスを指定する必要があります。

アクセス・トークンには、以下のスコープを含めることができます。

Patient スコープは、承認を患者コンテキストのクレームで指定された患者に関連するリソースに限定します。このスコープは、患者が Web ポータルで自分のデータを確認する場合などに使用されます。
User スコープは、特定のユーザがアクセスを許可される FHIR リソース・タイプを表示または操作するためのアクセスを許可します。この種の承認は、実装固有の承認処理 (同意など) に従います。
System スコープは外部システムを表します。これらは、一括データ抽出など、システム間のやり取りを促進するために使用されます。

Note:

FHIR 相互作用が Patient または User スコープによって承認される場合、使用されている可能性のある追加の実装固有の処理 (同意など) に従う必要があります。この種の追加処理は、system スコープによって承認された相互作用には期待されません。

基本の処理

要求に付随するアクセス・トークンには、少なくとも 1 つのサーバ・スコープ、患者リソース・スコープまたはユーザ・リソース・スコープが含まれている必要があります。含まれていないと、要求は HTTP 403 エラーで拒否されます。複数のスコープがある場合は、スコープの集合が評価されます。例えば、user スコープと patient スコープの両方が存在する場合、いずれかのスコープが現在の FHIR 相互作用を承認するまで、あるいはいずれのスコープも承認しないことが確定するまで、すべてのスコープが評価される可能性があります。

患者リソース・スコープ/患者コンテキスト値

アクセス・トークンに患者リソース・スコープが含まれている場合は、Patient リソース ID である患者コンテキスト値 (“起動コンテキスト” とも呼ばれる) も含まれている必要があります。この患者コンテキスト値により、指定の Patient リソースや関連リソースへのアクセス権が付与されます。ほとんどの場合、患者リソース・スコープは、関連するリソースへの明示的なアクセス権を付与する必要があります。例えば、患者コンテキスト値が 1234 で、患者リソース・スコープが patient/Observation.cruds の場合、FHIR サーバは ID 1234 の患者を参照する Observation に対するアクセス権を付与できます。この場合、patient/Observation.cruds (または、Observations へのアクセス権を付与する別のスコープ) が必要になります。この要件の例外として、FHIR クライアントは、そのリソースに固有の患者リソース・スコープを取得せずに、複数の Patient 間で共有されるリソースにアクセスできます。例えば、スコープが patient/Patient.rs である場合、クライアントは、スコープ patient/Organization.rs を取得せずに、患者によって参照される Organization にアクセスできます。

アクセス・トークンから患者コンテキスト値を取得するには、FHIR サーバでアクセス・トークンの patient プロパティを調べます。

検索

FHIR サーバは、有効なアクセス・トークンを伴う検索要求を、以下の方法で処理します。

_include パラメータと _revinclude パラメータを使用できます。
FHIR サーバが患者コンテキスト値を適用する場合：
- 連鎖および逆連鎖された (_has) パラメータは、許可されます。
- 親のスコープで検索リソース・タイプを許可しておく必要があります。
- 検索リソース・タイプが Patient ではない場合、患者コンテキストにある Patient リソースを参照検索パラメータ値で指定する必要があります。
- _include パラメータと _revinclude パラメータが存在する場合は、スコープで許可されているリソースに、これらのパラメータで引き出し処理のみを指定する必要があります。
- Patient 検索では、あらゆる _id が患者コンテキスト値と一致している必要があります。
- 他のすべてのケースでは、検索を実行し、得られた結果セットにあるすべてのリソースがスコープとコンテキストで許可されていることを確認します。

Create 相互作用

新しい Patient リソースの作成要求には、書き込み権限を付与するユーザ・リソース・スコープ (user/Patient.cud または user/Patient.cruds) が含まれている必要があります。患者リソース・スコープを含む Patient リソースに .c 相互作用を実行することはできません。患者リソース・スコープには、患者コンテキスト値が含まれている必要があり、.c 相互作用には、リソース ID を含めることはできません。

$everything

Patient または Encounter の $everything オペレーションに対する要求には、その要求で返される可能性があるリソースすべてに対する読み取りアクセス権を持つアクセス・トークンが含まれている必要があります。リソースがスコープの範囲ではないコンパートメントで見つかった場合は、要求全体が HTTP 403 Forbidden エラーで拒否されます。

この要件は、現実的には以下のように適用されます。

_type オペレーション・クエリ・パラメータが指定されている場合、スコープに、要求されるリソース・タイプすべてに対する読み取りアクセスが含まれる必要があります。
タイプが指定されておらず、アクセス・トークンで患者リソース・スコープが使用されている場合、コンパートメントで見つかったリソースを返すには、patient/*.rs または patient/*.cruds のスコープが必要です。
タイプが指定されておらず、アクセス・トークンでユーザ･リソース・スコープが使用されている場合、コンパートメントで見つかったリソースを返すには、user/*.rs または user/*.cruds のスコープ必要です。

認証を使用しない場合

基本認証