翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# FHIR リソースの削除
FHIR `delete`インタラクションは、HealthLake データストアから既存の FHIR リソースを削除します。詳細については、FHIR R4 RESTful API ドキュメント[https://hl7.org/fhir/R4/http.html#delete](https://hl7.org/fhir/R4/http.html#delete)の「」を参照してください。 ** R4 RESTful **
**FHIR リソースを削除するには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. 削除する FHIR のタイプを決定し`Resource`、関連する`id`値を収集します。詳細については、「[リソースタイプ:](reference-fhir-resource-types.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。FHIR `Resource`タイプと関連する も含めます`id`。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. リクエストを送信します。FHIR `delete`インタラクションは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可の`DELETE`リクエストを使用します。次の の`curl`例では、HealthLake データストアから既存の FHIR `Patient`リソースを削除します。例全体を表示するには、**コピー**ボタンをスクロールします。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request DELETE \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--aws-sigv4 'aws:amz:region:healthlake' \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
--header "x-amz-security-token:$AWS_SESSION_TOKEN" \
--header 'Accept: application/json'
```
サーバーは、リソースが HealthLake データストアから削除されたことを確認する `204` HTTP ステータスコードを返します。削除リクエストが失敗した場合、リクエストが失敗した理由を示す`400`一連の HTTP ステータスコードを受け取ります。
------
#### [ SMART on FHIR ]
[https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html) データ型の FHIR 認可の SMART の例。
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
発信者は認可 Lambda でアクセス許可を割り当てることができます。詳細については、「[OAuth 2.0 スコープ](reference-smart-on-fhir-oauth-scopes.md)」を参照してください。
------
#### [ AWS Console ]
1. HealthLake コンソールの[クエリの実行](https://console.aws.amazon.com/healthlake/home#/crud)ページにサインインします。
2. **クエリ設定**セクションで、次の選択を行います。
+ **データストア ID** — データストア ID を選択してクエリ文字列を生成します。
+ **クエリタイプ** — を選択します`Delete`。
+ **リソースタイプ** — 削除する FHIR [リソースタイプ](reference-fhir-resource-types.md)を選択します。
+ **リソース ID** — FHIR リソース ID を入力します。
3. **[Run query]** (クエリの実行) を選択します。
------
## 条件に基づく FHIR リソースの削除
条件付き削除は、特定の FHIR リソース ID がわからないが、削除するリソースに関するその他の識別情報がある場合に特に便利です。
条件付き削除を使用すると、論理 FHIR ID ではなく検索条件に基づいて既存のリソースを削除できます。サーバーが削除リクエストを処理すると、リソースタイプの標準検索機能を使用して検索を実行し、リクエストの単一の論理 ID を解決します。
### 条件付き削除の仕組み
**サーバーのアクションは、見つかった一致の数によって異なります。**
1. **一致なし**: サーバーは通常の削除を試みて適切に応答します (存在しないリソースの場合は 404 Not Found、既に削除されているリソースの場合は 204 No Content)
1. 1 **つの一致**: サーバーは一致するリソースに対して通常の削除を実行します
1. **複数の一致**: クライアントの基準が十分に選択されていないことを示す 412 Precondition Failed エラーを返します
### 対応シナリオ
AWS HealthLake は、以下のレスポンスパターンで条件付き削除オペレーションを処理します。
**正常なオペレーション**
+ 検索条件が 1 つのアクティブなリソースを正常に識別すると、システムは標準の削除オペレーションと同様に、削除の完了後に **204 No Content** を返します。
**ID ベースの条件付き削除**
追加のパラメータ (`createdAt`、`tag`、または `_lastUpdated`) `id`を使用して に基づいて条件付き削除を実行する場合:
+ **204 コンテンツ**なし: リソースは既に削除されています
+ **404 Not Found**: リソースが存在しません
+ **409 競合**: ID が一致するが、他のパラメータが一致しない
**Non-ID-Based条件付き削除**
が指定され`id`ていない場合、または `createdAt`、、`tag`または 以外のパラメータを使用する場合`_lastUpdated`:
+ **404 Not Found**: 一致が見つかりません
**競合状況**
いくつかのシナリオでは、412 Precondition Failed レスポンスが発生します。
+ 検索条件に一致するリソースが複数ある (基準が十分に具体的ではない)
+ で ETag ヘッダーを使用する場合のバージョン競合 `If-Match`
+ 検索オペレーションと削除オペレーションの間で発生するリソースの更新
**条件付き削除が成功した例**
次の の例では、特定の基準に基づいて患者リソースを削除します。
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
このリクエストは、次の場合に患者リソースを削除します。
+ 名前は「peter」です
+ 生年月日は 2000 年 1 月 1 日です
+ 電話番号は 1234567890 です
**ベストプラクティス**
1. 特定の検索条件を使用して、複数の一致を回避し、412 エラーを防止します。
1. 同時変更を処理するために必要な場合は、バージョン管理に ETag ヘッダーを検討してください。
1. エラーレスポンスを適切に処理します。
+ 404 の場合: 検索条件を絞り込む
+ 412 の場合: 条件をより具体的にするか、バージョン競合を解決する
1. 検索操作と削除操作の間でリソースが変更される可能性のある、同時実行性の高い環境でのタイミングの競合に備えます。