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

# べき等性と同時実行性
<a name="managing-fhir-resources-idempotency"></a>

## べき等性キー
<a name="idempotency-keys"></a>

AWS HealthLake は FHIR `POST`オペレーションのべき等性キーをサポートし、リソースの作成中にデータの整合性を確保するための堅牢なメカニズムを提供します。リクエストヘッダーに一意の UUID をべき等性キーとして含めることで、ヘルスケアアプリケーションは、ネットワークの不安定性や自動再試行を伴うシナリオでも、各 FHIR リソースが 1 回だけ作成されることを保証できます。

この機能は、重複する医療記録が重大な結果をもたらす可能性のある医療システムにとって特に重要です。以前のリクエストと同じべき等性キーを使用してリクエストを受信すると、HealthLake は重複を作成する代わりに元のリソースを返します。たとえば、再試行ループ中や冗長なリクエストパイプラインが原因で発生する可能性があります。べき等性キーを使用すると、HealthLake は断続的な接続問題を処理するクライアントアプリケーションにシームレスなエクスペリエンスを提供しながら、データの一貫性を維持できます。

### 実装
<a name="implementation"></a>

```
POST /<baseURL>/Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
    "resourceType": "Patient",
    "name": [...]
}
```

### レスポンスシナリオ
<a name="response-scenarios"></a>

最初のリクエスト (201 作成)  
+ 新しいリソースが正常に作成されました
+ レスポンスにはリソース ID が含まれます

リクエストの重複 (409 競合)  
+ 同じべき等性キーが検出されました
+ 元のリソースが返されました
+ 新しいリソースは作成されていません

無効なリクエスト (400 Bad Request)  
+ 不正な形式の UUID
+ 必須フィールドがありません

### ベストプラクティス
<a name="best-practices"></a>
+ 新しいリソースの作成ごとに一意の UUID を生成する
+ 再試行ロジックのべき等性キーを保存する
+ 一貫したキー形式を使用する: UUID v4 を推奨
+ リソース作成を処理するクライアントアプリケーションに を実装する

**注記**  
この機能は、厳密なデータ精度を必要とし、重複する医療記録を防ぐ医療システムにとって特に重要です。

## AWS HealthLake の ETag
<a name="healthlake-etag"></a>

AWS HealthLake は、FHIR リソースのオプティミスティック同時実行制御に ETags を使用し、同時変更を管理し、データ整合性を維持する信頼性の高いメカニズムを提供します。ETag は、リソースの特定のバージョンを表す一意の識別子であり、HTTP ヘッダーを介してバージョン管理システムとして機能します。リソースを読み取りまたは変更する場合、アプリケーションは ETags を使用して意図しない上書きを防止し、データの整合性を確保できます。特に、更新が同時に行われる可能性があるシナリオではそうです。

### 実装例
<a name="healthlake-etag-implementation"></a>

```
// Initial Read
GET /fhir/Patient/123
Response: 
ETag: W/"1"

// Update with If-Match
PUT /fhir/Patient/123
If-Match: W/"1"
{resource content}

// Create with If-None-Match
PUT /fhir/Patient/123
If-None-Match: *
{resource content}
// Succeeds only if resource doesn't exist
// Fails with 412 if resource exists
```

### レスポンスシナリオ
<a name="healthlake-etag-scenarios"></a>

正常なオペレーション (200 OK または 204 コンテンツなし)  
+ ETag が最新バージョンと一致する
+ オペレーションは意図したとおりに進行します

バージョン競合 (412 前提条件失敗)  
+ ETag が現在のバージョンと一致しません
+ データ損失を防ぐための更新が拒否されました

### ベストプラクティス
<a name="healthlake-etag-practices"></a>
+ すべての更新および削除オペレーションに ETagsを含める
+ バージョンの競合を処理するための再試行ロジックを実装する
+ If-None-Match を使用する: create-if-not-exists シナリオには \$1
+ 変更する前に必ず ETag の鮮度を確認する

この同時実行管理システムは、特に複数のユーザーまたはシステムが同じリソースにアクセスして変更する環境において、医療データの整合性を維持するために不可欠です。