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.
# 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.