CMS コンプライアンス機能 - AWS HealthLake
CMS 相互運用性エンドポイントCMS コンプライアンスの CloudWatch メトリクスの強化

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CMS コンプライアンス機能

AWS HealthLake には、CMS (Centers for Medicare & Medicaid Services) の相互運用性とコンプライアンス要件を満たすのに役立つ機能が用意されています。これらの機能により、CMS カテゴリ別の API 使用状況を追跡し、コンプライアンス上の使用状況メトリクスをレポートできます。

CMS 相互運用性エンドポイント

概要:

HealthLake には、CMS が義務付ける API カテゴリに対応する 4 つの CMS 相互運用性エンドポイントが用意されています。HealthLake データストアの基盤となるベース URL は変更されません。これらのエンドポイントは、CMS レポート目的で API コールを分類および追跡する方法を提供するだけです。

目的

これらの相互運用性エンドポイントの主な目的は、お客様が以下を実行できるようにすることです。

  • CMS カテゴリ別に API トランザクションを簡単に追跡する

  • CMS コンプライアンスの使用状況メトリクスを自動的にレポートする

  • 最小限の変更で既存の FHIR ワークフローを維持する

すべての API コールは、相互運用性エンドポイントと標準 FHIR エンドポイントのどちらを使用する場合でも同じように機能します。唯一の違いは、トランザクションが CloudWatch メトリクスでどのように分類されるかです。

サポートされている CMS 相互運用性エンドポイント

CMS カテゴリ 相互運用性エンドポイント 使用例
患者アクセス /patientaccess/v2/r4 baseURL/patientaccess/v2/r4/Patient/123
プロバイダーアクセス /​provideraccess/v2/r4 baseURL/​provideraccess/v2/r4/Observation?patient=123
支払者から支払者へ /payertopayerdx/v2/r4 baseURL/payertopayerdx/v2/r4/Practitioner/456
以前の認証サービス /priorauthservice/v2/r4 baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789

相互運用性エンドポイントの仕組み

標準 HealthLake API コール:

baseURL/resourceType/[id]
baseURL/resourceType?[parameters]

CMS 相互運用性エンドポイントの場合:

baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]

相互運用性エンドポイントパスは、ベース URL とリソースタイプの間に挿入されます。相互運用性エンドポイントパスの後はすべて、現在の API コールとまったく同じままです。

使用例

例 1: 患者アクセス API

現在の API コール (引き続き機能):

curl -X GET \
  https://healthlake.us-east-1.amazonaws.com/datastore/abc123/r4/Patient/123 \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/fhir+json"

患者アクセス相互運用性エンドポイント (CMS 追跡用) の場合:

curl -X GET \
  https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123 \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/fhir+json"

キーポイント:

  • 基本 URL は残ります。 https://healthlake.us-east-1.amazonaws.com/datastore/abc123

  • 相互運用性エンドポイントが挿入されました。 /patientaccess/v2/r4

  • リソースパスが変更されていません。 /Patient/123

  • 両方の呼び出しが同一のレスポンスを返す

  • 相互運用性エンドポイント呼び出しは、CloudWatch URIType=patient-accessの で自動的に追跡されます。

  • POST、PUT、PATCH、DELETE オペレーションは同じように機能します。

  • リクエスト本文は変更されません。

エンドポイント翻訳リファレンス

相互運用性エンドポイント への翻訳 CMS カテゴリ
baseURL/patientaccess/v2/r4/Patient baseURL/r4/Patient 患者アクセス
baseURL/​provideraccess/v2/r4/Observation baseURL/r4/Observation プロバイダーアクセス
baseURL/payertopayerdx/v2/r4/Practitioner/456 baseURL/r4/Practitioner/456 Payer to Payer Data Exchange
baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 baseURL/r4/ExplanationOfBenefit?patient=789 事前認可

重要な注意事項

  • 機能的な違いなし: 相互運用性エンドポイントと標準 FHIR エンドポイントは、同一のレスポンスを返し、同一のオペレーションをサポートします

  • 基本 URL 変更なし: HealthLake データストアエンドポイントは変わりません

  • シンプルな統合: 基本 URL とリソースタイプの間に相互運用性エンドポイントパスを挿入する

  • 自動追跡: CloudWatch メトリクスは、使用される相互運用性エンドポイントによって呼び出しを自動的に分類します。

  • 下位互換性: 相互運用性エンドポイントのない既存の API コールは引き続き正常に動作します。

CMS コンプライアンスの CloudWatch メトリクスの強化

概要:

CMS 相互運用性エンドポイントを使用すると、HealthLake は CMS レポート要件をサポートする追加のディメンションを含む拡張 CloudWatch メトリクスを自動的に出力します。これらのメトリクスは、追加の設定を必要とせずに、発信者 ID、アプリケーション、および CMS 固有の URI タイプごとに API の使用状況を追跡します。

仕組み

相互運用性エンドポイントを使用して API コールを行う場合:

# This call...
curl https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123

# Automatically generates metrics with:
# - URIType: "patient-access"
# - Sub: extracted from your bearer token (SMART on FHIR datastores only)
# - ClientId: extracted from your bearer token (SMART on FHIR datastores only)
# - Plus all standard dimensions (DatastoreId, Operation, etc.)

追加のコードや設定は必要ありません。相互運用性エンドポイントを使用するだけで、拡張メトリクスが自動的にキャプチャされます。

注記

FHIR データストアの非 SMART の場合、URITypeディメンションは引き続きキャプチャされるため、CMS カテゴリ別に API の使用状況を追跡できます。Sub および ClientIdディメンションは、これらのクレームを含むベアラートークンで FHIR 認証で SMART を使用する場合にのみ使用できます。

新しいメトリクスディメンション

既存のディメンション (DatastoreId、DatastoreType、Operation) に加えて、相互運用性エンドポイントを使用すると、次のディメンションが自動的に追加されます。

ディメンション 説明 値の例 ソース
URIType CMS コンプライアンスカテゴリ patient-access, provider-access, payer-to-payer, prior-authorization 相互運用性エンドポイントパスから自動的に決定される
サブ 発信者 ID ユーザー/エンティティ識別子 ベアラートークンsubクレームから抽出
ClientId アプリケーション識別子 portal_app, ehr_system ベアラートークンclient_idクレームから抽出

使用可能なメトリクス

相互運用性エンドポイントを使用する場合、既存のすべての HealthLake メトリクスに追加のディメンションが含まれるようになりました。

  • CallCount - API コールの合計数

  • レイテンシー - ミリ秒単位の API 応答時間

  • UserErrors - 4xx クライアントエラーの数

  • SystemErrors - 5xx サーバーエラーの数

  • スロットリング - スロットリングされたリクエストの数

  • SuccessfulRequests - 成功した API コールの数

CloudWatch でのメトリクスのクエリ

CloudWatch Insights クエリの例

アプリケーションごとにすべての Patient Access API コールをクエリします。

SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
    AND URIType = 'patient-access'
GROUP BY ClientId