Utilizzo Avvio rapido Parametri supportati Richiesta POST per inviare in blocco un'offerta di lavoro abbinata a un membro Risposta al lavoro completata con output Come HealthLake classifica i membri in gruppi di output Comportamento di corrispondenza della copertura Gestione delle referenze da parte dell'esecutore del consenso Risorse del gruppo di output Consent-Patient collegamento Cosa viene archiviato rispetto a cosa è transitorio Integrazione con $davinci-data-export Caratteristiche prestazionali Autorizzazione Regole di convalida Comportamento corrispondente Gestione degli errori Operazioni correlate

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 di 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}

Ogni richiesta supporta fino a 500 membri con un payload massimo di 5 MB.

Avvio rapido

Per iniziare con Bulk Member Match, segui questi passaggi:

Invia una richiesta di abbinamento in blocco MemberBundles utilizzando l'Group/$bulk-member-matchoperazione. La risposta include un ID del lavoro.
Verifica lo stato del lavoro utilizzando l'$bulk-member-match-statusoperazione fino a quando lo stato non è COMPLETATO.
Estrai l'ID MatchedMembers del gruppo dalla risposta al lavoro completata.
Esporta i dati clinici utilizzando l'Group/$davinci-data-exportoperazione sul gruppo corrispondente.

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.

Validazione strutturale: è MemberBundle conforme ai profili richiesti? In caso di errore: errore (non in nessun gruppo).
Abbinamento tra pazienti: è possibile HealthLake trovare pazienti corrispondenti ai dati demografici inviati? In caso di fallimento:. NonMatchedMembers
Conferma della copertura: è possibile HealthLake limitarsi a un solo paziente con valido CoverageToMatch? In caso di fallimento: NonMatchedMembers.
Valutazione del consenso: provision.period copre la data corrente? In caso di fallimento: ConsentConstrainedMembers.
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):

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

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

Nota

L'operazione non convalida il performer riferimento rispetto al patient campo. Un genitore o un tutore può acconsentire per conto di una persona a carico.

La tabella seguente descrive come la classificazione del consenso determina la collocazione dei membri:

Tipo di fornitura	URI della politica	Stato	Periodo	Outcome
`permit`	`#regular`	`active`	Copre la data corrente	MatchedMembers (Consenso memorizzato)
`permit`	`#sensitive`	`active`	Copre la data corrente	MatchedMembers (Consenso memorizzato)
`permit`	`#regular` o `#sensitive`	`active`	Scaduto o non avviato	ConsentConstrainedMembers
`deny`	Qualsiasi	Qualsiasi	Qualsiasi	400 Richiesta errata (Fase 1)
`permit`	Non finisce con `#regular` o `#sensitive`	Qualsiasi	Qualsiasi	400 Richiesta errata (Fase 1)
Qualsiasi	Qualsiasi	Non `active`	Qualsiasi	400 Richiesta errata (Fase 1)

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 paziente+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
Il performer riferimento non è stato convalidato in modo incrociato. patient Un parent/guardian consenso per conto di un dipendente è valido e non indirizzerà il membro a. ConsentConstrainedMembers

Risorse del gruppo di output

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). Questo gruppo non è istanziato nel datastore. Esiste solo nella risposta al lavoro completata.
ConsentConstrainedMembers Group (Gruppo): Contiene i riferimenti dei pazienti per i membri 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. Questo gruppo non è istanziato nel datastore. Esiste solo nella risposta al lavoro completata.

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:

POST [base]/Group/{id}/$member-remove— contrassegna i membri inattivi
PUT [base]/Group/{id}— aggiorna lo stato del gruppo a «finale»
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

Campo	Come HealthLake lo usa	Errore 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

Campo	Come lo HealthLake usa	Errore di convalida se...
`status`	Conferma che la copertura è utilizzabile	Mancante
`beneficiary`	Collega la copertura a un paziente candidato	Mancante
`relationship`	Conferma la relazione abbonato-beneficiario	Mancante
`identifier (MB) or subscriberId`	Chiave di disambiguazione principale	Nessuno dei due presenti

Campo	Come lo HealthLake utilizza	Errore 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
`provision.actor`	Identifica i pagatori originari e destinatari	Mancano o non includono gli attori source + destinatari richiesti per profilo HREx
`provision.action`	Conferma l'azione di divulgazione	Codice di «divulgazione» mancante o assente
`status`	Deve essere «attivo» per HRex IG	Non «attivo»: restituisce un errore di convalida 400

Nota

Per HRex IG, Consent.status è impostato su «attivo». HealthLake lo applica nella Fase 1 (convalida strutturale) e restituisce un errore di convalida 400 se viene fornito un altro stato. Non-active il consenso non verrà elaborato né classificato in ConsentConstrainedMembers : verrà rifiutato in anticipo.

Comportamento corrispondente

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 esiste una risorsa Coverage attiva nel datastore corrispondente a subscriberId o identifier (tipo MB).
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 relativi ai singoli membri: quando un membro specifico non viene elaborato, l'operazione continua con i membri rimanenti e include i dettagli dell'errore 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.

$member-matchoperazione per HealthLake— Operazione di abbinamento dei singoli membri.
Operazione di esportazione dati FHIR R4 $davinci-data-export per HealthLake— Esportazione di dati in blocco utilizzando le risorse del Gruppo.
FHIR R4 per $operations HealthLake— Elenco completo delle operazioni supportate.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

$bulk-delete

$confirm-attribution-list

Operazione $bulk-member-match per HealthLake

Nota

Utilizzo

Avvio rapido

Parametri supportati

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

Risposta al lavoro completata con output

Come HealthLake classifica i membri in gruppi di output

Nota

Comportamento di corrispondenza della copertura

Gestione delle referenze da parte dell'esecutore del consenso

Risorse del gruppo di output

Consent-Patient collegamento

Importante

Cosa viene archiviato rispetto a cosa è transitorio

Integrazione con $davinci-data-export

Usare $member-remove prima dell'esportazione

Importante

Caratteristiche prestazionali

Autorizzazione

Regole di convalida

MemberPatient

CoverageToMatch / CoverageToLink

Consenso

Nota

Comportamento corrispondente

Gestione degli errori

Operazioni correlate

Operazione `$bulk-member-match per` HealthLake