SMART on FHIR サポートによる Amazon HealthLake の相互運用性強化

この記事は、“Enhanced interoperability with SMART on FHIR support in Amazon HealthLake” を翻訳したものです。

はじめに

2021 年 7 月の開始以来、Amazon HealthLake は AWS Identity and Access Management (IAM) を通じて安全なアクセスを提供してきました。AWS は最近、SMART on FHIR 1.0.0 のサポートを含む新しい FHIR API 機能を Amazon HealthLake で発表しました。SMART on FHIR のサポートにより、HealthLake は FHIR スコープとローンチコンテキストを使用した SMART フレームワークに基づく認可を提供するようになりました。この記事では、Okta を ID プロバイダー (IdP) として使用して、HealthLake で SMART on FHIR を実装する方法について説明します。

患者と医療従事者に健康データへの安全なアクセスを提供するための革新的な取り組みを行う開発者は、さまざまな形式と標準のために複数の課題に直面しています。ONC Cures Act Final Rule は、医療業界に対し、開発者が医療従事者のワークフローをサポートする新しいアプリケーションを作成し、患者が自身の健康記録にアクセスできるようにする標準の採用を促しています。その標準の 1 つである SMART on FHIR は、開発者が 1 度アプリケーションを作成すれば、医療機関がさまざまな開発者のアプリケーションをテストし、適切なものを見つけられるようにするアーキテクチャ上の解決策を提案しています。「SMART」は Substitutable Medical Applications and Reusable Technologies を意味し、「on FHIR」は Fast Healthcare Interoperability Resources (FHIR) 標準の利用を示しています。

SMART フレームワークの概要

SMART アプリケーションを展開するためのフレームワークは、外部アプリケーションを電子健康記録 (EHR) システムに接続する上で重要な役割を果たします。このフレームワークにより、EHR システムの内外でアプリケーションを起動できるようになります。このフレームワークは、医師、患者、その他の個人やシステムが FHIR API を使用して設計されたさまざまなアプリケーションをサポートしています。ユーザーは、アプリケーションに自分の健康データへのアクセス権を付与できるため、アプリケーションがエンドユーザーデバイスやサーバー上で実行されているかどうかに関係なく、さまざまなアーキテクチャ構成で安全で信頼できるプロトコルが保証されます。SMART on FHIR 1.0.0 には、以下の 4 つのユースケースが含まれています。

独立して起動できるスタンドアロンの患者向けアプリケーション。
EHR ポータルから起動できる患者向けアプリケーション。
独立して起動できるスタンドアロンの医療従事者向けアプリケーション。
EHR ポータルから起動できる医療従事者向けアプリケーション。

SMART 認証と FHIR アクセス

次の図は、FHIR リソースサーバーとして HealthLake を利用する SMART on FHIR アプリケーションのスタンドアロンの起動とアクセス許可のステップを示しています。これらのステップとワークフローを詳しく見ていきましょう。

ステップ 1: アプリケーションが認証を要求します

SMART on FHIR クライアントアプリケーションは、FHIR リソースへのアクセスを認可するために、起動時に ID 情報なしで HTTP GET リクエストを FHIR サーバーの SMART 構成メタデータ [base]/.well-known/smart-configuration の検出 URL に送信します。この構成メタデータには、OAuth の authorization_endpoint と token_endpoint の URL が含まれています。その後、アプリケーションは、FHIR サーバーが「認可」に使用するエンドポイント URL のクエリコンポーネントに以下のパラメータを追加して、認可リクエストを作成します。

response_type: これは固定値です – code
client_id: クライアントの識別子です
redirect_uri: 登録済みクライアントが持つリダイレクト URI のいずれかと一致する必要があります
launch: EHR 起動フローを使用する場合、EHR から受け取った起動値と一致する必要があります。これはスタンドアロンの起動ワークフローでは必須ではないオプションのパラメータです
scope: アプリが必要とするアクセスを記述する必要があり、臨床、コンテキスト、ID データのスコープを含む必要があります

SMART アプリケーションの起動フレームワーク IG で説明されているように、データのスコープは次のように形成されます。

最も一般的に使用されるスコープの例は次のとおりです。

patient/*.read – 現在の患者に関連するリソースを読み取る権限
user/*.* – 現在のユーザーがアクセスできるすべてのリソースを読み書きする権限

他に一般的に使用される医療以外のスコープは以下の通りです。

launch – EHR から起動されたアプリのコンテキストを取得する権限
launch/patient – EHR 外からアプリが起動され、患者のコンテキストが必要な場合、認証サーバーから選択する患者のリストが提供される
offline_access – アクセストークンの有効期限が切れた後、オフラインの場合でも、期限切れのアクセストークンを更新するためのリフレッシュトークンを要求する
online_access – ユーザーがオンラインの場合に、期限切れのアクセストークンを更新するためのリフレッシュトークンを要求する

state : リクエストとコールバック間の状態を維持するために使用される不透明な値
aud : これは「対象者」を指し、アプリがデータを取得する FHIR リソースサーバーの URL です。

ステップ 2: 認可リクエストを評価する

認可プロセスは認可サーバーに依存し、サーバーはユーザーに許可を求めることができます。その後、サーバーはクライアント ID、設定されたポリシー、時にはユーザーの入力などの要因に基づいて、アクセスを許可するか拒否するかを決定します。アプリケーションは、認可サーバーから認可コードが送り返された場合、またはアクセスが拒否された場合はエラーレスポンスが送り返された場合に、この決定を受け取ります。

ステップ 3: 認可コードをアクセストークンと交換する

アプリケーションが認証コードを取得すると、そのコードをアクセストークンと交換する処理に進みます。この交換は、EHR 認証サーバーのトークン URL エンドポイントに対して HTTP POST リクエストを行うことで実現します。その際、コンテンツタイプとして application/x-www-form-urlencoded. を使用します。

ステップ 4: FHIR API を通じた医療データへのアクセス

アプリケーションが有効なアクセストークンを取得すると、FHIR サーバーのエンドポイントに FHIR API 呼び出しを行うことで、データを取得する機能を持ちます。API リクエストには、アクセストークンを “Bearer” トークンとして次の形式で含む認証ヘッダーが含まれています: Authorization: Bearer {{access_token}}. ここで、プレースホルダー {{access_token}} は、前のステップで取得した実際のトークン値に置き換えられます。

ステップ 5: リフレッシュトークン

アプリケーションはリフレッシュトークンを使用して新しいトークンを取得します。リフレッシュトークンは、アクセストークンの有効期間よりも長いセッションを許可するために発行されます。

Amazon HealthLake 上の SMART on FHIR の実装例

SMART on FHIR を定義する仕様と標準について説明したので、次は Okta を ID プロバイダー (IdP) として使用して HealthLake で実装する方法を示します。HealthLake では他の OAuth 2.0 IdP を使用することもできることに注意してください。

Amazon HealthLake での SMART アクセスの設定

ステップ 1: サードパーティの認可サーバーをセットアップし、’well-known’ 構成を取得する

認可サーバーは若干の違いがあるかもしれませんが、認可サーバーから ‘well-known’ 構成からベース URI と十分なメタデータを取得することが重要です。次の Okta のスクリーンショットは、Okta IDP のメタデータ URI を含むデフォルトの認可サーバー構成を示しています。

ID プロバイダーからのメタデータ情報には、認可エンドポイント、トークンエンドポイント、サポートされる付与タイプとスコープなどの詳細が含まれています。この情報は、次のセクションで強調されているように、SMART 機能を持つ HealthLake データストアを作成する際に使用されます。

ステップ 2: HealthLake と Auth Server 間の通信を確立する

SMART on FHIR サポートを備えた Amazon HealthLake データストアを作成する際は、特定のクレームを返す AWS Lambda 関数の ARN と、FHIR API リクエストを実行するための許可を持つ IAM サービスロールを指定する必要があります。Lambda 関数の作成の詳細については、Amazon HealthLake 開発者ガイドを参照してください。この Lambda 関数は、FHIR API リクエストに応答して、Amazon HealthLake サービスに必要な要素を返します。

次の図は、SMART on FHIR アプリケーション、IDP、Amazon HealthLake、Lambda 関数間の通信を示しています。

ステップ 3: HealthLake データストアの作成時に IdP 構成を保存する

HealthLake データストアの所有者が決定します

FHIR 相互作用に関連付けられた IAM ロール
復号化とトークン検証方法 (ローカル検証または ID プロバイダーとのトークン検査) と
ID プロバイダーの構成。検査 Lambda 関数を作成した後、ユーザーは IdentityProviderConfiguration を格納する機能が強化された create data store API を呼び出すことができます。このパラメータは、認可戦略、検出 API メタデータを構成し、細かい認可を有効にします。この構成は新しいデータストアを作成する際にのみ利用可能で、既存のデータストアでは有効にできないことに注意してください。さらに、この構成はコマンドラインインターフェイス (CLI) とソフトウェア開発キット (SDK) からのみアクセス可能で、コンソールからはアクセスできません。

この新しい CreateFHIRDatastoreRequest の構造では、新しいデータストアを作成する際に IdentityProviderConfiguration がオプションのパラメータとなっています。

この構成では、次のフィールドを受け入れます。

AuthorizationStrategy: SMART 認証の場合は SMART_on_FHIR_V1、非 SMART 認証の場合は AWSAuth を指定してください。値が SMART_on_FHIR_V1 の場合、以下のすべてのフィールドが必須になります。
FineGrainedAuthorizationEnabled: 細かい権限管理を HealthLake で行いたい場合は true、そうでない場合は false を選択してください。
Metadata – 検出 API リクエストコールを受信したときに返される認証サーバーのメタデータを格納します。SmartConfigurationMetadata は、FHIR 仕様に示されているものと同様の JSON オブジェクトで、authorization_endpoint と token_endpoint が含まれています。
IDPLambdaARN: トークン検証を行うカスタム Lambda の ARN です。

これらの設定を完了すると、HealthLake は SMART アプリケーションから送信された”Bearer” トークンをデコードできるようになり、それらのリクエストに対して認証と承認を実行できるようになります。

Amazon HealthLake の SMART on FHIR サポートの主要機能とメリット

適用性と柔軟性: ヘルスケアプロバイダーは、シームレスにサードパーティのアプリケーションを既存のシステムに統合できるようになります。これにより、臨床ワークフローのカスタマイズと拡張が可能になり、効率性と使いやすさが向上します。
患者中心のケア: HealthLake の SMART on FHIR サポートにより、患者は自身の健康データに安全にアクセスし、患者向けアプリケーションと対話できるようになります。これにより、患者の積極的な関与、エンパワーメント、健康状態の自己管理が促進されます。
相互運用性の向上: FHIR 標準データ形式を活用することで、SMART on FHIR は異なるシステム間で構造化された健康データを交換できるようになり、互換性と一貫性が確保されます。これにより、効率的なケアの調整、研究、集団健康管理が促進されます。
開発者に優しい環境: SMART オープンソースプラットフォームは、イノベーションを促進し、新しいヘルスケアソリューションの創出を奨励します。

結論

SMART on FHIR は、医療の相互運用性に変革をもたらすアプローチで、医療従事者、開発者、患者を同様に力づけます。アプリケーションをシームレスに統合し、ケアの調整を強化し、患者の関与を促進する機能により、SMART on FHIR は医療分野のデジタル変革を可能にする重要な要素となります。Amazon HealthLake がこの標準をサポートすることで、相互運用性、イノベーション、そして最終的には患者の良好なアウトカムを実現します。Amazon HealthLake を使い始め、健康データを数分で安全に保存、変換、トランザクション、分析する方法の詳細を知るには、以下の過去のブログをご覧ください。

Amazon HealthLake に関する過去のブログへのリンク

翻訳は Solutions Architect 窪田が担当しました。原文はこちらです。

Amazon Web Services ブログ