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. # `$bulk-member-match-Operation` für HealthLake AWS HealthLake unterstützt den `$bulk-member-match` Vorgang zur asynchronen Verarbeitung von Matchanfragen für mehrere Mitglieder. Dieser Vorgang ermöglicht es Organisationen im Gesundheitswesen, die eindeutigen Identifikatoren von Hunderten von Mitgliedern in verschiedenen Gesundheitssystemen effizient abzugleichen, indem demografische Informationen und Informationen zur Deckung in einer einzigen Sammelanfrage verwendet werden. [Diese Funktion ist für den groß angelegten Datenaustausch zwischen Kostenträgern, für die Umstellung von Mitgliedern und die Einhaltung der CMS-Anforderungen unerlässlich und entspricht der FHIR-Spezifikation.](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html) **Anmerkung** Die `$bulk-member-match` Operation basiert auf einer zugrunde liegenden FHIR-Spezifikation, die sich derzeit in der Erprobung befindet und sich ändern kann. Im Zuge der Weiterentwicklung der Spezifikation werden das Verhalten und die Schnittstelle dieser API entsprechend aktualisiert. Entwicklern wird empfohlen, die HealthLake AWS-Versionshinweise und die entsprechenden Aktualisierungen der FHIR-Spezifikation zu verfolgen, um über alle Änderungen, die sich auf ihre Integrationen auswirken könnten, auf dem Laufenden zu bleiben. Dieser Vorgang ist besonders nützlich, wenn Sie: + Führen Sie während der offenen Anmeldezeiträume einen maßstabsgetreuen Abgleich der Mitglieder durch + Erleichtern Sie den Massenwechsel zwischen den Kostenträgern + Support umfangreicher CMS-Compliance-Datenaustauschanforderungen + Passen Sie Mitgliedskohorten aus allen Gesundheitsnetzwerken effizient an + Reduzieren Sie API-Aufrufe und verbessern Sie die betriebliche Effizienz bei Matching-Szenarien mit hohem Volumen ## Usage Der `$bulk-member-match` Vorgang ist ein asynchroner Vorgang, der mit der POST-Methode für Gruppenressourcen aufgerufen wird: ``` POST [base]/Group/$bulk-member-match ``` Nachdem Sie eine Sammelabgleichsanfrage eingereicht haben, können Sie den Auftragsstatus wie folgt abfragen: ``` GET [base]/$bulk-member-match-status/{jobId} ``` ## Unterstützte Parameter HealthLake unterstützt die folgenden `$bulk-member-match` FHIR-Parameter: | Parameter | Typ | Erforderlich | Description | | --- | --- | --- | --- | | `MemberPatient` | Patient | Ja | Patientenressource mit demografischen Informationen für das abzugleichende Mitglied. | | `CoverageToMatch` | Abdeckung | Ja | Informationsquelle, die für den Abgleich mit vorhandenen Datensätzen verwendet wird. | | `CoverageToLink` | Abdeckung | Nein | Coverage-Ressource, die während des Abgleichs verknüpft werden soll. | | `Consent` | Zustimmung | Ja | Die Zustimmungsressource für Autorisierungszwecke wird ebenfalls gespeichert. Dies unterscheidet sich von einzelnen Vorgängen`$member-match`, bei denen *keine* Zustimmung erforderlich ist. | ## POST-Anfrage zur Einreichung eines Match-Jobs für mehrere Mitglieder Das folgende Beispiel zeigt eine POST-Anfrage zum Einreichen eines Match-Jobs für mehrere Mitglieder. Jedes Mitglied ist in einen `MemberBundle` Parameter eingeschlossen, der die erforderlichen `MemberPatient``CoverageToMatch`, und `Consent` Ressourcen sowie einen optionalen Wert enthält`CoverageToLink`. ``` POST [base]/Group/$bulk-member-match Content-Type: application/fhir+json { "resourceType": "Parameters", "parameter": [ { "name": "MemberBundle", "part": [ { "name": "MemberPatient", "resource": { "resourceType": "Patient", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-0" } ], "name": [ { "family": "Smith", "given": ["James"] } ], "gender": "male", "birthDate": "1950-01-01" } }, { "name": "CoverageToMatch", "resource": { "resourceType": "Coverage", "status": "active", "identifier": [ { "system": "http://example.org/coverage-id", "value": "cov-0" } ], "subscriberId": "sub-0", "beneficiary": { "reference": "Patient/patient123" }, "relationship": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" } ] }, "payor": [ { "reference": "Organization/org123" } ] } }, { "name": "Consent", "resource": { "resourceType": "Consent", "status": "active", "scope": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/consentscope", "code": "patient-privacy" } ] }, "category": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "IDSCL" } ] } ], "patient": { "reference": "Patient/patient123" }, "performer": [ { "reference": "Patient/patient123" } ], "sourceReference": { "reference": "http://example.org/DocumentReference/consent-source" }, "policy": [ { "uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular" } ], "provision": { "type": "permit", "period": { "start": "2024-01-01", "end": "2025-12-31" }, "actor": [ { "role": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type", "code": "performer" } ] }, "reference": { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "9876543210" }, "display": "Old Health Plan" } }, { "role": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "IRCP" } ] }, "reference": { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "0123456789" }, "display": "New Health Plan" } } ], "action": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/consentaction", "code": "disclose" } ] } ] } } }, { "name": "CoverageToLink", "resource": { "resourceType": "Coverage", "status": "active", "identifier": [ { "system": "http://example.org/coverage-link-id", "value": "cov-link-0" } ], "subscriberId": "new-sub-0", "beneficiary": { "reference": "Patient/patient123" }, "relationship": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" } ] }, "payor": [ { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "0123456789" }, "display": "New Health Plan" } ] } } ] } ] } ``` ## Antwort auf den Auftrag mit Ausgabe abgeschlossen Wenn der Job abgeschlossen ist, enthält die Antwort Job-Metadaten und eine FHIR-Parameter-Ressource, die drei Gruppenressourcen enthält, die die Vergleichsergebnisse kategorisieren. ``` { "datastoreId": "datastoreId", "jobId": "jobId", "status": "COMPLETED", "submittedTime": "2026-03-20T18:45:26.321Z", "numberOfMembers": 3, "numberOfMembersProcessedSuccessfully": 3, "numberOfMembersWithCustomerError": 0, "numberOfMembersWithServerError": 0, "output": { "resourceType": "Parameters", "meta": { "profile": [ "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-parameters-multi-member-match-bundle-out" ] }, "parameter": [ { "name": "MatchedMembers", "resource": { "resourceType": "Group", "id": "group1", "text": { "status": "generated", "div": "
Matched members group
" }, "contained": [ { "resourceType": "Patient", "id": "1", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-0" } ], "name": [ { "family": "Smith", "given": ["James"] } ], "gender": "male", "birthDate": "1950-01-01" } ], "type": "person", "actual": true, "code": { "coding": [ { "system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS", "code": "match", "display": "Matched" } ] }, "quantity": 1, "member": [ { "entity": { "extension": [ { "url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters", "valueReference": { "reference": "#1" } } ], "reference": "Patient/patient123" } } ] } }, { "name": "NonMatchedMembers", "resource": { "resourceType": "Group", "id": "Group2", "text": { "status": "generated", "div": "
Non-matched members group
" }, "contained": [ { "resourceType": "Patient", "id": "1", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-501" } ], "name": [ { "family": "Carter", "given": ["Emily"] } ], "gender": "female", "birthDate": "1985-06-15" } ], "type": "person", "actual": true, "code": { "coding": [ { "system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS", "code": "nomatch", "display": "Not Matched" } ] }, "quantity": 1, "member": [ { "entity": { "extension": [ { "url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters", "valueReference": { "reference": "#1" } } ], "reference": "Patient/patient123" } } ] } }, { "name": "ConsentConstrainedMembers", "resource": { "resourceType": "Group", "id": "group3", "text": { "status": "generated", "div": "
Consent constrained members group
" }, "contained": [ { "resourceType": "Patient", "id": "1", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-502" } ], "name": [ { "family": "Nguyen", "given": ["David"] } ], "gender": "male", "birthDate": "1972-11-22" } ], "type": "person", "actual": true, "code": { "coding": [ { "system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS", "code": "consentconstraint", "display": "Consent Constraint" } ] }, "quantity": 1, "member": [ { "entity": { "extension": [ { "url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters", "valueReference": { "reference": "#1" } } ], "reference": "Patient/123" } } ] } } ] } } ``` ## Wie werden Mitglieder HealthLake in Ausgabegruppen eingeteilt Jedes in einer `$bulk-member-match` Anfrage eingereichte Mitglied wird über eine sequentielle Pipeline bewertet. Das Ergebnis jedes Schritts bestimmt, welcher Output-Gruppe das Mitglied zugeordnet wird. 1. **Strukturvalidierung** — Entspricht das den MemberBundle erforderlichen Profilen? Bei einem Fehler: Fehler (in keiner Gruppe). 1. **Patientenabgleich** — Kann ich Patienten HealthLake finden, die den eingereichten demografischen Daten entsprechen? Bei einem Fehler: NonMatchedMembers. 1. **Bestätigung des Versicherungsschutzes** — Kann auf genau einen Patienten mit gültigem Versicherungsschutz HealthLake eingegrenzt werden CoverageToMatch? Bei einem Fehler: NonMatchedMembers. 1. **Bewertung der Einwilligung** - Ist die eingereichte Einwilligung derzeit ehrenhaft? (Status = aktiv, Zeitraum deckt das aktuelle Datum ab, der Ausführende kann bestätigt werden). Bei einem Fehler: ConsentConstrainedMembers. 1. **Erfolg** — Alle Prüfungen wurden bestanden. Die Zustimmung wird im Datenspeicher gespeichert. Mitglied hinzugefügt. MatchedMembers **Grundprinzip:** Ein Mitglied kann nur an einem Zielort erscheinen. Der erste fehlgeschlagene Schritt bestimmt die Platzierung. Mitglieder, die die Stufen 2 oder 3 nicht bestehen, werden niemals in diese Gruppe ConsentConstrainedMembers aufgenommen. Diese Gruppe ist ausschließlich für Mitglieder bestimmt, die erfolgreich gematcht haben, deren Zustimmung jedoch nicht eingehalten werden kann. **Einzelheiten zur Bewertung der Einwilligung (Schritt 4):** + **Test 1 — Zustimmungsstatus:** `Consent.status` Entspricht „aktiv“? Wenn nicht → ConsentConstrainedMembers. + **Test 2 — Bereitstellungszeitraum:** `provision.period` Deckt das aktuelle Datum ab? Wenn das aktuelle Datum vor `period.start` oder nach dem liegt `period.end` → ConsentConstrainedMembers. + **Test 3 — Überprüfung durch den Ausführenden:** Kann die `Consent.performer` Referenz validiert werden? Wenn die referenzierte Ressource nicht im Datenspeicher gefunden wird oder nicht mit dem entsprechenden Patienten verknüpft ist →. ConsentConstrainedMembers Alle Prüfungen müssen bestanden werden, damit das Mitglied aufgenommen MatchedMembers und die Zustimmung gespeichert wird. ## Verhalten bei der Anpassung an die Deckung Beim Mitgliederabgleich `CoverageToMatch` wird nur anhand des Datenspeichers des antwortenden Zahlers validiert. `CoverageToLink`gehört dem new/requesting Zahler und wird *nicht* anhand des Datenspeichers des alten Zahlers validiert. Die Aufnahme `CoverageToLink` in die Anfrage hat keinen Einfluss auf die passenden Ergebnisse. Jede Kombination aus Patient und Versicherungsschutz in der Anfrage wird unabhängig bearbeitet. Derselbe Patient kann mehrfach mit unterschiedlichen Versicherungsplänen eingereicht werden, und jeder Eintrag erhält sein eigenes Ergebnis, das auf seinem spezifischen Versicherungsschutz basiert. ## Umgang mit Referenzen durch den Consent Performer Der neue Zahler kann eine vorläufige oder lokale Patientenreferenz einsenden `Consent.performer` (z. B. dieselbe Referenznummer, die in verwendet wurde`Consent.patient`). HealthLake löst diese Referenzen automatisch auf: + `Consent.performer`Enthält dieselbe lokale Referenz wie`Consent.patient`, HealthLake ersetzt sie nach erfolgreichem Abgleich durch die tatsächlich zugeordnete Patientenreferenz. + HealthLake unterstützt Ausführende Referenzen der Typen Patient RelatedPerson, Praktiker und Organisation (sowohl direkte Verweise als auch Verweise auf logische Identifikatoren). PractitionerRole + Schlägt die Überprüfung des Ausführenden fehl (die Ressource wurde nicht gefunden oder ist dem entsprechenden Patienten nicht zugeordnet), wird das Mitglied hinzugefügt, ConsentConstrainedMembers anstatt einen Fehler zurückzugeben. ## Ressourcen der Output-Gruppe Der abgeschlossene Job gibt eine Parameter-Ressource zurück, die drei Gruppenressourcen enthält: **MatchedMembers Group (Gruppieren)** Enthält Patientenreferenzen für alle Mitglieder, die erfolgreich zugeordnet wurden und deren Einwilligung zum Zeitpunkt der Anfrage aktiv und gültig ist. Die Zustimmungsressource wird für jedes zugeordnete Mitglied erstellt und im Datenspeicher gespeichert. Diese Gruppe wird im Datenspeicher instanziiert und kann direkt mit verwendet werden. `$davinci-data-export` **NonMatchedMembers Group (Gruppieren)** Enthält Verweise auf Mitglieder, bei denen keine eindeutige Übereinstimmung gefunden wurde. Ein Mitglied wird hier platziert, wenn kein Patient im Datenspeicher den angegebenen demografischen Daten entspricht, kein gültiger Versicherungsschutz für einen passenden Patientenkandidaten besteht oder wenn mehrere Patienten den demografischen Daten entsprechen und mehrere Patienten einen gültigen Versicherungsschutz haben (mehrdeutig). **ConsentConstrainedMembers Group (Gruppieren)** Enthält Patientenreferenzen für Mitglieder, die erfolgreich zugeordnet wurden (demografische Daten und Versicherungsschutz bestätigt), deren Zustimmung jedoch zum Zeitpunkt der Anfrage nicht berücksichtigt werden kann. Die Zustimmungsressource wird *nicht für Mitglieder* gespeichert, deren Einwilligung eingeschränkt ist. Die identifizierte Mitgliedsidentität (MemberIdentifier und MemberId) ist weiterhin enthalten, sodass der anfragende Zahler weiß, für wen die Einschränkung gilt. Das `Group.quantity` Feld enthält die Gesamtzahl der Mitglieder in jeder ihrer jeweiligen Gruppen. **Referenzen der Gruppenmitglieder:** + `Group.member.entity.reference`— Für MatchedMembers und ConsentConstrainedMembers, enthält die Patienten-ID des entsprechenden Mitglieds im System des antwortenden Kostenträgers. Für NonMatchedMembers, verweist auf den enthaltenen Eingabepatienten. + `Group.member.entity.extension (base-ext-match-parameters)`— Enthält die Patienten-ID aus der ursprünglichen Eingabeanfrage (die vom anfragenden Zahler übermittelte ID, abgeleitet von`Patient.id`,`Coverage.beneficiary.reference`, oder`Consent.patient.reference`). ## Consent-Patient Verknüpfung **Wichtig** In der gespeicherten Einwilligungsressource wird die Patientenreferenz genau so gespeichert, wie sie vom anfragenden Zahler übermittelt wurde. HealthLake aktualisiert das Patientenfeld der Einwilligung nicht automatisch so, dass es auf den entsprechenden Patienten im Empfangsdatenspeicher verweist. Um eine gespeicherte Einwilligung mit dem entsprechenden Patienten zu verknüpfen, verwenden Sie die Jobausgabe: Jedes Mitglied der MatchedMembers Gruppe `member.entity.reference` zeigt mit einem Zeichen auf den entsprechenden Patienten und mit einem `member.entity.extension` (`base-ext-match-parameters`) auf den enthaltenen Eingabepatienten. Cross-reference diese mit dem Patientenfeld der Einwilligung, um das Mapping in Ihrer Anwendungsebene zu erstellen. ## Was wird gespeichert und was ist vorübergehend In der folgenden Tabelle wird dokumentiert, was während der `$bulk-member-match` Verarbeitung im Datenspeicher HealthLake verbleibt und was nur in der Job-Antwort enthalten ist: | Ressource | Gespeichert? | Über REST abfragbar? | Hinweise | | --- | --- | --- | --- | | MemberPatient (Eingabe) | Nein | Nein | Wird nur für den Abgleich verwendet; nicht dauerhaft | | CoverageToMatch (Eingabe) | Nein | Nein | Wird nur zur Bestätigung der Deckung verwendet | | CoverageToLink (Eingabe) | Nein | Nein | Nicht anhand des Datenspeichers validiert; gehört dem neuen Zahler | | **Zustimmung (übereinstimmende Mitglieder)** | **Ja** | Ja — GET [base] /Consent/ {id} | Wird so gespeichert, wie es vom anfragenden Zahler eingegangen ist | | Zustimmung (eingeschränkte Mitglieder) | Nein | Nein | Nicht gespeichert. Die Identität des Mitglieds ist immer noch in der Antwort enthalten. | | **MatchedMembers Gruppe (Ausgabe)** | **Ja** | Ja — GET [base] /Group/ {id} | Instanziiert; nutzbar mit $davinci-data-export | | NonMatchedMembers Gruppe | Nein | Nein | Nur Antwort auf den Job | | ConsentConstrainedMembers Gruppe | Nein | Nein | Nur Antwort auf den Job | ## Integration mit $davinci-data-export Die von zurückgegebene MatchedMembers Gruppenressource `$bulk-member-match` kann direkt mit dem `$davinci-data-export` Vorgang zum Abrufen von Massendaten von Mitgliedern verwendet werden: ``` POST [base]/Group/{matched-group-id}/$davinci-data-export GET [base]/Group/{matched-group-id} ``` Diese Integration ermöglicht effiziente Workflows, bei denen Sie zuerst übereinstimmende Mitglieder in großen Mengen identifizieren und dann ihre vollständigen Gesundheitsdaten mithilfe der resultierenden Gruppenressource exportieren. ### Verwenden Sie $member-remove vor dem Export Wenn Sie nach dem Abgleich bestimmte Mitglieder vom Export ausschließen müssen (z. B. wenn ein Mitglied die Zustimmung zwischen dem Abgleich und dem Export widerruft), verwenden `$member-remove` Sie dies für die Gruppe. MatchedMembers **Wichtig** Wenn Sie ein Mitglied über entfernen, wird das Mitglied in der Gruppe als inaktiv `$member-remove` markiert, inaktive Mitglieder werden jedoch `$davinci-data-export` erst ausgeschlossen, nachdem die Gruppe auf den Status „Endgültig“ aktualisiert wurde. Wenn Sie eine Gruppe aufrufen`$davinci-data-export`, die immer noch den Standardstatus hat, werden entfernte Mitglieder möglicherweise immer noch in den Exportergebnissen angezeigt. Arbeitsablauf: 1. `POST [base]/Group/{id}/$member-remove`— Mitglieder als inaktiv markieren 1. `PUT [base]/Group/{id}`— den Gruppenstatus auf „endgültig“ aktualisieren 1. `POST [base]/Group/{id}/$davinci-data-export`— Der Export schließt jetzt entfernte Mitglieder aus ## Leistungsmerkmale Der `$bulk-member-match` Vorgang ist für die Verarbeitung großer Datenmengen konzipiert und läuft asynchron: + **Parallelität**: Maximal 5 gleichzeitige Operationen pro Datenspeicher. + **Skalierbarkeit**: Verarbeitet bis zu 500 Mitglieder pro Anfrage (Nutzlastlimit von 5 MB). + **Parallele Operationen**: Kompatibel mit gleichzeitigen Import-, Export- oder Massenlöschvorgängen. ## Autorisierung Die API verwendet SMART auf dem FHIR-Autorisierungsprotokoll mit den folgenden erforderlichen Bereichen: + `system/Patient.read`— Erforderlich, um Patientenressourcen zu suchen und abzugleichen. + `system/Coverage.read`— Erforderlich, um die Versicherungsinformationen zu überprüfen. + `system/Group.write`— Erforderlich, um Ressourcen für Ergebnisgruppen zu erstellen. + `system/Organization.read`— Befriedigend, erforderlich, wenn sich der Versicherungsschutz auf Organisationen bezieht. + `system/Practitioner.read`— Befriedigend, erforderlich, wenn sich der Versicherungsschutz auf Praktiker bezieht. + `system/PractitionerRole.read`— Befristet, erforderlich, wenn sich der Versicherungsschutz auf die Rollen von Praktikern bezieht. + `system/Consent.write`— Befriedigend, erforderlich, wenn Ressourcen für die Einwilligung bereitgestellt werden. Der Vorgang unterstützt auch die AWS IAM Signature Version 4 (Sigv4) -Autorisierung für programmatischen Zugriff. ## Regeln für die Validierung In Schritt 1 werden jeweils MemberBundle die folgenden Validierungsregeln angewendet. Mitglieder, die die Überprüfung nicht bestehen, werden als Fehler gemeldet und erscheinen in keiner Ausgabegruppe. ### MemberPatient | Feld | Wie HealthLake benutzt es | Die Überprüfung ist fehlgeschlagen, wenn... | | --- | --- | --- | | `name.family` | Demografische Suche | Fehlen | | `name.given` | Demografische Suche | Fehlt (mindestens eine erforderlich) | | `birthDate` | Demografische Suche | Fehlen | | `gender` | Demografische Suche; falls nicht, wurde die Erweiterung Birth Sex verwendet | Weder Geschlecht noch Geburtsgeschlecht vorhanden (hrex-pat-1) | | `identifier` | Wird in die Suche aufgenommen, sofern vorhanden; verbessert das Selbstvertrauen | Verursacht niemals Fehler (optional) | ### CoverageToMatch / CoverageToLink | Feld | Wie HealthLake benutzt es | Die Überprüfung ist fehlgeschlagen, wenn... | | --- | --- | --- | | `status` | Bestätigt, dass die Berichterstattung umsetzbar ist | Fehlen | | `beneficiary` | Verbindet den Versicherungsschutz mit einem Patientenkandidaten | Fehlen | | `payor` | Begriffsklärung, wenn mehrere Kandidaten existieren | Fehlt oder es gibt mehr als einen Zahler | | `relationship` | Bestätigt die Beziehung zwischen Abonnent und Begünstigtem | Fehlen | | `identifier (MB) or subscriberId` | Primärer Begriffsklärungsschlüssel | Keiner von beiden anwesend | ### Zustimmung | Feld | Wie HealthLake benutzt es | Die Überprüfung ist fehlgeschlagen, wenn... | | --- | --- | --- | | `scope` | Bestätigt, dass der Geltungsbereich der Einwilligung die Privatsphäre des Patienten ist | Fehlender oder kein Datenschutzcode für Patienten | | `category` | Bestätigt die Klassifizierung der Offenlegung | Fehlen | | `patient` | Identifiziert den Einwilligungssubjekt | Fehlen | | `performer` | Identifiziert, wer zustimmt | Fehlen | | `sourceReference` | Dokumentiert die Quelle der Zustimmung | Fehlen | | `policy.uri` | Legt den Umfang der gemeinsamen Nutzung von Daten fest | Fehlt oder URI endet nicht mit \#regular oder \#sensitive | | `provision.type` | Muss laut HREx Consent-Profil „Permit“ sein | „Zulassen“ fehlt oder nicht (einschließlich „verweigern“) | | `provision.period` | In Schritt 4 im Hinblick auf eine Prüfung mit eingeschränktem Einverständnis bewertet | Fehlt oder nicht start/end | | `status` | In Schritt 4 bewertet (NICHT Schritt 1) | Führt niemals zu einem Fehler in Schritt 1 — HealthLake akzeptiert jeden gültigen Status und bewertet in Schritt 4 | **Anmerkung** Das HREx Consent-Profil definiert den Status mit dem festen Wert „aktiv“. HealthLake Diese Einschränkung wird bewusst gelockert, sodass eine Zustimmung, die nicht aktiv ist, eine aussagekräftige Einstufung (ConsentConstrainedMembers) erhält und nicht pauschal abgewiesen wird. ## Übereinstimmendes Verhalten + **Patientensuche (Schritt 2)** — HealthLake sucht mit `name.family` \+ `name.given` (exakt, ohne Berücksichtigung von Groß- und Kleinschreibung), `birthDate` (exakt), `gender` (exakt; Geburtsgeschlecht wird verwendet, wenn das Geschlecht fehlt) und `identifier` (falls vorhanden, optional). + **Disambiguierung des Erfassungsbereichs (Schritt 3)** — Wenn mehrere Patientenkandidaten gefunden werden, `CoverageToMatch` wird diese Methode verwendet, um auf einen Patienten einzugrenzen. Eine Abdeckung ist „gültig“, wenn im Datenspeicher eine aktive Coverage-Ressource vorhanden ist, die mit `subscriberId` oder `identifier` (Typ MB) UND übereinstimmt. `payor` + **Bewertung der Zustimmung (Schritt 4)** — Wird erst nach einem erfolgreichen eindeutigen Match durchgeführt. Einzelheiten zur Bewertung der Einwilligung finden Sie weiter oben. ## Fehlerbehandlung Der Vorgang behandelt die folgenden Fehlerbedingungen: + **400 Bad Request**: Ungültiges Anforderungsformat, fehlende erforderliche Parameter oder die Nutzlast überschreitet die Größenbeschränkungen (500 Mitglieder oder 5 MB). + **422 Unverarbeitbare Entität**: Verarbeitungsfehler bei der Auftragsausführung. + **Fehler einzelner** Mitglieder: Wenn ein bestimmtes Mitglied die Verarbeitung nicht durchführt, wird der Vorgang mit den verbleibenden Mitgliedern fortgesetzt und enthält Fehlerdetails in der NonMatchedMembers Gruppe mit den entsprechenden Ursachencodes. Beispiel: Wenn `MemberBundle` bei einem Patienten der `birthDate` Parameter fehlt, wird der folgende Fehler zurückgegeben: ``` "errors": [ { "memberIndex": 1, "jsonBlob": { "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "invalid", "diagnostics": "MemberPatient.birthDate is required" } ], "statusCode": 400 } } ] ``` Fehlerdetails sind über den Endpunkt für die Statusabfrage verfügbar und beinhalten: + `numberOfMembersWithCustomerError`: Anzahl der Mitglieder mit Überprüfungs- oder Eingabefehlern. + `numberOfMembersWithServerError`: Anzahl der Mitglieder mit serverseitigen Verarbeitungsfehlern. ## Zugehörige -Vorgänge + [`$member-match`Operation für HealthLake](reference-fhir-operations-member-match.md)— Vorgang zum Abgleich einzelner Mitglieder. + [FHIR R4-Betrieb `$davinci-data-export` für HealthLake](reference-fhir-operations-davinci-data-export.md)— Massendatenexport mithilfe von Gruppenressourcen. + [FHIR R4 für `$operations` HealthLake](reference-fhir-operations.md)— Vollständige Liste der unterstützten Operationen.