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-match`operazione 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.](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html) **Nota** L'`$bulk-member-match`operazione 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-match`operazione è 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 `MemberPatient``CoverageToMatch`, 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": "
Matched members group
" }, "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": "
Non-matched members group
" }, "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": "
Consent constrained members group
" }, "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). 1. **Abbinamento tra pazienti**: è possibile HealthLake trovare pazienti corrispondenti ai dati demografici inviati? In caso di fallimento:. NonMatchedMembers 1. **Conferma della copertura**: è possibile HealthLake restringere la copertura a un solo paziente con valido CoverageToMatch? In caso di fallimento: NonMatchedMembers. 1. **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 1. **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. `CoverageToLink`appartiene 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 in`Consent.patient`). HealthLake risolve automaticamente questi riferimenti: + Se `Consent.performer` contiene lo stesso riferimento locale di`Consent.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.id``Coverage.beneficiary.reference`, o`Consent.patient.reference`). ## Consent-Patient collegamento **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-match`elaborazione 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-export`operazione 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 1. `PUT [base]/Group/{id}`— aggiorna lo stato del gruppo a «finale» 1. `POST [base]/Group/{id}/$davinci-data-export`— l'esportazione ora esclude i membri rimossi ## Caratteristiche prestazionali L'`$bulk-member-match`operazione è 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 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 | ### Consenso | 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 | | `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. ## Operazioni correlate + [`$member-match`operazione per HealthLake](reference-fhir-operations-member-match.md)— Operazione di abbinamento dei singoli membri. + [Funzionamento FHIR R4 `$davinci-data-export` per HealthLake](reference-fhir-operations-davinci-data-export.md)— Esportazione di dati in blocco utilizzando le risorse del Gruppo. + [FHIR R4 per `$operations` HealthLake](reference-fhir-operations.md)— Elenco completo delle operazioni supportate.