Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwaltung von FHIR-Ressourcen in AWS HealthLake
Verwenden Sie FHIR RESTful R4-API-Interaktionen, um FHIR-Ressourcen in einem Datenspeicher zu verwalten. HealthLake In den folgenden Abschnitten HealthLake werden alle FHIR RESTful R4-API-Interaktionen beschrieben, die für die FHIR-Ressourcenverwaltung verfügbar sind. Informationen zu den Funktionen des HealthLake Datenspeichers und zu den unterstützten Teilen der FHIR-Spezifikation finden Sie unter. [FHIR R4-Fähigkeitserklärung für AWS HealthLake](reference-fhir-capability-statement.md)
**Anmerkung**
Die in diesem Kapitel aufgeführten FHIR-Interaktionen entsprechen dem HL7 FHIR R4-Standard für den Austausch von Gesundheitsdaten. Da es sich um Repräsentationen von HL7 FHIR-Diensten handelt, werden sie nicht über und angeboten. AWS CLI AWS SDKs Weitere Informationen finden Sie unter [RESTful API](https://hl7.org/fhir/R4/http.html) in der **FHIR RESTful R4-API-Dokumentation**.
In der folgenden Tabelle sind FHIR R4-Interaktionen aufgeführt, die von unterstützt werden. AWS HealthLake Informationen zu den von unterstützten *FHIR-Ressourcentypen* finden Sie unter HealthLake. [Ressourcentypen](reference-fhir-resource-types.md)
**FHIR R4-Interaktionen werden unterstützt von AWS HealthLake**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/healthlake/latest/devguide/managing-fhir-resources.html)
**Topics**
+ [Eine FHIR-Ressource erstellen](managing-fhir-resources-create.md)
+ [Eine FHIR-Ressource lesen](managing-fhir-resources-read.md)
+ [Lesen der FHIR-Ressourcengeschichte](managing-fhir-resources-read-history.md)
+ [Aktualisierung einer FHIR-Ressource](managing-fhir-resources-update.md)
+ [Ändern von Ressourcen mit PATCH-Operation](managing-fhir-resources-patch.md)
+ [Bündelung der FHIR-Ressourcen](managing-fhir-resources-bundle.md)
+ [Löschen einer FHIR-Ressource](managing-fhir-resources-delete.md)
+ [Idempotenz und Parallelität](managing-fhir-resources-idempotency.md)
# Eine FHIR-Ressource erstellen
Die `create` FHIR-Interaktion erstellt eine neue FHIR-Ressource in einem HealthLake Datenspeicher. Weitere Informationen finden Sie [https://hl7.org/fhir/R4/http.html#create](https://hl7.org/fhir/R4/http.html#create)in der **FHIR RESTful R4-API-Dokumentation**.
**Um eine FHIR-Ressource zu erstellen**
1. Sammeln HealthLake `region` und `datastoreId` schätzen. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Ermitteln Sie den Typ der `Resource` zu erstellenden FHIR. Weitere Informationen finden Sie unter [Ressourcentypen](reference-fhir-resource-types.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und `datastoreId` eine URL für die Anfrage. Geben Sie auch den zu erstellenden `Resource` FHIR-Typ an. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource
```
1. Konstruieren Sie einen JSON-Hauptteil für die Anfrage und geben Sie die FHIR-Daten für die neue Ressource an. Für dieses Verfahren verwenden wir eine `Patient` FHIR-Ressource. Speichern Sie die Datei also unter. `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. Senden Sie die Anforderung . Die `create` FHIR-Interaktion verwendet eine `POST` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. In den folgenden Beispielen wird eine `Patient` FHIR-Ressource entweder HealthLake mithilfe von curl oder der Konsole erstellt. HealthLake Scrollen Sie über die Schaltfläche **Kopieren**, um ein vollständiges Beispiel anzuzeigen.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
Beispiel für die SMART-on-FHIR-Autorisierung für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
**Anmerkung**
Die HealthLake Konsole unterstützt nur die [AWS SigV4-Autorisierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html).
1. Melden Sie sich auf der Seite „[Abfrage ausführen](https://console.aws.amazon.com/healthlake/home#/crud)“ in der HealthLake Konsole an.
2. Treffen Sie im Abschnitt **Abfrageeinstellungen** die folgenden Optionen.
+ **Datenspeicher-ID** — Wählen Sie eine Datenspeicher-ID aus, um eine Abfragezeichenfolge zu generieren.
+ **Abfragetyp** — wählen Sie`Create`.
+ **Ressourcentyp** — wählen Sie den zu erstellenden [FHIR-Ressourcentyp](reference-fhir-resource-types.md) aus.
+ **Hauptteil der Anfrage** — Konstruieren Sie einen JSON-Hauptteil für die Anfrage und geben Sie die FHIR-Daten für die neue Ressource an.
3. Wählen Sie **Abfrage ausführen**.
------
**Konfiguration der Validierungsebene für die Ressourcenerstellung**
Wenn Sie eine FHIR-Ressource erstellen, können Sie optional einen `x-amzn-healthlake-fhir-validation-level` HTTP-Header angeben, um eine Validierungsebene für die Ressource zu konfigurieren. AWS HealthLake unterstützt derzeit die folgenden Validierungsstufen:
+ `strict`: Ressourcen werden anhand des Profilelements der Ressource oder der R4-Spezifikation, falls kein Profil vorhanden ist, validiert. Dies ist die Standardvalidierungsebene für AWS HealthLake.
+ `structure-only`: Ressourcen werden anhand von R4 validiert, wobei alle referenzierten Profile ignoriert werden.
+ `minimal`: Ressourcen werden minimal validiert, wobei bestimmte R4-Regeln ignoriert werden. Ressourcen, die die erforderlichen Strukturprüfungen nicht bestehen, search/analytics werden aktualisiert und enthalten nun eine Warnung zur Prüfung.
Ressourcen, die mit der Mindestvalidierungsstufe erstellt wurden, können in einen Datenspeicher aufgenommen werden, obwohl die für die Suchindizierung erforderliche Überprüfung fehlgeschlagen ist. In diesem Fall werden die Ressourcen um eine Healthlake-spezifische Erweiterung erweitert, um die genannten Fehler zu dokumentieren:
```
{
"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.\"}]}"
}
```
Zusätzlich wird der folgende HTTP-Antwort-Header mit dem Wert „true“ hinzugefügt:
```
x-amzn-healthlake-validation-issues : true
```
**Anmerkung**
Die aufgenommenen Daten, die gemäß der R4-Spezifikation fehlerhaft formatiert sind, können möglicherweise nicht wie erwartet durchsucht werden, wenn diese Fehler vorliegen.
# Eine FHIR-Ressource lesen
Die `read` FHIR-Interaktion liest den aktuellen Status einer Ressource in einem HealthLake Datenspeicher. Weitere Informationen finden Sie [https://hl7.org/fhir/R4/http.html#read](https://hl7.org/fhir/R4/http.html#read)in der **FHIR RESTful R4-API-Dokumentation**.
**Um eine FHIR-Ressource zu lesen**
1. Sammeln HealthLake `region` und `datastoreId` schätzen. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Ermitteln Sie den Typ von FHIR`Resource`, der gelesen werden soll, und erfassen Sie den zugehörigen `id` Wert. Weitere Informationen finden Sie unter [Ressourcentypen](reference-fhir-resource-types.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und `datastoreId` eine URL für die Anfrage. Geben Sie auch den `Resource` FHIR-Typ und den zugehörigen `id` Typ an. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Senden Sie die Anforderung . Die `read` FHIR-Interaktion verwendet eine `GET` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. Im folgenden `curl` Beispiel wird der aktuelle Status einer `Patient` FHIR-Ressource eingelesen. HealthLake Scrollen Sie über die Schaltfläche **Kopieren**, um das gesamte Beispiel anzuzeigen.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
Beispiel für die SMART-on-FHIR-Autorisierung für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Melden Sie sich auf der Seite „[Abfrage ausführen](https://console.aws.amazon.com/healthlake/home#/crud)“ in der HealthLake Konsole an.
2. Treffen Sie im Abschnitt **Abfrageeinstellungen** die folgenden Optionen.
+ **Datenspeicher-ID** — Wählen Sie eine Datenspeicher-ID aus, um eine Abfragezeichenfolge zu generieren.
+ **Abfragetyp** — wählen Sie`Read`.
+ **Ressourcentyp** — wählen Sie den [FHIR-Ressourcentyp](reference-fhir-resource-types.md) aus, der gelesen werden soll.
+ **Ressourcen-ID** — geben Sie die FHIR-Ressourcen-ID ein.
3. Wählen Sie **Abfrage ausführen**.
------
# Lesen der FHIR-Ressourcengeschichte
Die `history` FHIR-Interaktion ruft den Verlauf einer bestimmten FHIR-Ressource in einem Datenspeicher ab. HealthLake Mithilfe dieser Interaktion können Sie feststellen, wie sich der Inhalt einer FHIR-Ressource im Laufe der Zeit verändert hat. Bei der Abstimmung mit Audit-Logs ist es auch nützlich, den Status einer Ressource vor und nach der Änderung zu überprüfen. Die FHIR-Interaktionen `create` und `delete` führen zu einer historischen Version der Ressource, die gespeichert werden soll. `update` Weitere Informationen finden Sie [https://hl7.org/fhir/R4/http.html#history](https://hl7.org/fhir/R4/http.html#history)in der **FHIR RESTful R4-API-Dokumentation**.
**Anmerkung**
Sie können sich `history` für bestimmte FHIR-Ressourcentypen abmelden. Um sich abzumelden, erstellen Sie einen Fall mit [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Um Ihren Fall zu erstellen, melden Sie sich bei Ihrem an AWS-Konto und wählen Sie **Fall erstellen**.
**Um den FHIR-Ressourcenverlauf zu lesen**
1. Sammeln HealthLake `region` und `datastoreId` schätzen. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Ermitteln Sie den Typ von FHIR`Resource`, der gelesen werden soll, und erfassen Sie den zugehörigen `id` Wert. Weitere Informationen finden Sie unter [Ressourcentypen](reference-fhir-resource-types.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und `datastoreId` eine URL für die Anfrage. Geben Sie auch den `Resource` FHIR-Typ, die zugehörigen `id` und optionalen Suchparameter an. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history{?[parameters]}
```
**HealthLake unterstützte Suchparameter für die FHIR-Interaktion `history`**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/healthlake/latest/devguide/managing-fhir-resources-read-history.html)
1. Senden Sie die Anforderung . Die `history` FHIR-Interaktion verwendet eine `GET` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. Im folgenden `curl` Beispiel wird der `_count` Suchparameter verwendet, um 100 historische Suchergebnisse pro Seite für eine `Patient` FHIR-Ressource in zurückzugeben. HealthLake Scrollen Sie über die Schaltfläche **Kopieren**, um das gesamte Beispiel anzuzeigen.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
Der zurückgegebene Inhalt einer `history` Interaktion ist in einer FHIR-Ressource enthalten`Bundle`, wobei der Typ auf gesetzt ist. `history` Sie enthält den angegebenen Versionsverlauf, sortiert nach den ältesten Versionen zuletzt, und enthält gelöschte Ressourcen. Weitere Informationen finden Sie [https://hl7.org/fhir/R4/bundle.html](https://hl7.org/fhir/R4/bundle.html)in der **FHIR R4-Dokumentation**.
## Lesen des versionsspezifischen FHIR-Ressourcenverlaufs
Die `vread` FHIR-Interaktion führt ein versionsspezifisches Lesen einer Ressource in einem Datenspeicher durch. HealthLake Mithilfe dieser Interaktion können Sie den Inhalt einer FHIR-Ressource so anzeigen, wie er zu einem bestimmten Zeitpunkt in der Vergangenheit war.
**Anmerkung**
Wenn Sie die `history` FHIR-Interaktion *ohne* verwenden`vread`, wird HealthLake immer die neueste Version der Metadaten der Ressource zurückgegeben.
HealthLake erklärt, dass es die Versionierung [https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning](https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning)für jede unterstützte Ressource unterstützt. Alle HealthLake Datenspeicher enthalten `Resource.meta.versionId` (`vid`) für alle Ressourcen.
Wenn die `history` FHIR-Interaktion aktiviert ist (standardmäßig für Datenspeicher, die nach dem 25.10.2024 erstellt wurden, oder auf Anfrage für ältere Datenspeicher), enthält die `Bundle` Antwort das `vid` als Teil des Elements. [https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location](https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location) Im folgenden Beispiel `vid` wird das als Zahl angezeigt. `1` Das vollständige Beispiel finden Sie unter [Beispiel Bundle/Bundle-Response](https://build.fhir.org/bundle-response.json.html) (JSON).
```
"response" : {
"status" : "201 Created",
"location" : "Patient/12423/_history/1",
...}
```
**Um den versionsspezifischen FHIR-Ressourcenverlauf zu lesen**
1. Sammeln HealthLake `region` und bewerten. `datastoreId` Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Ermitteln Sie den `Resource` FHIR-Typ, der gelesen und die zugehörigen `id` `vid` Werte gesammelt werden soll. Weitere Informationen finden Sie unter [Ressourcentypen](reference-fhir-resource-types.md).
1. Konstruieren Sie anhand der für HealthLake und FHIR gesammelten Werte eine URL für die Anfrage. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history/vid
```
1. Senden Sie die Anforderung . Die `history` FHIR-Interaktion verwendet eine `GET` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. Die folgende `vread` Interaktion gibt eine einzelne Instanz mit dem für die `Patient` FHIR-Ressource angegebenen Inhalt für die Version der Ressourcenmetadaten zurück, die von der angegeben wurde. `vid` Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
# Aktualisierung einer FHIR-Ressource
Die `update` FHIR-Interaktion erstellt eine neue aktuelle Version für eine vorhandene Ressource oder erstellt eine erste Version, wenn für die angegebene Ressource noch keine Ressource vorhanden ist. `id` Weitere Informationen finden Sie [https://hl7.org/fhir/R4/http.html#update](https://hl7.org/fhir/R4/http.html#update)in der **FHIR RESTful R4-API-Dokumentation**.
**Um eine FHIR-Ressource zu aktualisieren**
1. Sammeln HealthLake `region` und bewerten`datastoreId`. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Ermitteln Sie den Typ des FHIR`Resource`, der aktualisiert werden soll, und erfassen Sie den zugehörigen `id` Wert. Weitere Informationen finden Sie unter [Ressourcentypen](reference-fhir-resource-types.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und `datastoreId` eine URL für die Anfrage. Geben Sie auch den `Resource` FHIR-Typ und den zugehörigen `id` Typ an. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Erstellen Sie einen `JSON` Text für die Anfrage, in dem Sie angeben, welche FHIR-Datenaktualisierungen vorgenommen werden sollen. Speichern Sie die Datei für die Zwecke dieses Verfahrens unter. `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. Senden Sie die Anforderung . Die `update` FHIR-Interaktion verwendet eine `PUT` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. Das folgende `curl` Beispiel aktualisiert eine `Patient` Ressource in. HealthLake Scrollen Sie über die Schaltfläche **Kopieren**, um das gesamte Beispiel anzuzeigen.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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
```
Ihre Anfrage gibt einen `200` HTTP-Statuscode zurück, wenn eine bestehende Ressource *aktualisiert* wird, oder einen `201` HTTP-Statuscode, wenn eine neue Ressource erstellt wird.
------
#### [ SMART on FHIR ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Melden Sie sich auf der Seite „[Abfrage ausführen](https://console.aws.amazon.com/healthlake/home#/crud)“ in der HealthLake Konsole an.
2. Treffen Sie im Abschnitt **Abfrageeinstellungen** die folgenden Optionen.
+ **Datenspeicher-ID** — Wählen Sie eine Datenspeicher-ID aus, um eine Abfragezeichenfolge zu generieren.
+ **Abfragetyp** — wählen Sie`Update (PUT)`.
+ **Ressourcentyp** — Wählen Sie den [FHIR-Ressourcentyp](reference-fhir-resource-types.md) aus, den Sie aktualisieren oder erstellen möchten.
+ **Hauptteil der Anfrage** — Konstruieren Sie einen JSON-Hauptteil für die Anfrage und geben Sie die FHIR-Daten an, mit denen die Ressource aktualisiert werden soll.
3. Wählen Sie **Abfrage ausführen**.
------
## Aktualisierung der FHIR-Ressourcen auf der Grundlage von Bedingungen
Die bedingte Aktualisierung ermöglicht es Ihnen, eine vorhandene Ressource anhand einiger Identifikations-Suchkriterien und nicht anhand logischer FHIR `id` zu aktualisieren. Wenn der Server das Update verarbeitet, führt er eine Suche mithilfe seiner Standardsuchfunktionen für den Ressourcentyp durch, mit dem Ziel, eine `id` für die Anfrage logische Lösung zu finden.
Die Aktion, die der Server ergreift, hängt davon ab, wie viele Treffer er findet:
+ **Keine Treffer, keine `id` Angabe im Anfragetext**: Der Server erstellt die FHIR-Ressource.
+ **Keine Treffer, `id` angegeben und die Ressource ist noch nicht vorhanden mit`id`: Der** Server behandelt die Interaktion als Update as Create-Interaktion.
+ **Keine Treffer, `id` angegeben und bereits vorhanden**: Der Server lehnt das Update mit einem `409 Conflict` Fehler ab.
+ **Ein Treffer, keine Ressource `id` bereitgestellt ODER (Ressource `id` bereitgestellt und sie entspricht der gefundenen Ressource)**: Der Server führt das Update anhand der passenden Ressource wie oben beschrieben durch. Wenn die Ressource aktualisiert wurde, MUSS der Server a `200 OK` zurückgeben.
+ **One Match, `id` bereitgestellte Ressource, entspricht aber nicht der gefundenen Ressource**: Der Server gibt einen `409 Conflict` Fehler zurück, der darauf hinweist, dass die Client-ID-Spezifikation ein Problem war, vorzugsweise mit einem `OperationOutcome`
+ **Mehrere Treffer**: Der Server gibt einen `412 Precondition Failed` Fehler zurück, der darauf hinweist, dass die Kriterien des Clients nicht selektiv genug waren, vorzugsweise mit einem OperationOutcome
Im folgenden Beispiel wird eine `Patient` Ressource aktualisiert, deren Name Peter ist, deren Geburtsdatum der 1. Januar 2000 ist und deren Telefonnummer 1234567890 ist.
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
## Konfiguration der Validierungsebene für Ressourcenupdates
Bei der Aktualisierung einer FHIR-Ressource können Sie optional einen `x-amzn-healthlake-fhir-validation-level` HTTP-Header angeben, um eine Validierungsebene für die Ressource zu konfigurieren. AWS HealthLake unterstützt derzeit die folgenden Validierungsstufen:
+ `strict`: Ressourcen werden anhand des Profilelements der Ressource oder der R4-Spezifikation, falls kein Profil vorhanden ist, validiert. Dies ist die Standardvalidierungsebene für AWS HealthLake.
+ `structure-only`: Ressourcen werden anhand von R4 validiert, wobei alle referenzierten Profile ignoriert werden.
+ `minimal`: Ressourcen werden minimal validiert, wobei bestimmte R4-Regeln ignoriert werden. Ressourcen, die die erforderlichen Strukturprüfungen nicht bestehen, search/analytics werden aktualisiert und enthalten nun eine Warnung zur Prüfung.
Ressourcen, die mit der Mindestvalidierungsstufe aktualisiert wurden, können in einen Datenspeicher aufgenommen werden, obwohl die für die Suchindizierung erforderliche Überprüfung fehlgeschlagen ist. In diesem Fall werden die Ressourcen um eine Healthlake-spezifische Erweiterung erweitert, um die genannten Fehler zu dokumentieren:
```
{
"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.\"}]}"
}
```
Zusätzlich wird der folgende HTTP-Antwort-Header mit dem Wert „true“ hinzugefügt:
```
x-amzn-healthlake-validation-issues : true
```
**Anmerkung**
Beachten Sie, dass aufgenommene Daten, die gemäß der R4-Spezifikation falsch formatiert sind, möglicherweise nicht wie erwartet durchsucht werden können, wenn diese Fehler vorliegen.
# Ändern von Ressourcen mit PATCH-Operation
AWS HealthLake unterstützt den PATCH-Vorgang für FHIR-Ressourcen, sodass Sie Ressourcen ändern können, indem Sie gezielt bestimmte Elemente hinzufügen, ersetzen oder löschen möchten, ohne die gesamte Ressource zu aktualisieren. Dieser Vorgang ist besonders nützlich, wenn Sie:
+ Nehmen Sie gezielte Aktualisierungen großer Ressourcen vor
+ Reduzieren Sie die Nutzung der Netzwerkbandbreite
+ Führen Sie atomare Änderungen an bestimmten Ressourcenelementen durch
+ Minimiere das Risiko, dass gleichzeitige Änderungen überschrieben werden
+ Aktualisieren Sie Ressourcen im Rahmen von Batch- und Transaktions-Workflows
## Unterstützte PATCH-Formate
AWS HealthLake unterstützt zwei Standard-PATCH-Formate:
### JSON-Patch (RFC 6902)
Verwendet die JSON-Pointer-Syntax, um Elemente anhand ihrer Position in der Ressourcenstruktur als Ziel auszuwählen.
**Inhaltstyp:** `application/json-patch+json`
### FHIRPath Patch (FHIR R4-Spezifikation)
Verwendet FHIRPath Ausdrücke, um Elemente anhand ihres Inhalts und ihrer Beziehungen gezielt anzusprechen, und bietet so einen FHIR-nativen Patchansatz.
**Inhaltstyp:** `application/fhir+json`
## Usage
### Direkte PATCH-Operationen
Der PATCH-Vorgang kann mit der PATCH-HTTP-Methode direkt auf FHIR-Ressourcen aufgerufen werden:
```
PATCH [base]/[resource-type]/[id]{?_format=[mime-type]}
```
### PATCH in Paketen
PATCH-Operationen können als Einträge in FHIR-Bundles des Typs enthalten sein `batch` oder ermöglichen es Ihnen`transaction`, Patch-Operationen mit anderen FHIR-Interaktionen (Erstellen, Lesen, Aktualisieren, Löschen) in einer einzigen Anfrage zu kombinieren.
+ **Transaktionspakete**: Alle Einträge sind atomar erfolgreich oder schlagen fehl
+ **Batch-Bundles**: Jeder Eintrag wird unabhängig verarbeitet
## JSON-Patch-Format
### Unterstützte Vorgänge
| Operation | Description |
| --- | --- |
| add | Fügen Sie der Ressource einen neuen Wert hinzu |
| remove | Entferne einen Wert aus der Ressource |
| replace | Ersetzt einen vorhandenen Wert in der Ressource |
| move | Entferne einen Wert von einem Ort und füge ihn einem anderen hinzu |
| copy | Kopiert einen Wert von einem Ort an einen anderen |
| test | Testen Sie, ob ein Wert an der Zielposition einem bestimmten Wert entspricht |
### Pfadsyntax
Der JSON-Patch verwendet die JSON-Pointer-Syntax (RFC 6901):
| Beispiel für einen Pfad | Description |
| --- | --- |
| /name/0/family | Das Familienelement des Vornamens |
| /telecom/- | An das Telekommunikations-Array anhängen |
| /active | Aktives Element auf Stammebene |
| /address/0/line/1 | Zweite Zeile der ersten Adresse |
### Beispiele
**Direkte JSON-Patch-Anfrage mit mehreren Vorgängen**
```
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"
}
]
```
**Direkte JSON-Patch-Anfrage mit einem einzigen Vorgang**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
[
{
"op": "replace",
"path": "/active",
"value": false
}
]
```
**JSON-Patch im Paket**
Verwenden Sie eine Binärressource, die die Base64-kodierte JSON-Patch-Payload enthält:
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Binary",
"contentType": "application/json-patch+json",
"data": "W3sib3AiOiJhZGQiLCJwYXRoIjoiL2JpcnRoRGF0ZSIsInZhbHVlIjoiMTk5MC0wMS0wMSJ9XQ=="
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## FHIRPath Patch-Format
### Unterstützte Vorgänge
| Operation | Description |
| --- | --- |
| add | Fügt einer Ressource ein neues Element hinzu |
| insert | Fügt ein Element an einer bestimmten Position in einer Liste ein |
| delete | Ein Element aus einer Ressource entfernen |
| replace | Ersetzt den Wert eines vorhandenen Elements |
| move | Ordnen Sie Elemente innerhalb einer Liste neu an |
### Pfadsyntax
FHIRPath Patch verwendet FHIRPath Ausdrücke und unterstützt:
+ **Indexbasierter Zugriff**: `Patient.name[0]`
+ **Filterung** mit: `where()` `Patient.name.where(use = 'official')`
+ **Boolesche Logik**: `Patient.telecom.where(system = 'phone' and use = 'work')`
+ Funktionen zur **Unterteilung:,** `first()` `last()`
+ **Existenzprüfungen**:`exists()`, `count()`
+ **Polymorphe Navigation**: `Observation.value`
### Beispiele
**Direkte Patch-Anfrage 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 Patch im Paket**
Verwenden Sie eine Parameter-Ressource als Eingangsressource mit`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"
}
}]
}
```
## Anforderungsheader
| Header | Erforderlich | Beschreibung |
| --- | --- | --- |
| Content-Type | Ja | application/json-patch\$1jsonfür JSON Patch oder application/fhir\$1json für FHIRPath Patch |
| If-Match | Nein | Versionsspezifisches bedingtes Update mit ETag |
## Beispielantwort
Der Vorgang gibt die aktualisierte Ressource mit neuen Versionsinformationen zurück:
```
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"
}
}
```
## Behavior
Die PATCH-Operation:
+ Validiert die Patch-Syntax gemäß der entsprechenden Spezifikation (RFC 6902 für JSON Patch, FHIR R4 für Patch) FHIRPath
+ Wendet Operationen atomar an — alle Operationen sind erfolgreich oder alle schlagen fehl
+ Aktualisiert die Versions-ID der Ressource und erstellt einen neuen Verlaufseintrag
+ Behält die ursprüngliche Ressource im Verlauf bei, bevor Änderungen übernommen werden
+ Überprüft die FHIR-Ressourcenbeschränkungen nach dem Anwenden von Patches
+ Unterstützt bedingte Aktualisierungen mithilfe des If-Match-Headers mit ETag
## Fehlerbehandlung
Der Vorgang behandelt die folgenden Fehlerbedingungen:
+ **400 Bad Request**: Ungültige Patch-Syntax (fehlerhafte Anfrage oder fehlerhaftes Patch-Dokument)
+ **404 Nicht gefunden**: Ressource nicht gefunden (angegebene ID existiert nicht)
+ **409-Konflikt**: Versionskonflikt (gleichzeitige Updates oder veraltete Versions-ID angegeben)
+ **422 Unverarbeitbare Entität**: Patch-Operationen können nicht auf die angegebenen Ressourcenelemente angewendet werden
## Zusammenfassung der Funktionen
| Funktion | JSON-Patch | FHIRPath Aufnäher |
| --- | --- | --- |
| Art des Inhalts | application/json-patch\$1json | application/fhir\$1json |
| Pfadformat | JSON-Zeiger (RFC 6901) | FHIRPath Ausdrücke |
| Direkte PATCH-API | Unterstützt | Unterstützt |
| Batch bündeln | Unterstützt (über Binary) | Unterstützt (über Parameter) |
| Transaktion bündeln | Unterstützt (per Binärdatei) | Unterstützt (über Parameter) |
| Operationen | hinzufügen, entfernen, ersetzen, verschieben, kopieren, testen | hinzufügen, einfügen, löschen, ersetzen, verschieben |
## Einschränkungen
+ Bedingte PATCH-Operationen, die Suchbedingungen verwenden, werden nicht unterstützt
+ JSON-Patch in Bundles muss Binärressourcen mit Base64-codiertem Inhalt verwenden
+ FHIRPath Patches in Bundles müssen Parameter-Ressourcen verwenden
## Weitere Ressourcen
Weitere Informationen zu PATCH-Vorgängen finden Sie unter:
+ [FHIR R4 PATCH-Dokumentation](https://hl7.org/fhir/http.html#patch)
+ [FHIR R4-Patch-Spezifikation FHIRPath ](https://hl7.org/fhir/fhirpatch.html)
+ [RFC 6902 — JSON-Patch](https://datatracker.ietf.org/doc/html/rfc6902#section-4)
+ [RFC 6901 — JSON-Zeiger](https://datatracker.ietf.org/doc/html/rfc6901)
# Bündelung der FHIR-Ressourcen
Ein FHIR `Bundle` ist ein Container für eine Sammlung von FHIR-Ressourcen in. AWS HealthLake AWS HealthLake unterstützt zwei Arten von Bundles mit unterschiedlichem Verarbeitungsverhalten.
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction)Bundles verarbeiten jede Ressource unabhängig voneinander. Wenn eine Ressource ausfällt, können die verbleibenden Ressourcen trotzdem erfolgreich sein. Jeder Vorgang wird einzeln verarbeitet, und die Verarbeitung wird auch dann fortgesetzt, wenn einige Operationen fehlschlagen. Verwenden Sie Batch-Pakete für Massenoperationen, bei denen ein teilweiser Erfolg akzeptabel ist, wie z. B. das Hochladen mehrerer Patientenakten, die nichts miteinander zu tun haben.
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction)Bündel verarbeiten alle Ressourcen atomar als eine einzige Einheit. Entweder sind alle Ressourcenoperationen erfolgreich, oder es wird kein AWS HealthLake Commit ausgeführt. Verwenden Sie Transaktionspakete, wenn Sie eine garantierte referenzielle Integrität für alle verwandten Ressourcen benötigen, z. B. wenn Sie einen Patienten mit ähnlichen Beobachtungen und Erkrankungen erstellen möchten, bei denen alle Daten zusammen aufgezeichnet werden müssen.
**Unterschiede zwischen Batch- und Transaktionspaketen**
| Feature | Batch | Transaktion |
| --- | --- | --- |
| Verarbeitungsmodell | Jeder Vorgang ist unabhängig erfolgreich oder schlägt fehl. | Alle Operationen sind als einzelne Atomeinheit erfolgreich oder fehlschlagen. |
| Fehlerbehandlung | Die Verarbeitung wird fortgesetzt, auch wenn einzelne Operationen fehlschlagen. | Das gesamte Paket schlägt fehl, wenn ein einzelner Vorgang fehlschlägt. |
| Reihenfolge der Ausführung | Die Ausführungsreihenfolge ist nicht garantiert. | Die Operationen werden in der angegebenen Reihenfolge verarbeitet. |
| Referenzielle Integrität | Wird nicht betriebsübergreifend durchgesetzt. | Wird für lokal referenzierte Ressourcen innerhalb des Pakets durchgesetzt. |
| Am besten verwendet für | Massenoperationen, bei denen ein teilweiser Erfolg akzeptabel ist. | Verwandte Ressourcen, die zusammen erstellt oder aktualisiert werden müssen. |
Sie können FHIR-Ressourcen desselben oder verschiedener Typen bündeln, und sie können eine Mischung aus FHIR-Vorgängen wie,`create`, `read` `update``delete`, und beinhalten. `patch` Weitere Informationen finden Sie unter [Resource Bundle](https://hl7.org/fhir/R4/Bundle) in der **FHIR** R4-Dokumentation.
Im Folgenden finden Sie Beispiele für Anwendungsfälle für jeden Bundle-Typ.
Batch-Pakete
+ Laden Sie während der nächtlichen Datensynchronisierung mehrere Patientenakten aus verschiedenen Einrichtungen hoch, die nichts miteinander zu tun haben.
+ Laden Sie historische Arzneimitteldaten in großen Mengen hoch, bei denen es bei einigen Aufzeichnungen zu Validierungsproblemen kommen könnte.
+ Laden Sie Referenzdaten wie Organisationen und Ärzte, bei denen einzelne Fehler keine Auswirkungen auf andere Einträge haben.
Transaktionspakete
+ Erstellen Sie einen Patienten mit entsprechenden Beobachtungen und Zuständen während einer Aufnahme in die Notaufnahme, bei der alle Daten zusammen aufgezeichnet werden müssen.
+ Aktualisieren Sie die Medikamentenliste eines Patienten und die zugehörigen Allergie-Informationen, die konsistent bleiben müssen.
+ Zeichnen Sie eine vollständige Begegnung mit dem Patienten, Beobachtungen, Verfahren und Abrechnungsinformationen in einer einzigen atomaren Einheit auf.
**Wichtig**
Sowohl Batch- als auch Transaktionspakete verwenden dieselbe `Bundle` Ressourcenstruktur. Der einzige Unterschied ist der Wert des `type` Feldes.
Das folgende Beispiel zeigt ein Transaktionspaket mit mehreren Ressourcentypen und Vorgängen.
```
{
"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"
}
}
]
}
```
## Bündelung von FHIR-Ressourcen als unabhängige Einheiten
**Um FHIR-Ressourcen als unabhängige Einheiten zu bündeln**
1. Sammeln HealthLake `region` und bewerten`datastoreId`. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und eine URL für die Anfrage`datastoreId`. Geben Sie in der URL *keinen* FHIR-Ressourcentyp an. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. Konstruieren Sie einen JSON-Hauptteil für die Anfrage und geben Sie jedes HTTP-Verb als Teil der `method` Elemente an. Im folgenden Beispiel wird eine `batch` Typinteraktion mit der `Bundle` Ressource verwendet, um neue `Medication` Ressourcen `Patient` zu erstellen. Alle erforderlichen Abschnitte sind entsprechend kommentiert. Speichern Sie die Datei für dieses Verfahren unter`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. Senden Sie die Anforderung . Der `Bundle` Batchtyp FHIR verwendet eine `POST` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. Im folgenden Codebeispiel wird das `curl` Befehlszeilentool zu Demonstrationszwecken verwendet.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
Der Server gibt eine Antwort zurück, in der die `Medication` Ressourcen `Patient` und die Ressourcen angezeigt werden, die als Ergebnis der `Bundle` Batch-Anfrage erstellt wurden.
## PUTs Befristet in Paketen
AWS HealthLake unterstützt bedingte Aktualisierungen innerhalb von Bundles mit den folgenden Abfrageparametern:
+ `_id`(eigenständig)
+ `_id`in Kombination mit einer der folgenden Optionen:
+ `_tag`
+ `_createdAt`
+ `_lastUpdated`
Wenn Sie Conditional PUTs in Bundles verwenden, werden die Abfrageparameter anhand vorhandener Ressourcen AWS HealthLake ausgewertet und auf der Grundlage der Vergleichsergebnisse Maßnahmen ergriffen.
**Verhalten bei bedingten Aktualisierungen**
| Szenario | HTTP-Status | Maßnahme ergriffen |
| --- | --- | --- |
| Ressource ohne angegebene ID | 201 erstellt | Erstellt immer eine neue Ressource. |
| Ressource mit neuer ID (keine Übereinstimmung) | 201 erstellt | Erstellt eine neue Ressource mit der angegebenen ID. |
| Ressource mit vorhandener ID (einziger Treffer) | 200 OK | Aktualisiert die passende Ressource. |
| Ressource mit vorhandener ID (Konflikt erkannt) | 409 Conflict (409 Konflikt) | Gibt einen Fehler zurück. Es wurden keine Änderungen vorgenommen. |
| Ressource mit vorhandener ID (ID stimmt nicht überein) | 400 Bad Request (400 Ungültige Anfrage) | Gibt einen Fehler zurück. Es wurden keine Änderungen vorgenommen. |
| Mehrere Ressourcen entsprechen den Bedingungen | 412 Precondition Failed (412 Vorbedingung fehlgeschlagen) | Gibt einen Fehler zurück. Es wurden keine Änderungen vorgenommen. |
Im folgenden Beispielpaket mit einer bedingten Aktualisierung wird die `Patient` Ressource mit der FHIR-ID nur `476` aktualisiert, wenn die Bedingung erfüllt `_lastUpdated=lt2025-04-20` ist.
```
{
"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"
}
}
]
}
```
## Bündelung von FHIR-Ressourcen zu einer einzigen Einheit
**Um FHIR-Ressourcen zu einer einzigen Einheit zu bündeln**
1. Sammeln HealthLake `region` und `datastoreId` schätzen. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und eine URL für die Anfrage`datastoreId`. Nehmen Sie den FHIR-Ressourcentyp `Bundle` als Teil der URL auf. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle
```
1. Konstruieren Sie einen JSON-Hauptteil für die Anfrage und geben Sie die FHIR-Ressourcen an, die gruppiert werden sollen. Im folgenden Beispiel werden zwei `Patient` Ressourcen gruppiert HealthLake. Speichern Sie die Datei für dieses Verfahren unter`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. Senden Sie die Anforderung . Der `Bundle` Dokumenttyp FHIR verwendet eine `POST` Anfrage mit dem [AWS Signature Version 4-Signaturprotokoll](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). Im folgenden Codebeispiel wird das `curl` Befehlszeilentool zu Demonstrationszwecken verwendet.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
Der Server gibt eine Antwort zurück, in der zwei `Patient` Ressourcen angezeigt werden, die als Ergebnis der `Bundle` Dokumenttypanforderung erstellt wurden.
## Konfiguration der Validierungsebene für Bundles
Beim Bündeln von FHIR-Ressourcen können Sie optional einen `x-amzn-healthlake-fhir-validation-level` HTTP-Header angeben, um eine Validierungsebene für die Ressource zu konfigurieren. Diese Validierungsebene wird für alle Erstellungs- und Aktualisierungsanforderungen innerhalb des Pakets festgelegt. AWS HealthLake unterstützt derzeit die folgenden Validierungsstufen:
+ `strict`: Ressourcen werden anhand des Profilelements der Ressource oder der R4-Spezifikation, falls kein Profil vorhanden ist, validiert. Dies ist die Standardvalidierungsebene für AWS HealthLake.
+ `structure-only`: Ressourcen werden anhand von R4 validiert, wobei alle referenzierten Profile ignoriert werden.
+ `minimal`: Ressourcen werden minimal validiert, wobei bestimmte R4-Regeln ignoriert werden. Ressourcen, die die erforderlichen Strukturprüfungen nicht bestehen, search/analytics werden aktualisiert und enthalten nun eine Warnung zur Prüfung.
Ressourcen, die mit der Mindestvalidierungsstufe gebündelt sind, können in einen Datenspeicher aufgenommen werden, obwohl die für die Suchindizierung erforderliche Überprüfung fehlgeschlagen ist. In diesem Fall werden die Ressourcen mit einer Healthlake-spezifischen Erweiterung aktualisiert, um diese Fehler zu dokumentieren, und die Einträge in der Bundle-Antwort werden Ressourcen wie folgt enthalten: 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."
}
]
}
}
}
]
}
```
Zusätzlich wird der folgende HTTP-Antwort-Header mit dem Wert „true“ hinzugefügt:
```
x-amzn-healthlake-validation-issues : true
```
**Anmerkung**
Beachten Sie, dass aufgenommene Daten, die gemäß der R4-Spezifikation falsch formatiert sind, möglicherweise nicht wie erwartet durchsucht werden können, wenn diese Fehler vorliegen.
## Eingeschränkte Unterstützung für den Bundle-Typ „Nachricht“
HealthLake bietet eingeschränkte Unterstützung für den FHIR-Bundle-Typ `message` durch einen internen Konvertierungsprozess. Diese Unterstützung ist für Szenarien konzipiert, in denen Nachrichtenpakete nicht an der Quelle neu formatiert werden können, z. B. bei der Aufnahme von ADT-Feeds (Admission, Discharge, Transfer) aus älteren Krankenhaussystemen.
**Warnung**
Diese Funktion erfordert eine explizite Zuteilung von AWS Benutzerkonten und erzwingt weder die Semantik noch die referenzielle Integrität von FHIR R4-Nachrichten. Wenden Sie sich an den AWS Support, um die Aktivierung für Ihr Konto zu beantragen, bevor Sie Nachrichtenpakete verwenden.
### Hauptunterschiede zur standardmäßigen Nachrichtenverarbeitung
+ **Nachrichtenpakete** (FHIR-Spezifikation): Der erste Eintrag muss ein Eintrag sein`MessageHeader`, der auf andere Ressourcen verweist. Ressourcen fehlen einzelne `request` Objekte, und das MessageHeader Ereignis bestimmt die Verarbeitungsaktionen.
+ **HealthLake Verarbeitung**: Konvertiert Nachrichtenpakete in Batch-Bundles, indem jedem Ressourceneintrag automatisch PUT-Operationen zugewiesen werden. Ressourcen werden unabhängig voneinander verarbeitet, ohne dass die Nachrichtensemantik oder die referenzielle Integrität erzwungen werden.
### Wichtige Einschränkungen
+ FHIR R4-Nachrichtenspezifische Verarbeitungsregeln werden nicht durchgesetzt
+ Keine ressourcenübergreifende Transaktionsintegrität
+ Ressourcenübergreifende Referenzen werden nicht validiert
+ Erfordert eine ausdrückliche Zulassungsliste für Konten
### Beispiel für eine Struktur eines Nachrichtenpakets
```
{
"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"}
}
]
}
```
**Anmerkung**
Jede Ressource wird unabhängig gespeichert, als ob sie über einzelne PUT-Operationen übermittelt würde. Wenn eine vollständige FHIR-Messaging-Semantik oder eine Überprüfung der referentiellen Integrität erforderlich sind, verarbeiten Sie Nachrichtenpakete vorab oder implementieren Sie vor der Übermittlung eine Validierung auf Anwendungsebene.
## Asynchrone Bundle-Transaktionen
AWS HealthLake unterstützt den asynchronen `Bundle` Typ`transaction`, mit dem Sie Transaktionen mit bis zu 500 Ressourcen einreichen können. Wenn Sie eine asynchrone Transaktion einreichen, wird sie zur Verarbeitung in eine HealthLake Warteschlange gestellt und sofort eine Abfrage-URL zurückgegeben. Sie können diese URL verwenden, um den Status zu überprüfen und die Antwort abzurufen. Dies folgt dem [asynchronen FHIR-Bundle-Muster](https://hl7.org/fhir/async-bundle.html).
**Wann sollten asynchrone Transaktionen verwendet werden**
+ Sie müssen mehr als 100 Ressourcen (synchrones Limit) in einer einzigen Transaktion einreichen.
+ Sie möchten vermeiden, dass Ihre Anwendung blockiert wird, während Sie auf den Abschluss der Transaktionsverarbeitung warten.
+ Sie müssen große Mengen verwandter Ressourcen mit besserem Durchsatz verarbeiten.
**Wichtig**
Die Umfrageergebnisse sind nach Abschluss der Transaktion 90 Tage lang verfügbar. Nach diesem Zeitraum von 90 Tagen gibt die Abfrage-URL keine Ergebnisse mehr zurück. Entwerfen Sie Ihre Integration so, dass Ergebnisse in diesem Fenster abgerufen und gespeichert werden.
**Anmerkung**
Der synchrone `Bundle` Typ unterstützt `transaction` weiterhin bis zu 100 Ressourcen und ist der Standardverarbeitungsmodus. Wenn Sie einen `Bundle` Typ `transaction` mit mehr als 100 Ressourcen ohne `Prefer: respond-async` Header einreichen, wird ein `422 Unprocessable Entity` Fehler HealthLake zurückgegeben. Pakete mit Typ `batch` werden für die asynchrone Verarbeitung nicht unterstützt — nur `Bundle` Typen `transaction` können asynchron übermittelt werden (mit bis zu 500 Vorgängen).
### Eine asynchrone Transaktion einreichen
Um eine asynchrone Transaktion einzureichen, senden Sie eine `POST` Anfrage mit dem Header an den Datenspeicher-Endpunkt. `Prefer: respond-async` Das Paket muss den Typ `transaction` haben. Bundles mit Typ `batch` werden für die asynchrone Bundle-Verarbeitung nicht unterstützt.
HealthLake führt bei der Einreichung erste Validierungen für das Bundle durch. Wenn die Überprüfung erfolgreich ist, wird HTTP 202 Accepted mit einem `content-location` Antwortheader HealthLake zurückgegeben, der die Abfrage-URL enthält.
**Um einen asynchronen Typ einzureichen `Bundle` `transaction`**
1. Senden Sie eine `POST` Anfrage an den HealthLake Datenspeicher-Endpunkt.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. Konstruieren Sie einen JSON-Text für die Anfrage mit dem Bundle-Typ`transaction`. Speichern Sie die Datei für dieses Verfahren unter`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. Senden Sie die Anfrage mit dem `Prefer: respond-async` Header. Der `Bundle` Transaktionstyp FHIR verwendet eine `POST` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei FHIR-Autorisierung. Im folgenden Codebeispiel wird das `curl` Befehlszeilentool zu Demonstrationszwecken verwendet.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
1. Bei erfolgreicher Übermittlung gibt der Server HTTP 202 Accepted zurück. Der `content-location` Antwortheader enthält die Abfrage-URL. Der Antworttext ist eine `OperationOutcome` Ressource.
```
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"
]
}
]
}
```
### Abfrage des Transaktionsstatus
Nachdem Sie eine asynchrone Transaktion eingereicht haben, verwenden Sie die Abfrage-URL aus dem `content-location` Antwort-Header, um den Transaktionsstatus zu überprüfen. Senden Sie eine `GET` Anfrage an die Abfrage-URL.
**Anmerkung**
Für SMART auf FHIR-fähigen Datenspeichern muss das Autorisierungstoken `read` Berechtigungen für den `Transaction` Ressourcentyp enthalten, um den Transaktionsstatus abzufragen. Weitere Informationen zu SMART auf FHIR-Bereichen finden Sie unter. [SMART auf FHIR OAuth 2.0-Bereichen, unterstützt von HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Senden Sie eine `GET` Anfrage an die Abfrage-URL. Im folgenden Beispiel wird das `curl` Befehlszeilentool verwendet.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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 ]
SMART bei FHIR-Autorisierung. Das Autorisierungstoken muss `read` Berechtigungen für den `Transaction` Ressourcentyp enthalten.
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--header 'Authorization: Bearer $SMART_ACCESS_TOKEN' \
--header 'Accept: application/json'
```
------
In der folgenden Tabelle werden die möglichen Antworten beschrieben.
**Antwortcodes für Abfragen**
| HTTP-Status | Bedeutung | Antworttext |
| --- | --- | --- |
| 202 Akzeptiert | Die Transaktion befindet sich in der Warteschlange | OperationOutcomemit der Diagnose „EINGEREICHT“ |
| 202 Akzeptiert | Die Transaktion wird bearbeitet | OperationOutcomemit der Diagnose „IN\$1PROGRESS“ |
| 200 OK | Die Transaktion wurde erfolgreich abgeschlossen | Bundlemit Typ transaction-response |
| 4xx/5xx | Die Transaktion ist fehlgeschlagen | OperationOutcomemit Fehlerdetails |
Die folgenden Beispiele zeigen die einzelnen Antworttypen.
**Transaktion in Warteschlange gestellt (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "SUBMITTED"
}
]
}
```
**Transaktionsverarbeitung (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "IN_PROGRESS"
}
]
}
```
**Transaktion abgeschlossen (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"
}
}
]
}
```
**Die Transaktion ist fehlgeschlagen (4xx/5xx)**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Transaction failed: conflict detected on resource Patient/example-id"
}
]
}
```
### Bestellung wird bearbeitet
Asynchrone Pakete des Typs `transaction` befinden sich in der Warteschlange, werden aber nicht in strikter Reihenfolge verarbeitet. HealthLake optimiert die Verarbeitung auf der Grundlage der verfügbaren Kapazität und der Systemlast.
**Wichtig**
Verlassen Sie sich nicht darauf, dass Transaktionen in der Reihenfolge verarbeitet werden, in der sie eingereicht wurden. Wenn Sie beispielsweise Transaktion A um 10:00 Uhr und Transaktion B um 10:01 Uhr einreichen, könnte Transaktion B vor Transaktion A abgeschlossen werden. Gestalten Sie Ihre Anwendung so, dass sie:
Erledigen Sie den out-of-order Abschluss.
Verwenden Sie die Abfrage-URL, um jede Transaktion unabhängig zu verfolgen.
Implementieren Sie eine Sequenzierung auf Anwendungsebene, wenn die Reihenfolge für Ihren Anwendungsfall von Bedeutung ist.
### Kontingente und Drosselung
Die folgenden Kontingente und Ratenbegrenzungen gelten für asynchrone Transaktionen.
**Kontingente für asynchrone Transaktionen**
| Kontingent | Wert | Einstellbar |
| --- | --- | --- |
| Maximale Anzahl von Vorgängen pro asynchroner Transaktion | 500 | Nein |
| Maximale Anzahl ausstehender Transaktionen pro Datenspeicher | 500 | Ja |
+ Für asynchrone Transaktionen gelten dieselben API-Ratenlimits, die unter [Servicekontingente](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas) definiert sind.
+ Für Abfragen des Transaktionsstatus gelten dieselben API-Ratenbegrenzungen wie für Read (`GET`) -Operationen auf FHIR-Ressourcen.
+ Wenn das Limit für ausstehende Transaktionen erreicht ist, wird bei nachfolgenden Einsendungen ein Fehler zurückgegeben, bis die vorhandenen Transaktionen abgeschlossen sind.
### Fehlerbehandlung
Bei einem „Transaction“ -Bundle werden alle im Paket enthaltenen FHIR-Ressourcen als atomare Operation verarbeitet. Alle Ressourcen in der Operation müssen erfolgreich sein, oder es werden keine Operationen im Paket verarbeitet.
Fehler lassen sich in zwei Kategorien einteilen: Übertragungsfehler, die synchron HealthLake zurückgegeben werden, und Verarbeitungsfehler, die Sie durch Abfragen abrufen.
**Fehler bei der Übermittlung**
HealthLake validiert das Paket bei der Übermittlung und gibt Fehler synchron zurück, bevor die Transaktion in die Warteschlange gestellt wird. Zu den Übermittlungsfehlern gehören Fehler bei der Validierung ungültiger FHIR-Ressourcen, nicht unterstützte Ressourcentypen, Überschreitung der Obergrenze von 500 Vorgängen und die Verwendung des `Prefer: respond-async` Headers mit Batch-Bundles. Wenn das Limit für ausstehende Transaktionen für den Datenspeicher erreicht wurde, HealthLake wird a zurückgegeben. `ThrottlingException` Wenn ein Übertragungsfehler auftritt, wird die Transaktion nicht in die Warteschlange gestellt.
**Fehler bei der Verarbeitung**
Verarbeitungsfehler treten auf, nachdem die Transaktion in die Warteschlange gestellt wurde, und werden über die Abfrage-URL zurückgegeben. Dazu gehören Transaktionskonflikte, bei denen eine Ressource, die Teil der Transaktion ist, durch einen anderen Vorgang geändert wurde, und Serverfehler während der Verarbeitung. Wenn ein Verarbeitungsfehler auftritt, werden keine Ressourcenmutationen für Ressourcen in der Transaktion vorgenommen. Die Abfrage-URL gibt eine `OperationOutcome` mit den Fehlerdetails zurück.
# Löschen einer FHIR-Ressource
Die `delete` FHIR-Interaktion entfernt eine vorhandene FHIR-Ressource aus einem HealthLake Datenspeicher. Weitere Informationen finden Sie [https://hl7.org/fhir/R4/http.html#delete](https://hl7.org/fhir/R4/http.html#delete)in der **FHIR RESTful R4-API-Dokumentation**.
**Um eine FHIR-Ressource zu löschen**
1. Sammeln HealthLake `region` und bewerten`datastoreId`. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Ermitteln Sie den FHIR-Typ, der gelöscht `Resource` werden soll, und erfassen Sie den zugehörigen `id` Wert. Weitere Informationen finden Sie unter [Ressourcentypen](reference-fhir-resource-types.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und `datastoreId` eine URL für die Anfrage. Geben Sie auch den `Resource` FHIR-Typ und den zugehörigen `id` Typ an. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Senden Sie die Anforderung . Die `delete` FHIR-Interaktion verwendet eine `DELETE` Anfrage mit entweder [AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) oder SMART bei der FHIR-Autorisierung. Im folgenden `curl` Beispiel wird eine vorhandene `Patient` FHIR-Ressource aus einem HealthLake Datenspeicher entfernt. Scrollen Sie über die Schaltfläche **Kopieren**, um das gesamte Beispiel anzuzeigen.
------
#### [ SigV4 ]
SigV4-Autorisierung
```
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'
```
Der Server gibt einen `204` HTTP-Statuscode zurück, der bestätigt, dass die Ressource aus dem HealthLake Datenspeicher entfernt wurde. Wenn eine Löschanforderung fehlschlägt, erhalten Sie eine `400` Reihe von HTTP-Statuscodes, die angeben, warum die Anforderung fehlgeschlagen ist.
------
#### [ SMART on FHIR ]
SMART on FHIR-Autorisierungsbeispiel für den [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyp.
```
{
"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\"]}"
}
```
Der Anrufer kann im Autorisierungs-Lambda Berechtigungen zuweisen. Weitere Informationen finden Sie unter [OAuth 2.0-Bereiche](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Melden Sie sich auf der Seite „[Abfrage ausführen](https://console.aws.amazon.com/healthlake/home#/crud)“ in der HealthLake Konsole an.
2. Treffen Sie im Abschnitt **Abfrageeinstellungen** die folgenden Optionen.
+ **Datenspeicher-ID** — Wählen Sie eine Datenspeicher-ID aus, um eine Abfragezeichenfolge zu generieren.
+ **Abfragetyp** — wählen Sie`Delete`.
+ **Ressourcentyp** — Wählen Sie den zu löschenden [FHIR-Ressourcentyp](reference-fhir-resource-types.md) aus.
+ **Ressourcen-ID** — geben Sie die FHIR-Ressourcen-ID ein.
3. Wählen Sie **Abfrage ausführen**.
------
## Löschen von FHIR-Ressourcen auf der Grundlage von Bedingungen
Bedingtes Löschen ist besonders nützlich, wenn Sie die spezifische FHIR-Ressourcen-ID nicht kennen, aber über andere identifizierende Informationen zu der Ressource verfügen, die Sie löschen möchten.
Mit dem bedingten Löschen können Sie eine vorhandene Ressource anhand von Suchkriterien und nicht anhand der logischen FHIR-ID löschen. Wenn der Server die Löschanforderung verarbeitet, führt er eine Suche mithilfe von Standardsuchfunktionen für den Ressourcentyp durch, um eine einzelne logische ID für die Anforderung aufzulösen.
### So funktioniert bedingtes Löschen
**Die Aktion des Servers hängt davon ab, wie viele Treffer er findet:**
1. **Keine Treffer**: Der Server versucht einen normalen Löschvorgang und reagiert entsprechend (404 Not Found für eine nicht existierende Ressource, 204 Kein Inhalt für bereits gelöschte Ressource)
1. **Eine Übereinstimmung**: Der Server führt eine normale Löschung der entsprechenden Ressource durch
1. **Mehrere Treffer**: Gibt den Fehler 412 Precondition Failed zurück, der darauf hinweist, dass die Kriterien des Clients nicht selektiv genug waren
### Reaktionsszenarien
AWS HealthLake verarbeitet bedingte Löschvorgänge mit den folgenden Antwortmustern:
**Erfolgreiche Operationen**
+ Wenn Ihre Suchkriterien erfolgreich eine einzelne aktive Ressource identifizieren, gibt das System nach Abschluss des Löschvorgangs **204 Kein Inhalt** zurück, genau wie bei Standardlöschvorgängen.
**ID-basiertes bedingtes Löschen**
Beim Ausführen eines bedingten Löschvorgangs auf der `id` Grundlage zusätzlicher Parameter (`createdAt`,`tag`, oder`_lastUpdated`):
+ **204 Kein Inhalt**: Die Ressource wurde bereits gelöscht
+ **404 Nicht gefunden**: Die Ressource existiert nicht
+ **409 Konflikt**: Die ID stimmt überein, aber andere Parameter stimmen nicht überein
**Non-ID-Based Bedingtes Löschen**
Wenn nicht `id` angegeben oder wenn andere Parameter verwendet werden als`createdAt`,`tag`, oder`_lastUpdated`:
+ **404 Nicht gefunden**: Keine Treffer gefunden
**Konfliktsituationen**
Verschiedene Szenarien führen zu den Antworten 412 Precondition Failed:
+ Mehrere Ressourcen entsprechen Ihren Suchkriterien (die Kriterien sind nicht spezifisch genug)
+ Versionskonflikte bei der Verwendung von ETag Headern mit `If-Match`
+ Ressourcenaktualisierungen, die zwischen Such- und Löschvorgängen auftreten
**Beispiel für ein erfolgreiches bedingtes Löschen**
Im folgenden Beispiel wird eine Patientenressource anhand bestimmter Kriterien gelöscht:
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
Mit dieser Anfrage wird eine Patientenressource gelöscht, wobei:
+ Der Name ist „Peter“
+ Geburtsdatum ist der 1. Januar 2000
+ Die Telefonnummer ist 1234567890
**Bewährte Methoden**
1. Verwenden Sie spezifische Suchkriterien, um Mehrfachübereinstimmungen und 412-Fehler zu vermeiden.
1. Ziehen Sie ETag Header für die Versionskontrolle in Betracht, wenn dies für gleichzeitige Änderungen erforderlich ist.
1. Gehen Sie angemessen mit Fehlerreaktionen um:
+ Für 404: Verfeinern Sie Ihre Suchkriterien
+ Für 412: Spezifizieren Sie die Kriterien oder lösen Sie Versionskonflikte
1. Bereiten Sie sich auf Zeitkonflikte in Umgebungen mit hoher Parallelität vor, in denen Ressourcen zwischen Such- und Löschvorgängen geändert werden können.
# Idempotenz und Parallelität
## Idempotenzschlüssel
AWS HealthLake unterstützt Idempotenzschlüssel für `POST` FHIR-Operationen und bietet so einen robusten Mechanismus zur Sicherstellung der Datenintegrität bei der Ressourcenerstellung. Durch die Aufnahme einer eindeutigen UUID als Idempotenzschlüssel in den Anforderungsheader können Anwendungen im Gesundheitswesen garantieren, dass jede FHIR-Ressource genau einmal erstellt wird, selbst in Szenarien mit Netzwerkinstabilität oder automatischen Wiederholungsversuchen.
Diese Funktion ist besonders wichtig für Gesundheitssysteme, in denen doppelte Patientenakten schwerwiegende Folgen haben könnten. Wenn eine Anfrage mit demselben Idempotenzschlüssel wie eine vorherige Anfrage eingeht, HealthLake wird die ursprüngliche Ressource zurückgegeben, anstatt ein Duplikat zu erstellen. Dies kann beispielsweise während einer Wiederholungsschleife oder aufgrund redundanter Anforderungspipelines auftreten. Die Verwendung des Idempotenzschlüssels ermöglicht HealthLake die Aufrechterhaltung der Datenkonsistenz und bietet gleichzeitig ein reibungsloses Erlebnis für Client-Anwendungen, die mit zeitweiligen Verbindungsproblemen umgehen.
### Implementierung
```
POST //Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
"resourceType": "Patient",
"name": [...]
}
```
### Reaktionsszenarien
Erste Anfrage (201 erstellt)
+ Neue Ressource wurde erfolgreich erstellt
+ Die Antwort enthält die Ressourcen-ID
Doppelte Anfrage (409-Konflikt)
+ Derselbe Idempotenzschlüssel erkannt
+ Die ursprüngliche Ressource wurde zurückgegeben
+ Es wurde keine neue Ressource erstellt
Ungültige Anfrage (400 Schlechte Anfrage)
+ Fehlerhafte UUID
+ Fehlende Pflichtfelder
### Bewährte Methoden
+ Generieren Sie eine eindeutige UUID für jede neue Ressourcenerstellung
+ Speichern Sie Idempotenzschlüssel für die Wiederholungslogik
+ Verwenden Sie ein konsistentes Schlüsselformat: UUID v4 wird empfohlen
+ Implementieren Sie es in Client-Anwendungen, die die Ressourcenerstellung übernehmen
**Anmerkung**
Diese Funktion ist besonders nützlich für Gesundheitssysteme, die eine strikte Datengenauigkeit erfordern und doppelte Patientenakten verhindern müssen.
## ETag in AWS HealthLake
AWS HealthLake dient ETags zur optimistischen Kontrolle der Parallelität in FHIR-Ressourcen und bietet so einen zuverlässigen Mechanismus zur Verwaltung gleichzeitiger Änderungen und zur Wahrung der Datenkonsistenz. An ETag ist ein eindeutiger Bezeichner, der für eine bestimmte Version einer Ressource steht und über HTTP-Header als Versionskontrollsystem fungiert. Beim Lesen oder Ändern von Ressourcen können ETags Anwendungen unbeabsichtigte Überschreibungen verhindern und die Datenintegrität sicherstellen, insbesondere in Szenarien mit potenziellen gleichzeitigen Aktualisierungen.
### Beispiel für eine Implementierung
```
// 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
```
### Reaktionsszenarien
Erfolgreicher Vorgang (200 OK oder 204 Kein Inhalt)
+ ETag entspricht der aktuellen Version
+ Der Vorgang wird wie vorgesehen fortgesetzt
Versionskonflikt (412-Vorbedingung fehlgeschlagen)
+ ETag entspricht nicht der aktuellen Version
+ Das Update wurde abgelehnt, um Datenverlust zu verhindern
### Bewährte Methoden
+ ETags In alle Aktualisierungs- und Löschvorgänge einbeziehen
+ Implementieren Sie die Wiederholungslogik zur Behandlung von Versionskonflikten
+ Verwenden Sie If-None-Match: \$1 für Szenarien create-if-not-exists
+ Überprüfen Sie immer die ETag Frische, bevor Sie Änderungen vornehmen
Dieses System zur Kontrolle der Parallelität ist für die Aufrechterhaltung der Integrität von Gesundheitsdaten unerlässlich, insbesondere in Umgebungen, in denen mehrere Benutzer oder Systeme auf dieselben Ressourcen zugreifen und diese ändern.