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 zum Versicherungsschutz 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}

Jede Anfrage unterstützt bis zu 500 Mitglieder mit einer maximalen Nutzlast von 5 MB.

Schnellstart

Gehen Sie wie folgt vor, um mit Bulk Member Match zu beginnen:

  1. Reichen Sie MemberBundles mithilfe des Group/$bulk-member-match Vorgangs eine Sammelabgleichsanfrage ein. Die Antwort enthält eine Job-ID.

  2. Rufen Sie den Auftragsstatus mithilfe der $bulk-member-match-status Operation ab, bis der Status ABGESCHLOSSEN lautet.

  3. Extrahieren Sie die MatchedMembers Gruppen-ID aus der abgeschlossenen Jobantwort.

  4. Exportieren Sie klinische Daten mithilfe der Group/$davinci-data-export Operation für die entsprechende Gruppe.

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 Zustimmung - provision.period Deckt das aktuelle Datum ab? Bei einem Fehler: ConsentConstrainedMembers.

  5. Erfolg — Alle Schecks 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):

  • Bereitstellungszeitraum: provision.period Deckt das aktuelle Datum ab? Wenn das aktuelle Datum vor period.start oder nach dem liegt period.end → ConsentConstrainedMembers.

Alle Prüfungen müssen bestanden werden, damit das Mitglied aufgenommen MatchedMembers und die Zustimmung gespeichert werden kann.

Anmerkung

Der Vorgang validiert den performer Verweis nicht anhand des patient Felds. Ein Elternteil oder Erziehungsberechtigter kann im Namen eines Angehörigen zustimmen.

In der folgenden Tabelle wird beschrieben, wie die Klassifizierung der Zustimmung die Platzierung der Mitglieder bestimmt:

Art der BereitstellungRichtlinie-URIStatusZeitraumErgebnis

permit

#regular

active

Deckt das aktuelle Datum ab

MatchedMembers (Zustimmung gespeichert)

permit

#sensitive

active

Deckt das aktuelle Datum ab

MatchedMembers (Zustimmung gespeichert)

permit

#regular oder #sensitive

active

Abgelaufen oder nicht gestartet

ConsentConstrainedMembers

deny

Beliebig

Beliebig

Beliebig

400 Schlechte Anfrage (Schritt 1)

permit

Endet nicht mit #regular oder #sensitive

Beliebig

Beliebig

400 Schlechte Anfrage (Schritt 1)

Beliebig

Beliebig

Nicht active

Beliebig

400 Schlechte Anfrage (Schritt 1)

Verhalten bei der Anpassung an die Abdeckung

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

  • Die performer Referenz wurde nicht gegengeprüft. patient Eine parent/guardian Zustimmung im Namen eines Angehörigen ist gültig und leitet das Mitglied nicht weiter. ConsentConstrainedMembers

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 Consent-Ressource 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). Diese Gruppe ist im Datenspeicher nicht instanziiert. Sie ist nur in der abgeschlossenen Jobantwort enthalten.

ConsentConstrainedMembers Group (Gruppieren)

Enthält Patientenreferenzen für Mitglieder, die erfolgreich zusammengebracht wurden (demografische Daten und Versicherungsschutz bestätigt), deren Zustimmung jedoch zum Zeitpunkt der Anfrage nicht eingehalten 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. Diese Gruppe ist im Datenspeicher nicht instanziiert. Sie ist nur in der abgeschlossenen Jobantwort enthalten.

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

  • 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

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 Einwilligungsquelle

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

provision.actor

Identifiziert die Ausgangs- und Empfängerzahler

Die erforderlichen Quell- und Empfängerakteure pro HREx-Profil fehlen oder sind nicht enthalten

provision.action

Bestätigt die Offenlegungsmaßnahme

Fehlender oder kein „Offenlegen“ -Code

status

Muss laut HRex IG „aktiv“ sein

Nicht „aktiv“ — gibt einen 400-Validierungsfehler zurück

Anmerkung

Consent.statusIst laut HRex IG auf „aktiv“ festgelegt. HealthLake erzwingt dies in Schritt 1 (Strukturvalidierung) und gibt einen Validierungsfehler von 400 zurück, wenn ein anderer Status angegeben wird. Non-active Die Zustimmung wird weder verarbeitet noch klassifiziert ConsentConstrainedMembers — sie wird im Voraus abgelehnt.

Passendes 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) übereinstimmt.

  • Bewertung der Zustimmung (Schritt 4) — Wird erst nach einem erfolgreichen eindeutigen Abgleich 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 die Verarbeitung eines bestimmten Elements fehlschlägt, wird der Vorgang mit den verbleibenden Mitgliedern fortgesetzt und enthält Fehlerdetails mit 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.