翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CMS コンプライアンス機能
AWS HealthLake には、CMS (Centers for Medicare & Medicaid Services) の相互運用性とコンプライアンス要件を満たすのに役立つ機能が用意されています。これらの機能により、CMS カテゴリ別の API 使用状況を追跡し、コンプライアンス上の使用状況メトリクスをレポートできます。
**Topics**
+ [CMS 相互運用性エンドポイント](#cms-interoperability-endpoints)
+ [CMS コンプライアンスの CloudWatch メトリクスの強化](#cms-cloudwatch-metrics)
## 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 " \
-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 " \
-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\$1app, ehr\$1system | ベアラートークンclient\$1idクレームから抽出 |
### 使用可能なメトリクス
相互運用性エンドポイントを使用する場合、既存のすべての 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
```