翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# での FHIR リソースの管理 AWS HealthLake
FHIR R4 RESTful API インタラクションを使用して、HealthLake データストア内の FHIR リソースを管理します。以下のセクションでは、FHIR リソース管理で使用できる HealthLake がサポートするすべての FHIR R4 RESTful API インタラクションについて説明します。HealthLake データストアの機能およびサポートされる FHIR 仕様の部分については、「」を参照してください[の FHIR R4 機能ステートメント AWS HealthLake](reference-fhir-capability-statement.md)。
**注記**
この章に記載されている FHIR インタラクションは、医療データ交換のための HL7 FHIR R4 標準に準拠して構築されています。これらは HL7 FHIR サービスの表現であるため、 AWS CLI および AWS SDKsでは提供されません。詳細については、FHIR R4 [RESTful API](https://hl7.org/fhir/R4/http.html) ドキュメントの「RESTful API」を参照してください。 ** R4 RESTful **
次の表に、 でサポートされている FHIR R4 インタラクションを示します AWS HealthLake。HealthLake でサポートされている FHIR *リソースタイプ*については、「」を参照してください[リソースタイプ:](reference-fhir-resource-types.md)。
**でサポートされている FHIR R4 インタラクション AWS HealthLake**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/healthlake/latest/devguide/managing-fhir-resources.html)
**Topics**
+ [FHIR リソースの作成](managing-fhir-resources-create.md)
+ [FHIR リソースの読み取り](managing-fhir-resources-read.md)
+ [FHIR リソース履歴の読み取り](managing-fhir-resources-read-history.md)
+ [FHIR リソースの更新](managing-fhir-resources-update.md)
+ [PATCH オペレーションによるリソースの変更](managing-fhir-resources-patch.md)
+ [FHIR リソースのバンドル](managing-fhir-resources-bundle.md)
+ [FHIR リソースの削除](managing-fhir-resources-delete.md)
+ [べき等性と同時実行性](managing-fhir-resources-idempotency.md)
# FHIR リソースの作成
FHIR `create`インタラクションは、HealthLake データストアに新しい FHIR リソースを作成します。詳細については、FHIR R4 RESTful API ドキュメント[https://hl7.org/fhir/R4/http.html#create](https://hl7.org/fhir/R4/http.html#create)の「」を参照してください。 ** R4 RESTful **
**FHIR リソースを作成するには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. `Resource` 作成する FHIR のタイプを決定します。詳細については、「[リソースタイプ:](reference-fhir-resource-types.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。作成する FHIR `Resource`タイプも含めます。次の例の URL パス全体を表示するには、**コピー**ボタンにスクロールします。
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource
```
1. リクエストの JSON 本文を作成し、新しいリソースの FHIR データを指定します。この手順では、FHIR `Patient`リソースを使用しているため、ファイルを として保存します`create-patient.json`。
```
{
"resourceType": "Patient",
"identifier": [
{
"system": "urn:oid:1.2.36.146.595.217.0.1",
"value": "12345"
}
],
"name": [
{
"family": "Silva",
"given": [
"Ana",
"Carolina"
]
}
],
"gender": "female",
"birthDate": "1992-02-10"
}
```
1. リクエストを送信します。FHIR `create`インタラクションは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可の`POST`リクエストを使用します。次の例では、curl または HealthLake コンソールを使用して HealthLake に FHIR `Patient`リソースを作成します。例全体を表示するには、**コピー**ボタンをスクロールします。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient' \
--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' \
--data @create-patient.json
```
------
#### [ 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 ]
**注記**
HealthLake コンソールは [AWS SigV4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) 認可のみをサポートします。
1. HealthLake コンソールの[クエリの実行](https://console.aws.amazon.com/healthlake/home#/crud)ページにサインインします。
2. **クエリ設定**セクションで、次の選択を行います。
+ **データストア ID** — データストア ID を選択してクエリ文字列を生成します。
+ **クエリタイプ** — を選択します`Create`。
+ **リソースタイプ** — 作成する FHIR [リソースタイプ](reference-fhir-resource-types.md)を選択します。
+ **リクエスト本文** — リクエストの JSON 本文を作成し、新しいリソースの FHIR データを指定します。
3. **[Run query]** (クエリの実行) を選択します。
------
**リソース作成の検証レベルの設定**
FHIR リソースを作成するときに、オプションで HTTP `x-amzn-healthlake-fhir-validation-level` ヘッダーを指定して、リソースの検証レベルを設定できます。 AWS HealthLake は現在、次の検証レベルをサポートしています。
+ `strict`: リソースは、リソースのプロファイル要素、またはプロファイルが存在しない場合は R4 仕様に従って検証されます。これはデフォルトの検証レベルです AWS HealthLake。
+ `structure-only`: リソースは R4 に対して検証され、参照されるプロファイルは無視されます。
+ `minimal`: リソースは、特定の R4 ルールを無視して、最小限検証されます。検索/分析に必要な構造チェックに失敗したリソースは、監査の警告を含むように更新されます。
最小限の検証レベルで作成されたリソースは、検索インデックス作成に必要な検証に失敗しても、Datastore に取り込むことができます。この場合、リソースが更新されて Healthlake 固有の拡張機能が含まれ、その障害が記録されます。
```
{
"url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue",
"valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}"
}
```
さらに、次の HTTP レスポンスヘッダーが「true」の値に含まれます。
```
x-amzn-healthlake-validation-issues : true
```
**注記**
R4 仕様に従って不正な形式を取り込んだデータは、これらのエラーが存在する場合、期待どおりに検索できない場合があります。
# FHIR リソースの読み取り
FHIR `read`インタラクションは、HealthLake データストア内のリソースの現在の状態を読み取ります。詳細については、FHIR R4 RESTful API ドキュメント[https://hl7.org/fhir/R4/http.html#read](https://hl7.org/fhir/R4/http.html#read)の「」を参照してください。 ** R4 RESTful **
**FHIR リソースを読み取るには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. 関連する`id`値`Resource`を読み取って収集する FHIR のタイプを決定します。詳細については、「[リソースタイプ:](reference-fhir-resource-types.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。FHIR `Resource`タイプと関連する も含めます`id`。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. リクエストを送信します。FHIR `read`インタラクションは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可のいずれかの`GET`リクエストを使用します。次の の`curl`例では、HealthLake の FHIR `Patient`リソースの現在の状態を読み取ります。例全体を表示するには、**コピー**ボタンをスクロールします。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request GET \
'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'
```
------
#### [ 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 を選択してクエリ文字列を生成します。
+ **クエリタイプ** — を選択します`Read`。
+ **リソースタイプ** — 読み取る FHIR [リソースタイプ](reference-fhir-resource-types.md)を選択します。
+ **リソース ID** — FHIR リソース ID を入力します。
3. **[Run query]** (クエリの実行) を選択します。
------
# FHIR リソース履歴の読み取り
FHIR `history`インタラクションは、HealthLake データストア内の特定の FHIR リソースの履歴を取得します。このインタラクションを使用して、FHIR リソースの内容が時間の経過とともにどのように変化したかを判断できます。また、監査ログと連携して、変更前後のリソースの状態を確認するのにも役立ちます。FHIR インタラクション `create`、`update`、および `delete`では、リソースの履歴バージョンが保存されます。詳細については、FHIR R4 RESTful API ドキュメント[https://hl7.org/fhir/R4/http.html#history](https://hl7.org/fhir/R4/http.html#history)の「」を参照してください。 ** R4 RESTful **
**注記**
特定の FHIR リソースタイプ`history`に対して をオプトアウトできます。オプトアウトするには、 を使用してケースを作成します[AWS Support Center Console](https://console.aws.amazon.com/support/home#/)。ケースを作成するには、 にログイン AWS アカウント し、**ケースの作成**を選択します。
**FHIR リソース履歴を読み取るには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. 関連する`id`値`Resource`を読み取って収集する FHIR のタイプを決定します。詳細については、「[リソースタイプ:](reference-fhir-resource-types.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。また、FHIR `Resource`タイプ、関連付けられた `id`、およびオプションの検索パラメータを含めます。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history{?[parameters]}
```
**HealthLake が FHIR `history`インタラクションでサポートする検索パラメータ**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/healthlake/latest/devguide/managing-fhir-resources-read-history.html)
1. リクエストを送信します。FHIR `history`インタラクションは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可の`GET`リクエストを使用します。次の`curl`例では、 `_count`検索パラメータを使用して、HealthLake の FHIR `Patient`リソースの 1 ページあたり 100 件の履歴検索結果を返します。例全体を表示するには、**コピー**ボタンをスクロールします。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient/id/_history?_count=100' \
--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'
```
------
#### [ 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)」を参照してください。
------
`history` インタラクションの戻りコンテンツは FHIR リソース に含まれ`Bundle`、タイプは に設定されます`history`。これには、指定されたバージョン履歴が含まれ、最後に最も古いバージョンでソートされ、削除されたリソースが含まれます。詳細については、**FHIR R4 ドキュメント**[https://hl7.org/fhir/R4/bundle.html](https://hl7.org/fhir/R4/bundle.html)の「」を参照してください。
## バージョン固有の FHIR リソース履歴の読み取り
FHIR `vread`インタラクションは、HealthLake データストア内のリソースのバージョン固有の読み取りを実行します。このインタラクションを使用すると、FHIR リソースのコンテンツは、過去の特定の時点と同じように表示できます。
**注記**
*なしで* FHIR `history`インタラクションを使用する場合`vread`、HealthLake は常にリソースのメタデータの最新バージョンを返します。
HealthLake は、サポートされている各リソースの でのバージョニングのサポート[https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning](https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning)を宣言します。すべての HealthLake データストアには、すべてのリソースに `Resource.meta.versionId` (`vid`) が含まれます。
FHIR `history`インタラクションが有効になっている場合 (10/25/2024 以降に作成されたデータストアの場合はデフォルトで、古いデータストアの場合はリクエストによって）、`Bundle`レスポンス`vid`には [https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location](https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location)要素の一部として が含まれます。次の例では、 は数値 として`vid`表示されます`1`。完全な例を表示するには、[「バンドル/バンドルレスポンス (JSON) の例](https://build.fhir.org/bundle-response.json.html)」を参照してください。
```
"response" : {
"status" : "201 Created",
"location" : "Patient/12423/_history/1",
...}
```
**バージョン固有の FHIR リソース履歴を読み取るには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. 関連する と`id``vid`値を読み取って収集する FHIR `Resource`タイプを決定します。詳細については、「[リソースタイプ:](reference-fhir-resource-types.md)」を参照してください。
1. HealthLake と FHIR 用に収集された値を使用して、リクエストの URL を作成します。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history/vid
```
1. リクエストを送信します。FHIR `history`インタラクションは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可のいずれかの`GET`リクエストを使用します。次の`vread`インタラクションは、 で指定された`Patient`リソースメタデータのバージョンについて、FHIR リソースに指定されたコンテンツを含む単一のインスタンスを返します`vid`。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient/id/_history/vid' \
--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'
```
------
#### [ 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)」を参照してください。
------
# FHIR リソースの更新
FHIR `update`インタラクションは、既存のリソースの新しい最新バージョンを作成するか、特定の にリソースがまだ存在しない場合は初期バージョンを作成します`id`。詳細については、FHIR R4 RESTful API ドキュメント[https://hl7.org/fhir/R4/http.html#update](https://hl7.org/fhir/R4/http.html#update)の「」を参照してください。 ** R4 RESTful **
**FHIR リソースを更新するには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. 更新`Resource`する FHIR のタイプを決定し、関連する`id`値を収集します。詳細については、「[リソースタイプ:](reference-fhir-resource-types.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。また、FHIR `Resource`タイプとそれに関連する を含めます`id`。次の例の URL パス全体を表示するには、**コピー**ボタンにスクロールします。
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. リクエストの`JSON`本文を作成し、実行する FHIR データの更新を指定します。この手順では、ファイルを として保存します`update-patient.json`。
```
{
"id": "2de04858-ba65-44c1-8af1-f2fe69a977d9",
"resourceType": "Patient",
"active": true,
"name": [
{
"use": "official",
"family": "Doe",
"given": [
"Jane"
]
},
{
"use": "usual",
"given": [
"Jane"
]
}
],
"gender": "female",
"birthDate": "1985-12-31"
}
```
1. リクエストを送信します。FHIR `update`インタラクションは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可の`PUT`リクエストを使用します。次の の`curl`例では、HealthLake の`Patient`リソースを更新します。例全体を表示するには、**コピー**ボタンをスクロールします。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request PUT \
'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' \
--data @update-patient.json
```
リクエストは、既存のリソース*が更新され*た場合は `200` HTTP ステータスコード、新しいリソースが作成された場合は `201` 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 を選択してクエリ文字列を生成します。
+ **クエリタイプ** — を選択します`Update (PUT)`。
+ **リソースタイプ** — 更新または作成する FHIR [リソースタイプ](reference-fhir-resource-types.md)を選択します。
+ **リクエスト本文** — リクエストの JSON 本文を作成し、リソースを更新する FHIR データを指定します。
3. **[Run query]** (クエリの実行) を選択します。
------
## 条件に基づく FHIR リソースの更新
条件付き更新では、論理 FHIR ではなく、一部の識別検索条件に基づいて既存のリソースを更新できます`id`。サーバーが更新を処理すると、`id`リクエストの単一の論理を解決するために、リソースタイプの標準検索機能を使用して検索が実行されます。
サーバーが実行するアクションは、見つかった一致の数によって異なります。
+ **一致なし、リクエスト本文に`id`指定なし**: サーバーは FHIR リソースを作成します。
+ **一致する`id`ものがなく、リソースが にまだ存在しない`id`**場合: サーバーはインタラクションをアップデートとして処理し、インタラクションを作成します。
+ **一致なし、`id`指定済み、既に存在**: サーバーは`409 Conflict`エラーで更新を拒否します。
+ **One Match, no resource `id` provided OR (resource `id` provided and it match the found resource)**: サーバーは上記のように、一致するリソースに対して更新を実行します。リソースが更新された場合、サーバーは を返します`200 OK`。
+ 1 **つの一致。リソース`id`が指定されていますが、リソースと一致しません**: サーバーは、クライアント ID の仕様が で問題である可能性を示す`409 Conflict`エラーを返します。 `OperationOutcome`
+ **複数の一致**: サーバーは、クライアントの基準が OperationOutcome で十分に選択されていないことを示す`412 Precondition Failed`エラーを返します。
次の例では、名前が peter、生年月日が 2000 年 1 月 1 日、電話番号が 1234567890 の`Patient`リソースを更新します。
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
## リソース更新の検証レベルの設定
FHIR リソースを更新する場合、オプションで HTTP `x-amzn-healthlake-fhir-validation-level` ヘッダーを指定して、リソースの検証レベルを設定できます。 AWS HealthLake は現在、次の検証レベルをサポートしています。
+ `strict`: リソースは、リソースのプロファイル要素、またはプロファイルが存在しない場合は R4 仕様に従って検証されます。これはデフォルトの検証レベルです AWS HealthLake。
+ `structure-only`: リソースは R4 に対して検証され、参照されるプロファイルは無視されます。
+ `minimal`: リソースは、特定の R4 ルールを無視して、最小限検証されます。検索/分析に必要な構造チェックに失敗したリソースは、監査の警告を含むように更新されます。
最小限の検証レベルで更新されたリソースは、検索インデックス作成に必要な検証に失敗しても、Datastore に取り込まれる可能性があります。この場合、リソースが更新されて Healthlake 固有の拡張機能が含まれ、その障害が記録されます。
```
{
"url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue",
"valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}"
}
```
さらに、次の HTTP レスポンスヘッダーは「true」の値に含まれます。
```
x-amzn-healthlake-validation-issues : true
```
**注記**
これらのエラーが存在する場合、R4 仕様に従って誤った形式で取り込まれたデータは期待どおりに検索できない可能性があることに注意してください。
# PATCH オペレーションによるリソースの変更
AWS HealthLake は FHIR リソースの PATCH オペレーションをサポートしているため、リソース全体を更新することなく、特定の要素をターゲットにして追加、置換、または削除することで、リソースを変更できます。このオペレーションは、以下が必要な場合に特に役立ちます。
+ 大規模なリソースをターゲットに更新する
+ ネットワーク帯域幅の使用量を減らす
+ 特定のリソース要素に対してアトミック変更を実行する
+ 同時変更を上書きするリスクを最小限に抑える
+ バッチワークフローとトランザクションワークフローの一部としてリソースを更新する
## サポートされているパッチ形式
AWS HealthLake は 2 つの標準 PATCH 形式をサポートしています。
### JSON パッチ (RFC 6902)
JSON ポインタ構文を使用して、リソース構造内の要素の位置で要素をターゲットにします。
**Content-Type:** `application/json-patch+json`
### FHIRPath パッチ (FHIR R4 仕様)
FHIRPath 式を使用して、コンテンツと関係によって要素をターゲットにし、パッチ適用に対する FHIR ネイティブアプローチを提供します。
**Content-Type:** `application/fhir+json`
## 使用方法
### Direct PATCH オペレーション
PATCH オペレーションは、PATCH HTTP メソッドを使用して FHIR リソースで直接呼び出すことができます。
```
PATCH [base]/[resource-type]/[id]{?_format=[mime-type]}
```
### バンドル内のパッチ
パッチオペレーションは、タイプ `batch`または の FHIR バンドル内のエントリとして含めることができるため`transaction`、1 つのリクエストでパッチオペレーションを他の FHIR インタラクション (作成、読み取り、更新、削除) と組み合わせることができます。
+ **トランザクションバンドル**: すべてのエントリがアトミックに成功または失敗する
+ **バッチバンドル**: 各エントリは個別に処理されます
## JSON パッチ形式
### サポートされているオペレーション
| 運用 | 説明 |
| --- | --- |
| add | リソースに新しい値を追加する |
| remove | リソースから値を削除する |
| replace | リソース内の既存の値を置き換える |
| move | ある場所から値を削除し、別の場所に追加する |
| copy | ある場所から別の場所に値をコピーする |
| test | ターゲットロケーションの値が指定された値と等しいことをテストする |
### パス構文
JSON パッチは JSON ポインタ構文 (RFC 6901) を使用します。
| パスの例 | 説明 |
| --- | --- |
| /name/0/family | 名前のファミリー要素 |
| /telecom/- | テレコム配列に追加 |
| /active | ルートレベルのアクティブ要素 |
| /address/0/line/1 | 最初のアドレスの 2 行目 |
### 例
**複数のオペレーションによる直接 JSON パッチリクエスト**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
If-Match: W/"1"
[
{
"op": "replace",
"path": "/name/0/family",
"value": "Smith"
},
{
"op": "add",
"path": "/telecom/-",
"value": {
"system": "phone",
"value": "555-555-5555",
"use": "home"
}
},
{
"op": "remove",
"path": "/address/0"
},
{
"op": "move",
"from": "/name/0/family",
"path": "/name/1/family"
},
{
"op": "test",
"path": "/gender",
"value": "male"
},
{
"op": "copy",
"from": "/name/0",
"path": "/name/1"
}
]
```
**単一のオペレーションによる直接 JSON パッチリクエスト**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
[
{
"op": "replace",
"path": "/active",
"value": false
}
]
```
**バンドルの JSON パッチ**
base64 でエンコードされた JSON パッチペイロードを含むバイナリリソースを使用します。
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Binary",
"contentType": "application/json-patch+json",
"data": "W3sib3AiOiJhZGQiLCJwYXRoIjoiL2JpcnRoRGF0ZSIsInZhbHVlIjoiMTk5MC0wMS0wMSJ9XQ=="
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## FHIRPath パッチ形式
### サポートされているオペレーション
| 運用 | 説明 |
| --- | --- |
| add | リソースに新しい要素を追加する |
| insert | リスト内の特定の位置に要素を挿入する |
| delete | リソースから 要素を削除する |
| replace | 既存の要素の値を置き換える |
| move | リスト内の要素の順序を変更する |
### パス構文
FHIRPath Patch は、以下をサポートする FHIRPath 式を使用します。
+ **インデックスベースのアクセス**: `Patient.name[0]`
+ **を使用したフィルタリング`where()`**: `Patient.name.where(use = 'official')`
+ **ブールロジック**: `Patient.telecom.where(system = 'phone' and use = 'work')`
+ **サブセット関数**: `first()`、 `last()`
+ **存在チェック**: `exists()`、 `count()`
+ **多形ナビゲーション**: `Observation.value`
### 例
**Direct FHIRPath パッチリクエスト**
```
PATCH [base]/Patient/123
Content-Type: application/fhir+json
Authorization: ...
{
"resourceType": "Parameters",
"parameter": [{
"name": "operation",
"part": [
{ "name": "type", "valueCode": "add" },
{ "name": "path", "valueString": "Patient" },
{ "name": "name", "valueString": "birthDate" },
{ "name": "value", "valueDate": "1990-01-01" }
]
}]
}
```
**バンドルの FHIRPath パッチ**
Parameters リソースを のエントリリソースとして使用します`method: PATCH`。
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Parameters",
"parameter": [{
"name": "operation",
"part": [
{ "name": "type", "valueCode": "add" },
{ "name": "path", "valueString": "Patient" },
{ "name": "name", "valueString": "birthDate" },
{ "name": "value", "valueDate": "1990-01-01" }
]
}]
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## リクエストヘッダー
| ヘッダー | 必要 | 説明 |
| --- | --- | --- |
| Content-Type | はい | application/json-patch\$1json for JSON パッチまたは application/fhir\$1json for FHIRPath パッチ |
| If-Match | いいえ | ETag を使用したバージョン固有の条件付き更新 |
## レスポンス例
オペレーションは、更新されたリソースに新しいバージョン情報を返します。
```
HTTP/1.1 200 OK
Content-Type: application/fhir+json
ETag: W/"2"
Last-Modified: Mon, 05 May 2025 10:10:10 GMT
{
"resourceType": "Patient",
"id": "example",
"active": true,
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"telecom": [
{
"system": "phone",
"value": "555-555-5555",
"use": "home"
}
],
"meta": {
"versionId": "2",
"lastUpdated": "2025-05-05T10:10:10Z"
}
}
```
## 行動
PATCH オペレーション:
+ 適切な仕様に従ってパッチ構文を検証します (JSON パッチの場合は RFC 6902、FHIRPath パッチの場合は FHIR R4)
+ オペレーションをアトミックに適用 - すべてのオペレーションが成功または失敗する
+ リソースバージョン ID を更新し、新しい履歴エントリを作成します。
+ 変更を適用する前に、元のリソースを履歴に保持します
+ パッチを適用した後、FHIR リソースの制約を検証します
+ ETag で If-Match ヘッダーを使用した条件付き更新をサポート
## エラー処理
オペレーションは、次のエラー条件を処理します。
+ **400 不正なリクエスト**: 無効なパッチ構文 (非準拠のリクエストまたは不正な形式のパッチドキュメント)
+ **404 Not Found**: リソースが見つかりません (指定された ID は存在しません)
+ **409 競合**: バージョン競合 (同時更新または以前のバージョン ID の提供)
+ **422 未処理のエンティティ**: パッチオペレーションを指定されたリソース要素に適用できません
## 機能の概要
| 機能 | JSON パッチ | FHIRPath パッチ |
| --- | --- | --- |
| コンテンツタイプ | application/json-patch\$1json | application/fhir\$1json |
| パス形式 | JSON ポインタ (RFC 6901) | FHIRPath 式 |
| Direct PATCH API | サポート対象 | サポート |
| バンドルバッチ | サポートされている (バイナリ経由) | サポートされている (パラメータ経由) |
| バンドルトランザクション | サポートされている (バイナリ経由) | サポートされている (パラメータ経由) |
| オペレーション | 追加、削除、置換、移動、コピー、テスト | 追加、挿入、削除、置換、移動 |
## 制限事項
+ 検索条件を使用した条件付き PATCH オペレーションはサポートされていません
+ バンドル内の JSON パッチは、base64 でエンコードされたコンテンツを含むバイナリリソースを使用する必要があります
+ バンドルの FHIRPath パッチは Parameters リソースを使用する必要があります
## その他のリソース
PATCH オペレーションの詳細については、以下を参照してください。
+ [FHIR R4 パッチドキュメント](https://hl7.org/fhir/http.html#patch)
+ [FHIR R4 FHIRPath パッチ仕様](https://hl7.org/fhir/fhirpatch.html)
+ [RFC 6902 - JSON パッチ](https://datatracker.ietf.org/doc/html/rfc6902#section-4)
+ [RFC 6901 - JSON ポインタ](https://datatracker.ietf.org/doc/html/rfc6901)
# FHIR リソースのバンドル
FHIR `Bundle`は、 の FHIR リソースのコレクション用のコンテナです AWS HealthLake。 は、処理動作が異なる 2 種類のバンドル AWS HealthLake をサポートしています。
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction) バンドルは、各リソースを個別に処理します。1 つのリソースが失敗しても、残りのリソースは成功します。各オペレーションは個別に処理され、一部のオペレーションが失敗しても処理が続行されます。複数の無関係な患者レコードのアップロードなど、部分的な成功が許容される一括操作にはバッチバンドルを使用します。
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction) バンドルは、すべてのリソースを 1 つのユニットとしてアトミックに処理します。すべてのリソースオペレーションが成功するか、コミット AWS HealthLake されません。すべてのデータを一緒に記録する必要がある、関連する観察結果と条件を持つ患者を作成するなど、関連するリソース全体で参照整合性が保証されている必要がある場合は、トランザクションバンドルを使用します。
**バッチバンドルとトランザクションバンドルの違い**
| 機能 | バッチ | トランザクション |
| --- | --- | --- |
| 処理モデル | 各オペレーションは個別に成功または失敗します。 | すべてのオペレーションは 1 つのアトミックユニットとして成功または失敗します。 |
| 障害処理 | 個々のオペレーションが失敗しても処理は続行されます。 | 1 回のオペレーションが失敗すると、バンドル全体が失敗します。 |
| 実行順序 | 実行順序は保証されません。 | オペレーションは指定された順序で処理されます。 |
| 参照整合性 | オペレーション間では適用されません。 | バンドル内のローカルに参照されるリソースに対して強制されます。 |
| 最適なケース | 部分的な成功が許容される一括オペレーション。 | 一緒に作成または更新する必要がある関連リソース。 |
同じタイプまたは異なるタイプの FHIR リソースをバンドルでき、、、、`update`、 `delete`などの FHIR `create` `read`オペレーションの組み合わせを含めることができます`patch`。詳細については、**FHIR R4 ドキュメント**の[「リソースバンドル](https://hl7.org/fhir/R4/Bundle)」を参照してください。
各バンドルタイプのユースケースの例を次に示します。
バッチバンドル
+ 夜間のデータ同期中に、異なる施設から複数の無関係な患者レコードをアップロードします。
+ 一部のレコードに検証の問題がある可能性のある過去の薬剤レコードを一括アップロードします。
+ 個々の障害が他のエントリに影響を与えない組織や実務者などのリファレンスデータをロードします。
トランザクションバンドル
+ すべてのデータを一緒に記録する必要がある緊急部門への入院中に、関連する観察結果と状態を持つ患者を作成します。
+ 一貫性を保つ必要がある患者の薬剤リストおよび関連するアレルギー情報を更新します。
+ 患者、観察結果、処置、請求情報との完全な遭遇を単一のアトミックユニットとして記録します。
**重要**
バッチバンドルとトランザクションバンドルの両方が同じ`Bundle`リソース構造を使用します。唯一の違いは、 `type`フィールドの値です。
次の例は、複数のリソースタイプとオペレーションを持つトランザクションバンドルを示しています。
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"fullUrl": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065",
"resource": {
"resourceType": "Patient",
"id": "new-patient",
"active": true,
"name": [
{
"family": "Johnson",
"given": [
"Sarah"
]
}
],
"gender": "female",
"birthDate": "1985-08-12",
"telecom": [
{
"system": "phone",
"value": "555-123-4567",
"use": "home"
}
]
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"fullUrl": "urn:uuid:7f83f473-d8cc-4a8d-86d3-9d9876a3248b",
"resource": {
"resourceType": "Observation",
"id": "blood-pressure",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel"
}
],
"text": "Blood pressure panel"
},
"subject": {
"reference": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065"
},
"effectiveDateTime": "2023-10-15T09:30:00Z",
"component": [
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8480-6",
"display": "Systolic blood pressure"
}
]
},
"valueQuantity": {
"value": 120,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
},
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8462-4",
"display": "Diastolic blood pressure"
}
]
},
"valueQuantity": {
"value": 80,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
}
]
},
"request": {
"method": "POST",
"url": "Observation"
}
},
{
"resource": {
"resourceType": "Appointment",
"id": "appointment-123",
"status": "booked",
"description": "Annual physical examination",
"start": "2023-11-15T09:00:00Z",
"end": "2023-11-15T09:30:00Z",
"participant": [
{
"actor": {
"reference": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065"
},
"status": "accepted"
}
]
},
"request": {
"method": "PUT",
"url": "Appointment/appointment-123"
}
},
{
"request": {
"method": "DELETE",
"url": "MedicationRequest/med-request-456"
}
}
]
}
```
## FHIR リソースを独立したエンティティとしてバンドルする
**FHIR リソースを独立したエンティティとしてバンドルするには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。URL に FHIR リソースタイプを指定*しないでください*。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. 各 HTTP 動詞を `method`要素の一部として指定して、リクエストの JSON 本文を作成します。次の例では、 `Bundle`リソースと`batch`のタイプインタラクションを使用して、新しい リソース`Patient`と `Medication`リソースを作成します。必要なセクションはすべて、それに応じてコメントされます。この手順では、ファイルを として保存します`batch-independent.json`。
```
{
"resourceType": "Bundle",
"id": "bundle-batch",
"meta": {
"lastUpdated": "2014-08-18T01:43:30Z"
},
"type": "batch",
"entry": [
{
"resource": {
"resourceType": "Patient",
"meta": {
"lastUpdated": "2022-06-03T17:53:36.724Z"
},
"text": {
"status": "generated",
"div": "Some narrative"
},
"active": true,
"name": [
{
"use": "official",
"family": "Jackson",
"given": [
"Mateo",
"James"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"resource": {
"resourceType": "Medication",
"id": "med0310",
"contained": [
{
"resourceType": "Substance",
"id": "sub03",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "55452001",
"display": "Oxycodone (substance)"
}
]
}
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "430127000",
"display": "Oral Form Oxycodone (product)"
}
]
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "385055001",
"display": "Tablet dose form (qualifier value)"
}
]
},
"ingredient": [
{
"itemReference": {
"reference": "#sub03"
},
"strength": {
"numerator": {
"value": 5,
"system": "http://unitsofmeasure.org",
"code": "mg"
},
"denominator": {
"value": 1,
"system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
"code": "TAB"
}
}
}
]
},
"request": {
"method": "POST",
"url": "Medication"
}
}
]
}
```
1. リクエストを送信します。FHIR `Bundle`バッチタイプは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可の`POST`リクエストを使用します。次のコード例では、デモンストレーションの目的で `curl` コマンドラインツールを使用しています。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/' \
--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' \
--data @batch-type.json
```
------
#### [ 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)」を参照してください。
------
サーバーは、`Bundle`バッチタイプリクエストの結果として作成された `Patient`および `Medication`リソースを示すレスポンスを返します。
## バンドルPUTs
AWS HealthLake は、次のクエリパラメータを使用してバンドル内の条件付き更新をサポートします。
+ `_id` (スタンドアロン)
+ `_id` を次のいずれかと組み合わせて使用します。
+ `_tag`
+ `_createdAt`
+ `_lastUpdated`
バンドルで条件付き PUTs を使用する場合、 は既存のリソースに対してクエリパラメータ AWS HealthLake を評価し、一致結果に基づいてアクションを実行します。
**条件付き更新動作**
| シナリオ | HTTP ステータス | 実行されたアクション |
| --- | --- | --- |
| ID が指定されていないリソース | 201 作成 | 常に新しいリソースを作成します。 |
| 新しい ID を持つリソース (一致なし) | 201 作成 | 指定された ID で新しいリソースを作成します。 |
| 既存の ID を持つリソース (単一一致) | 200 OK | 一致するリソースを更新します。 |
| 既存の ID を持つリソース (競合が検出されました) | 409 Conflict | エラーを返します。変更は行われません。 |
| 既存の ID を持つリソース (ID の不一致) | 400 Bad Request | エラーを返します。変更は行われません。 |
| 複数のリソースの一致条件 | 412 Precondition Failed | エラーを返します。変更は行われません。 |
次の条件付き更新のバンドル例では、FHIR ID を持つ`Patient`リソース`_lastUpdated=lt2025-04-20`は、条件が満たされた場合にのみ`476`更新されます。
```
{
"resourceType": "Bundle",
"id": "bundle-batch",
"meta": {
"lastUpdated": "2014-08-18T01:43:30Z"
},
"type": "batch",
"entry": [
{
"resource": {
"resourceType": "Patient",
"id": "476",
"meta": {
"lastUpdated": "2022-06-03T17:53:36.724Z"
},
"active": true,
"name": [
{
"use": "official",
"family": "Jackson",
"given": [
"Mateo",
"James"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
},
"request": {
"method": "PUT",
"url": "Patient?_id=476&_lastUpdated=lt2025-04-20"
}
},
{
"resource": {
"resourceType": "Medication",
"id": "med0310",
"contained": [
{
"resourceType": "Substance",
"id": "sub03",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "55452001",
"display": "Oxycodone (substance)"
}
]
}
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "430127000",
"display": "Oral Form Oxycodone (product)"
}
]
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "385055001",
"display": "Tablet dose form (qualifier value)"
}
]
},
"ingredient": [
{
"itemReference": {
"reference": "#sub03"
},
"strength": {
"numerator": {
"value": 5,
"system": "http://unitsofmeasure.org",
"code": "mg"
},
"denominator": {
"value": 1,
"system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
"code": "TAB"
}
}
}
]
},
"request": {
"method": "POST",
"url": "Medication"
}
}
]
}
```
## FHIR リソースを単一のエンティティとしてバンドルする
**FHIR リソースを単一のエンティティとしてバンドルするには**
1. HealthLake `region`と `datastoreId`の値を収集します。詳細については、「[データストアのプロパティの取得](managing-data-stores-describe.md)」を参照してください。
1. HealthLake `region`と の収集された値を使用して、リクエストの URL を作成します`datastoreId`。URL `Bundle`の一部として FHIR リソースタイプを含めます。次の例の URL パス全体を表示するには、**コピー**ボタンをスクロールします。
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle
```
1. リクエストの JSON 本文を作成し、グループ化する FHIR リソースを指定します。次の例では、HealthLake で 2 つの`Patient`リソースをグループ化します。この手順では、ファイルを として保存します`batch-single.json`。
```
{
"resourceType": "Bundle",
"id": "bundle-minimal",
"language": "en-US",
"identifier": {
"system": "urn:oid:1.2.3.4.5",
"value": "28b95815-76ce-457b-b7ae-a972e527db4f"
},
"type": "document",
"timestamp": "2020-12-11T14:30:00+01:00",
"entry": [
{
"fullUrl": "urn:uuid:f40b07e3-37e8-48c3-bf1c-ae70fe12dabf",
"resource": {
"resourceType": "Composition",
"id": "f40b07e3-37e8-48c3-bf1c-ae70fe12dabf",
"status": "final",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "60591-5",
"display": "Patient summary Document"
}
]
},
"date": "2020-12-11T14:30:00+01:00",
"author": [
{
"reference": "urn:uuid:45271f7f-63ab-4946-970f-3daaaa0663ff"
}
],
"title": "Patient Summary as of December 7, 2020 14:30"
}
},
{
"fullUrl": "urn:uuid:45271f7f-63ab-4946-970f-3daaaa0663ff",
"resource": {
"resourceType": "Practitioner",
"id": "45271f7f-63ab-4946-970f-3daaaa0663ff",
"active": true,
"name": [
{
"family": "Doe",
"given": [
"John"
]
}
]
}
}
]
}
```
1. リクエストを送信します。FHIR `Bundle`ドキュメントタイプは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)の署名プロトコルを持つ`POST`リクエストを使用します。次のコード例では、デモンストレーションの目的で `curl` コマンドラインツールを使用しています。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle' \
--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' \
--data @document-type.json
```
------
#### [ 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)」を参照してください。
------
サーバーは、`Bundle`ドキュメントタイプリクエストの結果として作成された 2 つの`Patient`リソースを示すレスポンスを返します。
## バンドルの検証レベルの設定
FHIR リソースをバンドルする場合、オプションで HTTP `x-amzn-healthlake-fhir-validation-level` ヘッダーを指定して、リソースの検証レベルを設定できます。この検証レベルは、バンドル内のすべての作成および更新リクエストに対して設定されます。 AWS HealthLake は現在、次の検証レベルをサポートしています。
+ `strict`: リソースは、リソースのプロファイル要素、またはプロファイルが存在しない場合は R4 仕様に従って検証されます。これはデフォルトの検証レベルです AWS HealthLake。
+ `structure-only`: リソースは R4 に対して検証され、参照されるプロファイルは無視されます。
+ `minimal`: リソースは、特定の R4 ルールを無視して、最小限検証されます。検索/分析に必要な構造チェックに失敗したリソースは、監査の警告を含むように更新されます。
最小限の検証レベルにバンドルされたリソースは、検索インデックス作成に必要な検証に失敗しても、Datastore に取り込むことができます。この場合、リソースが更新されて Healthlake 固有の拡張機能が含まれ、上記の失敗が記録されます。バンドルレスポンス内のエントリには、次のように OperationOutcome リソースが含まれます。
```
{
"resourceType": "Bundle",
"type": "batch-response",
"timestamp": "2025-08-25T22:58:48.846287342Z",
"entry": [
{
"response": {
"status": "201",
"location": "Patient/195abc49-ba8e-4c8b-95c2-abc88fef7544/_history/1",
"etag": "W/\"1\"",
"lastModified": "2025-08-25T22:58:48.801245445Z",
"outcome": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"details": {
"text": "FHIR resource in payload failed FHIR validation rules."
},
"diagnostics": "FHIR resource in payload failed FHIR validation rules."
}
]
}
}
}
]
}
```
さらに、次の HTTP レスポンスヘッダーは「true」の値に含まれます。
```
x-amzn-healthlake-validation-issues : true
```
**注記**
これらのエラーが存在する場合、R4 仕様に従って誤った形式で取り込まれたデータは期待どおりに検索できない可能性があることに注意してください。
## バンドルタイプ「メッセージ」の限定サポート
HealthLake では、内部変換プロセス`message`を通じて FHIR バンドルタイプのサポートが制限されています。このサポートは、レガシーの病院システムから ADT (入室、退室、転送) フィードを取り込むなど、メッセージバンドルをソースで再フォーマットできないシナリオ向けに設計されています。
**警告**
この機能には明示的な AWS アカウント許可リストが必要であり、FHIR R4 メッセージセマンティクスや参照整合性は適用されません。メッセージバンドルを使用する前に、 AWS サポートに連絡してアカウントの有効化をリクエストしてください。
### 標準メッセージ処理との主な違い
+ **メッセージバンドル** (FHIR 仕様): 最初のエントリは、他のリソースを参照`MessageHeader`する である必要があります。リソースには個々の`request`オブジェクトがなく、MessageHeader イベントによって処理アクションが決まります。
+ **HealthLake 処理**: 各リソースエントリに PUT オペレーションを自動的に割り当てることで、メッセージバンドルをバッチバンドルに変換します。リソースは、メッセージセマンティクスや参照整合性を適用せずに個別に処理されます。
### 重要な制限事項
+ FHIR R4 メッセージ固有の処理ルールは適用されません
+ リソース間でトランザクションの整合性がない
+ リソース間の参照は検証されません
+ 明示的なアカウントの許可リストが必要です
### メッセージバンドル構造の例
```
{
"resourceType": "Bundle",
"type": "message",
"entry": [
{
"resource": {
"resourceType": "MessageHeader",
"eventCoding": {
"system": "http://hl7.org/fhir/us/davinci-alerts/CodeSystem/notification-event",
"code": "notification-admit"
},
"focus": [{"reference": "Encounter/example-id"}]
}
},
{
"resource": {"resourceType": "Patient", "id": "example-id"}
},
{
"resource": {"resourceType": "Encounter", "id": "example-id"}
}
]
}
```
**注記**
各リソースは、個別の PUT オペレーションを介して送信されたかのように個別に保存されます。完全な FHIR メッセージングセマンティクスまたは参照整合性の検証が必要な場合は、送信前にメッセージバンドルを前処理するか、アプリケーションレベルの検証を実装します。
## 非同期バンドルトランザクション
AWS HealthLake は、最大 500 `transaction`個のリソースを持つトランザクションを送信できる非同期`Bundle`型をサポートしています。非同期トランザクションを送信すると、HealthLake はそれを処理のためにキューに入れ、すぐにポーリング URL を返します。この URL を使用してステータスを確認し、レスポンスを取得できます。これは [FHIR 非同期バンドルパターン](https://hl7.org/fhir/async-bundle.html)に従います。
**非同期トランザクションを使用するタイミング**
+ 1 つのトランザクションで 100 を超えるリソース (同期制限) を送信する必要があります。
+ トランザクション処理が完了するまでの待機中にアプリケーションをブロックしないようにします。
+ 大量の関連リソースをより良いスループットで処理する必要があります。
**重要**
ポーリング結果は、トランザクション完了後 90 日間使用できます。この 90 日間の期間が過ぎると、ポーリング URL は結果を返さなくなります。このウィンドウ内で結果を取得して保存する統合を設計します。
**注記**
同期`Bundle`型`transaction`は引き続き最大 100 個のリソースをサポートし、デフォルトの処理モードです。`Prefer: respond-async` ヘッダーなしで 100 を超えるリソース`transaction`を持つ`Bundle`タイプを送信すると、HealthLake は`422 Unprocessable Entity`エラーを返します。タイプのバンドル`batch`は非同期処理ではサポートされていません。`Bundle`タイプのみ非同期で送信`transaction`できます (最大 500 オペレーション）。
### 非同期トランザクションの送信
非同期トランザクションを送信するには、 `Prefer: respond-async`ヘッダーを使用してデータストアエンドポイントに`POST`リクエストを送信します。バンドルのタイプは である必要があります`transaction`。タイプのバンドル`batch`は、非同期バンドル処理ではサポートされていません。
HealthLake は、送信時にバンドルの初期検証を行います。検証が成功すると、HealthLake はポーリング URL を含む`content-location`レスポンスヘッダーで HTTP 202 Accepted を返します。
**非同期`Bundle`型を送信するには `transaction`**
1. HealthLake データストアエンドポイントに`POST`リクエストを送信します。
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. バンドルタイプ でリクエストの JSON 本文を作成します`transaction`。この手順では、ファイルを として保存します`async-transaction.json`。
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"resource": {
"resourceType": "Patient",
"active": true,
"name": [
{
"use": "official",
"family": "Smith",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1990-01-15"
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"resource": {
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel"
}
]
},
"subject": {
"reference": "urn:uuid:example-patient-id"
}
},
"request": {
"method": "POST",
"url": "Observation"
}
}
]
}
```
1. `Prefer: respond-async` ヘッダーを使用してリクエストを送信します。FHIR `Bundle`トランザクションタイプは、[AWS 署名バージョン 4 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)または SMART on FHIR 認可の`POST`リクエストを使用します。次のコード例では、デモンストレーションの目的で `curl` コマンドラインツールを使用しています。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/' \
--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' \
--header 'Prefer: respond-async' \
--data @async-transaction.json
```
------
#### [ 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)」を参照してください。
------
1. 送信が成功すると、サーバーは HTTP 202 Accepted を返します。`content-location` レスポンスヘッダーにはポーリング URL が含まれています。レスポンス本文は `OperationOutcome`リソースです。
```
HTTP/1.1 202 Accepted
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId
```
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Submitted Asynchronous Bundle Transaction",
"location": [
"https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId"
]
}
]
}
```
### トランザクションステータスのポーリング
非同期トランザクションを送信したら、`content-location`レスポンスヘッダーのポーリング URL を使用してトランザクションのステータスを確認します。ポーリング URL に`GET`リクエストを送信します。
**注記**
SMART on FHIR 対応データストアの場合、認可トークンには、トランザクションステータスをポーリングする`Transaction`リソースタイプの`read`アクセス許可が含まれている必要があります。SMART on FHIR スコープの詳細については、「」を参照してください[HealthLake でサポートされている FHIR OAuth 2.0 スコープでの SMART](reference-smart-on-fhir-oauth-scopes.md)。
ポーリング URL に`GET`リクエストを送信します。次の例では、 `curl` コマンドラインツールを使用しています。
------
#### [ SigV4 ]
SigV4 認可
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--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'
```
------
#### [ SMART on FHIR ]
FHIR 認可に関する SMART。認可トークンには、`Transaction`リソースタイプに対する`read`アクセス許可を含める必要があります。
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--header 'Authorization: Bearer $SMART_ACCESS_TOKEN' \
--header 'Accept: application/json'
```
------
次の表に、考えられるレスポンスを示します。
**ポーリングレスポンスコード**
| HTTP ステータス | 意味 | レスポンス本文 |
| --- | --- | --- |
| 202 Accepted | トランザクションがキューに入っている | OperationOutcome 診断「SUBMITTED」を使用する |
| 202 Accepted | トランザクションは処理中です | OperationOutcome 診断「IN\$1PROGRESS」 |
| 200 OK | トランザクションが正常に完了しました | Bundle タイプ を持つ transaction-response |
| 4xx/5xx | トランザクションが失敗しました | OperationOutcome エラーの詳細を含む |
次の例は、各レスポンスタイプを示しています。
**キューに入れられたトランザクション (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "SUBMITTED"
}
]
}
```
**トランザクション処理 (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "IN_PROGRESS"
}
]
}
```
**トランザクション完了 (200)**
```
{
"resourceType": "Bundle",
"type": "transaction-response",
"entry": [
{
"response": {
"status": "201",
"location": "Patient/example-id/_history/1",
"etag": "W/\"1\"",
"lastModified": "2024-01-15T10:30:00.000Z"
}
},
{
"response": {
"status": "201",
"location": "Observation/example-id/_history/1",
"etag": "W/\"1\"",
"lastModified": "2024-01-15T10:30:00.000Z"
}
}
]
}
```
**トランザクションが失敗しました (4xx/5xx)**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Transaction failed: conflict detected on resource Patient/example-id"
}
]
}
```
### 処理順序
タイプの非同期バンドル`transaction`はキューに入れられますが、厳密な送信順序では処理されません。HealthLake は、使用可能な容量とシステム負荷に基づいて処理を最適化します。
**重要**
送信された順序で処理されるトランザクションに依存しないでください。例えば、トランザクション A を午前 10:00 に送信し、トランザクション B を午前 10:01 に送信すると、トランザクション B はトランザクション A の前に完了する可能性があります。アプリケーションを設計する目的は次のとおりです。
out-of-orderの完了を処理します。
ポーリング URL を使用して、各トランザクションを個別に追跡します。
ユースケースで注文が重要な場合は、アプリケーションレベルのシーケンスを実装します。
### クォータとスロットリング
非同期トランザクションには、次のクォータとレート制限が適用されます。
**非同期トランザクションクォータ**
| クォータ | 値 | 引き上げ可能 |
| --- | --- | --- |
| 非同期トランザクションあたりの最大オペレーション数 | 500 | いいえ |
| データストアあたりの保留中の最大トランザクション数 | 500 | はい |
+ 非同期トランザクションは、 で定義されているのと同じ API レート制限を共有します[Service Quotas](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas)。
+ トランザクションステータスのポーリングは、FHIR リソースの読み取り (`GET`) オペレーションと同じ API レート制限を共有します。
+ 保留中のトランザクション制限に達すると、後続の送信は既存のトランザクションが完了するまでエラーを返します。
### エラー処理
「トランザクション」バンドルの場合、バンドルに含まれるすべての FHIR リソースはアトミックオペレーションとして処理されます。オペレーションのすべてのリソースは成功する必要があります。成功しない場合、バンドル内のオペレーションは処理されません。
エラーは、HealthLake が同期的に返す送信エラーと、ポーリングによって取得する処理エラーの 2 つのカテゴリに分類されます。
**送信エラー**
HealthLake は送信時にバンドルを検証し、トランザクションがキューに入る前にエラーを同期的に返します。送信エラーには、無効な FHIR リソース検証エラー、サポートされていないリソースタイプ、500 オペレーション制限の超過、バッチバンドルでの `Prefer: respond-async`ヘッダーの使用が含まれます。データストアの保留中のトランザクション制限に達した場合、HealthLake は を返します`ThrottlingException`。送信エラーが発生すると、トランザクションはキューに入れられません。
**処理エラー**
処理エラーは、トランザクションがキューに入れられ、ポーリング URL を介して返された後に発生します。これには、トランザクションの一部であるリソースを別のオペレーションで変更したトランザクションの競合や、処理中のサーバーエラーが含まれます。処理エラーが発生した場合、トランザクション内のリソースに対してリソースミューテーションは行われません。ポーリング URL は、エラーの詳細`OperationOutcome`を含む を返します。
# 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. 検索操作と削除操作の間でリソースが変更される可能性のある、同時実行性の高い環境でのタイミングの競合に備えます。
# べき等性と同時実行性
## べき等性キー
AWS HealthLake は FHIR `POST`オペレーションのべき等性キーをサポートし、リソースの作成中にデータの整合性を確保するための堅牢なメカニズムを提供します。リクエストヘッダーに一意の UUID をべき等性キーとして含めることで、ヘルスケアアプリケーションは、ネットワークの不安定性や自動再試行を伴うシナリオでも、各 FHIR リソースが 1 回だけ作成されることを保証できます。
この機能は、重複する医療記録が重大な結果をもたらす可能性のある医療システムにとって特に重要です。以前のリクエストと同じべき等性キーを使用してリクエストを受信すると、HealthLake は重複を作成する代わりに元のリソースを返します。たとえば、再試行ループ中や冗長なリクエストパイプラインが原因で発生する可能性があります。べき等性キーを使用すると、HealthLake は断続的な接続問題を処理するクライアントアプリケーションにシームレスなエクスペリエンスを提供しながら、データの一貫性を維持できます。
### 実装
```
POST //Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
"resourceType": "Patient",
"name": [...]
}
```
### レスポンスシナリオ
最初のリクエスト (201 作成)
+ 新しいリソースが正常に作成されました
+ レスポンスにはリソース ID が含まれます
リクエストの重複 (409 競合)
+ 同じべき等性キーが検出されました
+ 元のリソースが返されました
+ 新しいリソースは作成されていません
無効なリクエスト (400 Bad Request)
+ 不正な形式の UUID
+ 必須フィールドがありません
### ベストプラクティス
+ 新しいリソースの作成ごとに一意の UUID を生成する
+ 再試行ロジックのべき等性キーを保存する
+ 一貫したキー形式を使用する: UUID v4 を推奨
+ リソース作成を処理するクライアントアプリケーションに を実装する
**注記**
この機能は、厳密なデータ精度を必要とし、重複する医療記録を防ぐ医療システムにとって特に重要です。
## AWS HealthLake の ETag
AWS HealthLake は、FHIR リソースのオプティミスティック同時実行制御に ETags を使用し、同時変更を管理し、データ整合性を維持する信頼性の高いメカニズムを提供します。ETag は、リソースの特定のバージョンを表す一意の識別子であり、HTTP ヘッダーを介してバージョン管理システムとして機能します。リソースを読み取りまたは変更する場合、アプリケーションは ETags を使用して意図しない上書きを防止し、データの整合性を確保できます。特に、更新が同時に行われる可能性があるシナリオではそうです。
### 実装例
```
// 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
```
### レスポンスシナリオ
正常なオペレーション (200 OK または 204 コンテンツなし)
+ ETag が最新バージョンと一致する
+ オペレーションは意図したとおりに進行します
バージョン競合 (412 前提条件失敗)
+ ETag が現在のバージョンと一致しません
+ データ損失を防ぐための更新が拒否されました
### ベストプラクティス
+ すべての更新および削除オペレーションに ETagsを含める
+ バージョンの競合を処理するための再試行ロジックを実装する
+ If-None-Match を使用する: create-if-not-exists シナリオには \$1
+ 変更する前に必ず ETag の鮮度を確認する
この同時実行管理システムは、特に複数のユーザーまたはシステムが同じリソースにアクセスして変更する環境において、医療データの整合性を維持するために不可欠です。