View a markdown version of this page

$bulk-member-match-Operation für HealthLake - AWS HealthLake

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.

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 MemberPatientCoverageToMatch, und Consent Ressourcen sowie einen optionalen Wert enthältCoverageToLink.

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": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Matched members group</div>" }, "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": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Non-matched members group</div>" }, "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": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Consent constrained members group</div>" }, "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).

  2. Patientenabgleich — Kann ich Patienten HealthLake finden, die den eingereichten demografischen Daten entsprechen? Bei einem Fehler: NonMatchedMembers.

  3. Bestätigung des Versicherungsschutzes — Kann auf genau einen Patienten mit gültigem Versicherungsschutz HealthLake eingegrenzt werden CoverageToMatch? Bei einem Fehler: NonMatchedMembers.

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

  5. 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. CoverageToLinkgehö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 wurdeConsent.patient). HealthLake löst diese Referenzen automatisch auf:

  • Consent.performerEnthält dieselbe lokale Referenz wieConsent.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 vonPatient.id,Coverage.beneficiary.reference, oderConsent.patient.reference).

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

  2. PUT [base]/Group/{id}— den Gruppenstatus auf „endgültig“ aktualisieren

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

FeldWie HealthLake benutzt esDie Ü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

FeldWie HealthLake benutzt esDie Ü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

FeldWie HealthLake benutzt esDie Ü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.