View a markdown version of this page

Operazione $bulk-member-match per HealthLake - AWS HealthLake
UtilizzoParametri supportatiRichiesta POST per inviare in blocco un'offerta di lavoro abbinata a un membroRisposta al lavoro completata con outputCome HealthLake classifica i membri in gruppi di outputComportamento di corrispondenza della coperturaGestione delle referenze da parte dell'esecutore del consensoRisorse di Output GroupConsent-Patient collegamentoCosa viene archiviato rispetto a cosa è transitorioIntegrazione con $davinci-data-exportCaratteristiche prestazionaliAutorizzazioneRegole di convalidaComportamento di corrispondenzaGestione degli erroriOperazioni correlate

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Operazione $bulk-member-match per HealthLake

AWS HealthLake supporta l'$bulk-member-matchoperazione per l'elaborazione asincrona delle richieste di abbinamento di più membri. Questa operazione consente alle organizzazioni sanitarie di abbinare in modo efficiente gli identificatori univoci di centinaia di membri in diversi sistemi sanitari utilizzando informazioni demografiche e di copertura in un'unica richiesta di massa. Questa funzionalità è essenziale per lo scambio di dati payer-to-payer su larga scala, le transizioni tra i membri e i requisiti di conformità CMS e segue le specifiche FHIR.

Nota

L'$bulk-member-matchoperazione si basa su una specifica FHIR sottostante che è attualmente sperimentale e soggetta a modifiche. Man mano che le specifiche si evolvono, il comportamento e l'interfaccia di questa API verranno aggiornati di conseguenza. Si consiglia agli sviluppatori di monitorare le note di HealthLake rilascio di AWS e gli aggiornamenti delle specifiche FHIR pertinenti per rimanere informati su eventuali modifiche che potrebbero influire sulle loro integrazioni.

Questa operazione è particolarmente utile quando è necessario:

  • Elaborare l'abbinamento dei membri su larga scala durante i periodi di iscrizione aperti

  • Facilita le transizioni di massa dei membri tra i paganti

  • Supporta i requisiti di scambio di dati di conformità CMS su larga scala

  • Abbina in modo efficiente le coorti di membri attraverso le reti sanitarie

  • Riduci al minimo le chiamate API e migliora l'efficienza operativa per scenari di abbinamento ad alto volume

Utilizzo

L'$bulk-member-matchoperazione è un'operazione asincrona richiamata sulle risorse del gruppo utilizzando il metodo POST:

POST [base]/Group/$bulk-member-match

Dopo aver inviato una richiesta di corrispondenza in blocco, puoi verificare lo stato del lavoro utilizzando:

GET [base]/$bulk-member-match-status/{jobId}

Parametri supportati

HealthLake supporta i seguenti parametri FHIR: $bulk-member-match

Parametro Tipo Campo obbligatorio Description

MemberPatient

Paziente

Sì

Risorsa per il paziente contenente informazioni demografiche relative al membro da abbinare.

CoverageToMatch

Copertura

Sì

Risorsa di copertura che verrà utilizzata per il confronto con i record esistenti.

CoverageToLink

Copertura

No

Risorsa di copertura da collegare durante il processo di abbinamento.

Consent

Consenso

Sì

Viene inoltre memorizzata la risorsa di consenso a fini di autorizzazione. Questa operazione è diversa dalla singola $member-match operazione in cui non è richiesto il consenso.

Richiesta POST per inviare in blocco un'offerta di lavoro abbinata a un membro

L'esempio seguente mostra una richiesta POST per inviare un lavoro collettivo riservato ai membri. Ogni membro è racchiuso in un MemberBundle parametro contenente le risorse obbligatorie e Consent le risorse MemberPatientCoverageToMatch, oltre a un parametro opzionale. 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"
              }
            ]
          }
        }
      ]
    }
  ]
}

Risposta al lavoro completata con output

Una volta completato il lavoro, la risposta include i metadati del lavoro e una risorsa FHIR Parameters contenente tre risorse di gruppo che classificano i risultati delle partite.

{
  "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"
              }
            }
          ]
        }
      }
    ]
  }
}

Come HealthLake classifica i membri in gruppi di output

Ogni membro inviato in una $bulk-member-match richiesta viene valutato tramite una pipeline sequenziale. Il risultato di ogni passaggio determina in quale gruppo di output viene inserito il membro.

  1. Validazione strutturale: è MemberBundle conforme ai profili richiesti? In caso di errore: errore (non in nessun gruppo).

  2. Abbinamento tra pazienti: è possibile HealthLake trovare pazienti corrispondenti ai dati demografici inviati? In caso di fallimento:. NonMatchedMembers

  3. Conferma della copertura: è possibile HealthLake restringere la copertura a un solo paziente con valido CoverageToMatch? In caso di fallimento: NonMatchedMembers.

  4. Valutazione del consenso: il consenso presentato è onorevole in questo momento? (status = attivo, il periodo copre la data corrente, l'esecutore può essere convalidato). In caso di fallimento:. ConsentConstrainedMembers

  5. Operazione riuscita: tutti i controlli vengono superati. Consenso memorizzato nel datastore. Membro inserito. MatchedMembers

Principio chiave: un membro può apparire solo in una destinazione. Il primo passaggio non riuscito determina il posizionamento. I membri che non superano le fasi 2 o 3 non vengono mai inseriti ConsentConstrainedMembers : tale gruppo è riservato esclusivamente ai membri che hanno raggiunto l'abbinamento con successo ma il cui consenso non può essere rispettato.

Dettagli sulla valutazione del consenso (Fase 4):

  • Verifica 1 — Stato del consenso: è Consent.status uguale a «attivo»? In caso contrario → ConsentConstrainedMembers.

  • Verifica 2 - Periodo di fornitura: provision.period copre la data corrente? Se la data corrente è precedente period.start o successiva a period.end → ConsentConstrainedMembers.

  • Controllo 3 — Convalida dell'esecutore: Il Consent.performer riferimento può essere convalidato? Se la risorsa referenziata non viene trovata nel datastore o non è associata al paziente corrispondente →. ConsentConstrainedMembers

Tutti i controlli devono essere superati affinché il membro venga inserito MatchedMembers e il consenso venga archiviato.

Comportamento di corrispondenza della copertura

Durante l'abbinamento dei membri, solo CoverageToMatch viene convalidato rispetto al datastore del pagante che risponde. CoverageToLinkappartiene al new/requesting pagante e non è convalidato rispetto al datastore del vecchio pagante. L'inclusione CoverageToLink nella richiesta non influirà sui risultati corrispondenti.

Ogni combinazione Patiente+Copertura nella richiesta viene elaborata in modo indipendente. Lo stesso paziente può essere inviato più volte con piani di copertura diversi e ogni candidatura riceve il proprio risultato in base alla copertura specifica.

Gestione delle referenze da parte dell'esecutore del consenso

Il nuovo pagatore può inviare una referenza temporanea o locale per il paziente Consent.performer (ad esempio, la stessa referenza utilizzata inConsent.patient). HealthLake risolve automaticamente questi riferimenti:

  • Se Consent.performer contiene lo stesso riferimento locale diConsent.patient, lo HealthLake sostituisce con il riferimento del paziente effettivamente corrispondente dopo che l'abbinamento è riuscito.

  • HealthLake supporta riferimenti agli esecutori di tipo Paziente RelatedPerson, Professionista e Organizzazione (sia riferimenti diretti che riferimenti identificativi logici). PractitionerRole

  • Se la convalida dell'esecutore fallisce (risorsa non trovata o non associata al paziente corrispondente), il membro viene inserito anziché restituire un errore. ConsentConstrainedMembers

Risorse di Output Group

Il lavoro completato restituisce una risorsa Parameters contenente tre risorse di gruppo:

MatchedMembers Group (Gruppo)

Contiene i riferimenti dei pazienti per tutti i membri abbinati correttamente il cui consenso è attivo e valido al momento della richiesta. La risorsa Consent viene creata e archiviata nel datastore per ogni membro corrispondente. Questo gruppo è istanziato nel datastore e può essere utilizzato direttamente con. $davinci-data-export

NonMatchedMembers Group (Gruppo)

Contiene riferimenti ai membri in cui non è stata trovata alcuna corrispondenza univoca. Un membro viene inserito qui quando nessun paziente nel datastore corrisponde ai dati demografici forniti, non esiste una copertura valida per nessun paziente candidato corrispondente o più pazienti corrispondono ai dati demografici e più pazienti hanno una copertura valida (ambiguo).

ConsentConstrainedMembers Group (Gruppo)

Contiene i riferimenti dei pazienti che sono stati abbinati con successo (dati demografici e copertura confermati) ma il cui consenso non può essere rispettato al momento della richiesta. La risorsa Consent non viene archiviata per i membri con vincoli di consenso. L'identità del membro corrispondente (MemberIdentifier e MemberId) è ancora inclusa in modo che il pagante richiedente sappia chi era vincolato.

Il Group.quantity campo contiene il numero totale di membri in ciascuno dei rispettivi gruppi.

Riferimenti dei membri del gruppo:

  • Group.member.entity.reference— Per MatchedMembers e ConsentConstrainedMembers, contiene l'ID del paziente del membro corrispondente nel sistema del pagatore che risponde. Per NonMatchedMembers, fa riferimento all'input Paziente contenuto.

  • Group.member.entity.extension (base-ext-match-parameters)— Contiene l'ID del paziente riportato nella richiesta di immissione originale (l'ID inviato dal pagatore richiedente, derivato da Patient.idCoverage.beneficiary.reference, oConsent.patient.reference).

Importante

La risorsa Consent memorizzata conserva il riferimento del paziente esattamente come inviato dal pagatore richiedente. HealthLake non aggiorna automaticamente il campo del paziente del consenso in modo che punti al Paziente corrispondente nel datastore ricevente.

Per collegare un Consenso memorizzato al Paziente corrispondente, utilizza il job output: ogni membro del MatchedMembers Gruppo rimanda al member.entity.reference Paziente corrispondente e un member.entity.extension (base-ext-match-parameters) rimanda al Paziente di input contenuto. Cross-reference aggiungili al campo Consent's patient per creare la mappatura nel livello di candidatura.

Cosa viene archiviato rispetto a cosa è transitorio

La tabella seguente documenta ciò che HealthLake persiste nel datastore durante l'$bulk-member-matchelaborazione e ciò che esiste solo nella risposta al lavoro:

Risorsa Memorizzato? Interrogabile tramite REST? Note

MemberPatient (ingresso)

No

No

Utilizzato solo per la corrispondenza; non persistente

CoverageToMatch (input)

No

No

Utilizzato solo per la conferma della copertura

CoverageToLink (input)

No

No

Non convalidato rispetto al datastore; appartiene al nuovo pagatore

Consenso (membri abbinati)

Sì

Sì, GET [base] /Consent/ {id}

Memorizzato così come ricevuto dal pagatore richiedente

Consenso (membri vincolati)

No

No

Non memorizzato. L'identità del membro è ancora inclusa nella risposta.

MatchedMembers Gruppo (output)

Sì

Sì, GET [base] /Group/ {id}

Istanziato; utilizzabile con $davinci-data-export

NonMatchedMembers Gruppo

No

No

Solo Job response

ConsentConstrainedMembers Gruppo

No

No

Solo Job response

Integrazione con $davinci-data-export

La risorsa MatchedMembers di gruppo restituita da $bulk-member-match può essere utilizzata direttamente con l'$davinci-data-exportoperazione per recuperare i dati di massa dei membri:

POST [base]/Group/{matched-group-id}/$davinci-data-export
GET [base]/Group/{matched-group-id}

Questa integrazione consente flussi di lavoro efficienti in cui si identificano innanzitutto i membri corrispondenti in blocco, quindi si esportano le relative cartelle cliniche complete utilizzando la risorsa di Gruppo risultante.

Usare $member-remove prima dell'esportazione

Se devi escludere membri specifici dall'esportazione dopo l'abbinamento (ad esempio, un membro revoca il consenso tra l'abbinamento e l'esportazione), usalo nel gruppo. $member-remove MatchedMembers

Importante

La rimozione di un membro tramite $member-remove contrassegna il membro come inattivo nel Gruppo, ma esclude i membri inattivi $davinci-data-export solo dopo che il Gruppo è stato aggiornato allo stato «finale». Se $davinci-data-export chiami un Gruppo che ha ancora lo status predefinito, i membri rimossi potrebbero comunque apparire nei risultati di esportazione.

Flusso di lavoro:

  1. POST [base]/Group/{id}/$member-remove— contrassegna i membri inattivi

  2. PUT [base]/Group/{id}— aggiorna lo stato del gruppo a «finale»

  3. POST [base]/Group/{id}/$davinci-data-export— l'esportazione ora esclude i membri rimossi

Caratteristiche prestazionali

L'$bulk-member-matchoperazione è progettata per l'elaborazione di grandi volumi e viene eseguita in modo asincrono:

  • Concorrenza: massimo 5 operazioni simultanee per archivio dati.

  • Scalabilità: gestisce fino a 500 membri per richiesta (limite di payload di 5 MB).

  • Operazioni parallele: compatibile con operazioni simultanee di importazione, esportazione o eliminazione in blocco.

Autorizzazione

L'API utilizza il protocollo di autorizzazione SMART on FHIR con i seguenti ambiti richiesti:

  • system/Patient.read— Necessario per cercare e abbinare le risorse dei pazienti.

  • system/Coverage.read— Necessario per convalidare le informazioni sulla copertura.

  • system/Group.write— Necessario per creare risorse del Gruppo di risultati.

  • system/Organization.read— Condizionale, obbligatorio se la copertura si riferisce alle organizzazioni.

  • system/Practitioner.read— Condizionale, obbligatorio se la copertura si riferisce ai professionisti.

  • system/PractitionerRole.read— Condizionale, obbligatorio se la copertura si riferisce ai ruoli dei professionisti.

  • system/Consent.write— Condizionale, obbligatorio se vengono fornite risorse per il consenso.

L'operazione supporta anche l'autorizzazione AWS IAM Signature Version 4 (SigV4) per l'accesso programmatico.

Regole di convalida

Le seguenti regole di convalida vengono applicate a ciascuna di esse MemberBundle nella Fase 1. I membri che non superano la convalida vengono segnalati come errori e non compaiono in nessun gruppo di output.

MemberPatient

CampoCome HealthLake lo usaErrore di convalida se...

name.family

Ricerca demografica

Mancante

name.given

Ricerca demografica

Mancante (almeno una richiesta)

birthDate

Ricerca demografica

Mancante

gender

Ricerca demografica; se assente, viene utilizzata l'estensione Birth Sex

Non sono presenti né sesso né sesso di nascita (hrex-pat-1)

identifier

Incluso nella ricerca quando presente; migliora la fiducia

Non causa mai guasti (opzionale)

CoverageToMatch / CoverageToLink

CampoCome lo HealthLake usaErrore di convalida se...

status

Conferma che la copertura è utilizzabile

Mancante

beneficiary

Collega la copertura a un candidato paziente

Mancante

payor

Disambiguazione quando esistono più candidati

Mancante o più di un pagatore

relationship

Conferma la relazione abbonato-beneficiario

Mancante

identifier (MB) or subscriberId

Chiave di disambiguazione principale

Nessuno dei due presenti

CampoCome lo HealthLake utilizzaErrore di convalida se...

scope

Conferma che l'ambito del consenso è la privacy del paziente

Codice sulla privacy del paziente mancante o assente

category

Conferma la classificazione delle divulgazioni

Mancante

patient

Identifica il soggetto del consenso

Mancante

performer

Identifica chi è d'accordo

Mancante

sourceReference

Documenta la fonte del consenso

Mancante

policy.uri

Determina l'ambito di condivisione dei dati

Mancante o URI che non termina con #regular o #sensitive

provision.type

Deve essere «permesso» per il profilo HREx Consent

«Permesso» mancante o assente (incluso «rifiuto»)

provision.period

Valutato nella Fase 4 per un controllo limitato al consenso

Mancante o assente start/end

status

Valutato nella fase 4 (NON nella fase 1)

Non causa mai un errore nella Fase 1: HealthLake accetta qualsiasi stato valido e valuta nella Fase 4

Nota

Il profilo HREx Consent definisce lo stato con un valore fisso di «attivo». HealthLake allenta intenzionalmente questo vincolo in modo che un consenso non attivo riceva una classificazione significativa () ConsentConstrainedMembers anziché un rifiuto generalizzato di convalida.

Comportamento di corrispondenza

  • Ricerca paziente (fase 2): HealthLake ricerche utilizzando name.family + name.given (esatto, senza distinzione tra maiuscole e minuscole), birthDate (esatto), gender (esatto; sesso di nascita utilizzato se il sesso non è presente) e identifier (se presente, facoltativo).

  • Disambiguazione della copertura (Fase 3): quando vengono trovati più pazienti candidati, CoverageToMatch viene utilizzata per restringere il campo a uno solo. Una copertura è «valida» quando nel datastore è presente una risorsa Coverage attiva corrispondente a subscriberId o identifier (tipo MB) AND. payor

  • Valutazione del consenso (Fase 4): eseguita solo dopo una corrispondenza univoca riuscita. Vedi la sezione precedente relativa ai dettagli sulla valutazione del consenso.

Gestione degli errori

L'operazione gestisce le seguenti condizioni di errore:

  • 400 Richiesta errata: formato di richiesta non valido, parametri obbligatori mancanti o il payload supera i limiti di dimensione (500 membri o 5 MB).

  • 422 Entità non processabile: errori di elaborazione durante l'esecuzione del lavoro.

  • Errori individuali dei membri: quando un membro specifico non viene elaborato, l'operazione continua con i membri rimanenti e include i dettagli dell'errore nel NonMatchedMembers Gruppo con i codici motivo appropriati. Ad esempio, se MemberBundle a un paziente manca il birthDate parametro, verrà restituito il seguente errore:

    "errors": [
  {
    "memberIndex": 1,
    "jsonBlob": {
      "resourceType": "OperationOutcome",
      "issue": [
        {
          "severity": "error",
          "code": "invalid",
          "diagnostics": "MemberPatient.birthDate is required"
        }
      ],
      "statusCode": 400
    }
  }
]

I dettagli sull'errore sono disponibili tramite l'endpoint di polling dello stato e includono:

  • numberOfMembersWithCustomerError: Numero di membri con errori di convalida o di input.

  • numberOfMembersWithServerError: Numero di membri con errori di elaborazione sul lato server.