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 |
|---|---|---|---|
|
Patient |
Ja |
Patientenressource mit demografischen Informationen für das abzugleichende Mitglied. |
|
Abdeckung |
Ja |
Informationsquelle, die für den Abgleich mit vorhandenen Datensätzen verwendet wird. |
|
Abdeckung |
Nein |
Coverage-Ressource, die während des Abgleichs verknüpft werden soll. |
|
Zustimmung |
Ja |
Die Zustimmungsressource für Autorisierungszwecke wird ebenfalls gespeichert. Dies unterscheidet sich von einzelnen Vorgängen |
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.
Strukturvalidierung — Entspricht das den MemberBundle erforderlichen Profilen? Bei einem Fehler: Fehler (in keiner Gruppe).
Patientenabgleich — Kann ich Patienten HealthLake finden, die den eingereichten demografischen Daten entsprechen? Bei einem Fehler: NonMatchedMembers.
Bestätigung des Versicherungsschutzes — Kann auf genau einen Patienten mit gültigem Versicherungsschutz HealthLake eingegrenzt werden CoverageToMatch? Bei einem Fehler: NonMatchedMembers.
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.
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.statusEntspricht „aktiv“? Wenn nicht → ConsentConstrainedMembers.Test 2 — Bereitstellungszeitraum:
provision.periodDeckt das aktuelle Datum ab? Wenn das aktuelle Datum vorperiod.startoder nach dem liegtperiod.end→ ConsentConstrainedMembers.Test 3 — Überprüfung durch den Ausführenden: Kann die
Consent.performerReferenz 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).
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:
POST [base]/Group/{id}/$member-remove— Mitglieder als inaktiv markierenPUT [base]/Group/{id}— den Gruppenstatus auf „endgültig“ aktualisierenPOST [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... |
|---|---|---|
| Demografische Suche | Fehlen |
| Demografische Suche | Fehlt (mindestens eine erforderlich) |
| Demografische Suche | Fehlen |
| Demografische Suche; falls nicht, wurde die Erweiterung Birth Sex verwendet | Weder Geschlecht noch Geburtsgeschlecht vorhanden (hrex-pat-1) |
| 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... |
|---|---|---|
| Bestätigt, dass die Berichterstattung umsetzbar ist | Fehlen |
| Verbindet den Versicherungsschutz mit einem Patientenkandidaten | Fehlen |
| Begriffsklärung, wenn mehrere Kandidaten existieren | Fehlt oder es gibt mehr als einen Zahler |
| Bestätigt die Beziehung zwischen Abonnent und Begünstigtem | Fehlen |
| Primärer Begriffsklärungsschlüssel | Keiner von beiden anwesend |
Zustimmung
| Feld | Wie HealthLake benutzt es | Die Überprüfung ist fehlgeschlagen, wenn... |
|---|---|---|
| Bestätigt, dass der Geltungsbereich der Einwilligung die Privatsphäre des Patienten ist | Fehlender oder kein Datenschutzcode für Patienten |
| Bestätigt die Klassifizierung der Offenlegung | Fehlen |
| Identifiziert den Einwilligungssubjekt | Fehlen |
| Identifiziert, wer zustimmt | Fehlen |
| Dokumentiert die Quelle der Zustimmung | Fehlen |
| Legt den Umfang der gemeinsamen Nutzung von Daten fest | Fehlt oder URI endet nicht mit #regular oder #sensitive |
| Muss laut HREx Consent-Profil „Permit“ sein | „Zulassen“ fehlt oder nicht (einschließlich „verweigern“) |
| In Schritt 4 im Hinblick auf eine Prüfung mit eingeschränktem Einverständnis bewertet | Fehlt oder nicht start/end |
| 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) undidentifier(falls vorhanden, optional).Disambiguierung des Erfassungsbereichs (Schritt 3) — Wenn mehrere Patientenkandidaten gefunden werden,
CoverageToMatchwird diese Methode verwendet, um auf einen Patienten einzugrenzen. Eine Abdeckung ist „gültig“, wenn im Datenspeicher eine aktive Coverage-Ressource vorhanden ist, die mitsubscriberIdoderidentifier(Typ MB) UND übereinstimmt.payorBewertung 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
MemberBundlebei einem Patienten derbirthDateParameter 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-matchOperation für HealthLake— Vorgang zum Abgleich einzelner Mitglieder.
FHIR R4-Betrieb $davinci-data-export für HealthLake— Massendatenexport mithilfe von Gruppenressourcen.
FHIR R4 für $operations HealthLake— Vollständige Liste der unterstützten Operationen.