Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # `operación $bulk-member-match para` HealthLake AWS HealthLake admite la `$bulk-member-match` operación de procesar las solicitudes de emparejamiento de varios miembros de forma asíncrona. Esta operación permite a las organizaciones de atención médica comparar de manera eficiente los identificadores únicos de cientos de miembros de diferentes sistemas de salud utilizando información demográfica y de cobertura en una sola solicitud masiva. [Esta capacidad es esencial para el intercambio de datos entre pagadores a gran escala, las transiciones de los miembros y los requisitos de conformidad con los CMS, y sigue la especificación de la FHIR.](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html) **nota** La `$bulk-member-match` operación se basa en una especificación subyacente del FHIR que actualmente se encuentra en fase experimental y está sujeta a cambios. A medida que la especificación evolucione, el comportamiento y la interfaz de esta API se actualizarán en consecuencia. Se recomienda a los desarrolladores que supervisen las notas de la HealthLake versión de AWS y las actualizaciones de las especificaciones del FHIR pertinentes para mantenerse informados de cualquier cambio que pueda afectar a sus integraciones. Esta operación resulta especialmente útil cuando necesita: + Procese la comparación de miembros a gran escala durante los períodos de inscripción abierta + Facilite las transiciones masivas de miembros entre pagadores + Support con los requisitos de intercambio de datos de conformidad con los CMS a gran escala + Haga coincidir de manera eficiente las cohortes de miembros en todas las redes de atención médica + Minimice las llamadas a la API y mejore la eficiencia operativa en escenarios de coincidencia de gran volumen ## De uso La `$bulk-member-match` operación es una operación asíncrona que se invoca en los recursos del grupo mediante el método POST: ``` POST [base]/Group/$bulk-member-match ``` Tras enviar una solicitud de coincidencia masiva, puedes sondear el estado del trabajo mediante: ``` GET [base]/$bulk-member-match-status/{jobId} ``` ## Parámetros admitidos HealthLake admite los siguientes `$bulk-member-match` parámetros del FHIR: | Parámetro | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | `MemberPatient` | Paciente | Sí | Recurso para pacientes que contiene información demográfica sobre el miembro al que se va a vincular. | | `CoverageToMatch` | Cobertura | Sí | Recurso de cobertura que se utilizará para compararlo con los registros existentes. | | `CoverageToLink` | Cobertura | No | El recurso de cobertura se vinculará durante el proceso de emparejamiento. | | `Consent` | Consentimiento | Sí | También se almacena el recurso de consentimiento para fines de autorización. Esto es diferente de la `$member-match` operación individual en la que *no* se requiere el consentimiento. | ## Solicitud POST para enviar un trabajo de emparejamiento masivo de miembros En el siguiente ejemplo, se muestra una solicitud POST para enviar un trabajo de afiliación masiva de miembros. Cada miembro está incluido en un `MemberBundle` parámetro que contiene los `Consent` recursos necesarios `MemberPatient` y uno opcional`CoverageToLink`. `CoverageToMatch` ``` 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" } ] } } ] } ] } ``` ## Respuesta al trabajo completada con salida Cuando se completa el trabajo, la respuesta incluye los metadatos del trabajo y un recurso de parámetros del FHIR que contiene tres recursos del grupo que clasifican los resultados de la coincidencia. ``` { "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" } } ] } } ] } } ``` ## ¿Cómo HealthLake clasifica los miembros en grupos de salida Cada miembro presentado en una `$bulk-member-match` solicitud se evalúa mediante un proceso secuencial. El resultado de cada paso determina en qué grupo de salida se encuentra el miembro. 1. **Validación estructural**: ¿se MemberBundle ajusta a los perfiles requeridos? En caso de fallo: error (no en ningún grupo). 1. **Coincidencia de pacientes**: ¿se pueden HealthLake encontrar pacientes que coincidan con los datos demográficos enviados? Sobre el fracaso: NonMatchedMembers. 1. **Confirmación de cobertura**: ¿se puede HealthLake limitar a exactamente un paciente con validez CoverageToMatch? En caso de fallo: NonMatchedMembers. 1. **Evaluación del consentimiento**: ¿el consentimiento presentado es honorable en este momento? (estado = activo, el período abarca la fecha actual, el ejecutante puede ser validado). En caso de fallo: ConsentConstrainedMembers. 1. **Éxito**: se aprueban todos los controles. El consentimiento se almacena en el almacén de datos. Miembro ingresado. MatchedMembers **Principio clave:** un miembro solo puede aparecer en un destino. El primer paso que falle determina la ubicación. Los miembros que no aprueben los pasos 2 o 3 nunca serán incluidos en ese grupo ConsentConstrainedMembers ; ese grupo es exclusivamente para los miembros que hayan conseguido emparejarse con éxito, pero cuyo consentimiento no podrá respetarse. **Detalles de la evaluación del consentimiento (paso 4):** + **Comprobación 1: Estado del consentimiento:** ¿es `Consent.status` igual a «activo»? Si no → ConsentConstrainedMembers. + **Verificación 2: Período de provisión:** ¿`provision.period`cubre la fecha actual? Si la fecha actual es anterior `period.start` o posterior a `period.end` → ConsentConstrainedMembers. + **Comprobación 3: Validación del ejecutante:** ¿Se puede validar la `Consent.performer` referencia? Si el recurso al que se hace referencia no se encuentra en el almacén de datos o no está asociado al paciente coincidente →. ConsentConstrainedMembers Se deben pasar todos los controles para poder ingresar al miembro MatchedMembers y para almacenar el consentimiento. ## Comportamiento de coincidencia de cobertura Durante la comparación de miembros, solo `CoverageToMatch` se valida con el almacén de datos del pagador que responde. `CoverageToLink`pertenece al new/requesting pagador y *no* se valida con el almacén de datos del pagador anterior. Incluirlo `CoverageToLink` en la solicitud no afectará a los resultados coincidentes. Cada combinación de paciente y cobertura de la solicitud se procesa de forma independiente. El mismo paciente puede presentarse varias veces con diferentes planes de cobertura, y cada solicitud recibe su propio resultado en función de su cobertura específica. ## Consentimiento, ejecutante, manejo de referencias El nuevo pagador puede enviar una referencia temporal o local de un paciente `Consent.performer` (por ejemplo, la misma referencia utilizada en`Consent.patient`). HealthLake resuelve estas referencias automáticamente: + Si `Consent.performer` contiene la misma referencia local que`Consent.patient`, la HealthLake reemplaza por la referencia real del paciente coincidente una vez que la comparación se realice correctamente. + HealthLake admite referencias a artistas intérpretes o ejecutantes de los tipos Paciente RelatedPerson PractitionerRole, Médico y Organización (tanto referencias directas como referencias de identificador lógico). + Si la validación del ejecutante falla (no se encuentra el recurso o no está asociado al paciente compatible), se coloca al miembro en ConsentConstrainedMembers lugar de mostrar un error. ## Recursos del grupo de salida El trabajo completado devuelve un recurso de parámetros que contiene tres recursos de grupo: **MatchedMembers Group (Grupo)** Contiene las referencias de los pacientes de todos los miembros seleccionados correctamente cuyo consentimiento está activo y válido en el momento de la solicitud. El recurso Consent se crea y almacena en el almacén de datos de cada miembro coincidente. Este grupo se crea en el almacén de datos y se puede usar directamente con. `$davinci-data-export` **NonMatchedMembers Group (Grupo)** Contiene referencias a miembros en los que no se encontró ninguna coincidencia única. Un miembro aparece aquí cuando ningún paciente del almacén de datos coincide con los datos demográficos proporcionados, no existe una cobertura válida para ningún paciente candidato compatible o varios pacientes coinciden con los datos demográficos y varios tienen una cobertura válida (ambiguo). **ConsentConstrainedMembers Group (Grupo)** Contiene las referencias de los pacientes a los que se pudo vincular correctamente (se confirmaron los datos demográficos y la cobertura), pero cuyo consentimiento no se pudo cumplir en el momento de la solicitud. El recurso Consent *no* se almacena para los miembros con restricciones de consentimiento. La identidad (MemberIdentifier y MemberId) del miembro coincidente se sigue incluyendo para que el pagador solicitante sepa quién tuvo la restricción. El `Group.quantity` campo contiene el recuento total de miembros de cada uno de sus grupos respectivos. **Referencias de miembros del grupo:** + `Group.member.entity.reference`— Para MatchedMembers y ConsentConstrainedMembers, contiene la identificación del paciente del miembro coincidente en el sistema del pagador que responde. Para NonMatchedMembers, hace referencia a la entrada contenida, Paciente. + `Group.member.entity.extension (base-ext-match-parameters)`— Contiene la identificación del paciente de la solicitud de entrada original (la identificación presentada por el pagador solicitante, derivada de `Patient.id``Coverage.beneficiary.reference`, o`Consent.patient.reference`). ## Consent-Patient vinculación **importante** El recurso de consentimiento almacenado conserva la referencia del paciente exactamente como la envió el pagador solicitante. HealthLake no actualiza automáticamente el campo de paciente del consentimiento para que apunte al paciente coincidente en el almacén de datos receptor. Para vincular un consentimiento almacenado con el paciente compatible, utilice el resultado del trabajo: cada miembro del MatchedMembers grupo tiene un botón que `member.entity.reference` apunta al paciente coincidente y un `member.entity.extension` (`base-ext-match-parameters`) que apunta al paciente de entrada contenido. Cross-reference todo ello con el campo de paciente de Consent para crear el mapeo en la capa de aplicación. ## ¿Qué se almacena frente a qué es transitorio La siguiente tabla documenta lo que HealthLake permanece en el almacén de datos durante el `$bulk-member-match` procesamiento y lo que solo existe en la respuesta al trabajo: | Recurso | ¿Almacenado? | ¿Se puede consultar mediante REST? | Notas | | --- | --- | --- | --- | | MemberPatient (entrada) | No | No | Se usa solo para hacer coincidir; no persiste | | CoverageToMatch (entrada) | No | No | Se usa solo para confirmar la cobertura | | CoverageToLink (entrada) | No | No | No se valida con el almacén de datos; pertenece al nuevo pagador | | **Consentimiento (miembros coincidentes)** | **Sí** | Sí, GET [base] /Consent/ {id} | Se guarda tal como se recibió del pagador solicitante | | Consentimiento (miembros restringidos) | No | No | No almacenado. La identidad del miembro sigue incluida en la respuesta. | | **MatchedMembers Grupo (salida)** | **Sí** | Sí, GET [base] /Group/ {id} | Instanciado; se puede usar con $davinci-data-export | | NonMatchedMembers Grupo | No | No | Job response únicamente | | ConsentConstrainedMembers Grupo | No | No | Job response únicamente | ## Integración con $davinci-data-export El recurso del MatchedMembers grupo devuelto por se `$bulk-member-match` puede utilizar directamente con la `$davinci-data-export` operación para recuperar datos masivos de los miembros: ``` POST [base]/Group/{matched-group-id}/$davinci-data-export GET [base]/Group/{matched-group-id} ``` Esta integración permite flujos de trabajo eficientes en los que primero se identifican los miembros coincidentes de forma masiva y, a continuación, se exportan sus historiales médicos completos utilizando el recurso del grupo resultante. ### Uso de $member-remove antes de exportar Si necesitas excluir a miembros específicos de la exportación después de la coincidencia (por ejemplo, si un miembro revoca el consentimiento entre la comparación y la exportación), usa `$member-remove` On the Group. MatchedMembers **importante** Al eliminar a un miembro mediante, se `$member-remove` marca como inactivo en el Grupo, pero `$davinci-data-export` solo se excluyen los miembros inactivos una vez que el Grupo pasa al estado «definitivo». Si llamas a `$davinci-data-export` un grupo que todavía tiene el estado predeterminado, es posible que los miembros eliminados sigan apareciendo en los resultados de exportación. Flujo de trabajo: 1. `POST [base]/Group/{id}/$member-remove`— marcar los miembros como inactivos 1. `PUT [base]/Group/{id}`— actualizar el estado del grupo a «definitivo» 1. `POST [base]/Group/{id}/$davinci-data-export`— la exportación ahora excluye a los miembros eliminados ## Características de rendimiento La `$bulk-member-match` operación está diseñada para el procesamiento de grandes volúmenes y se ejecuta de forma asíncrona: + **Simultaneidad**: máximo de 5 operaciones simultáneas por almacén de datos. + **Escalabilidad**: gestiona hasta 500 miembros por solicitud (límite de carga útil de 5 MB). + **Operaciones paralelas**: compatible con operaciones simultáneas de importación, exportación o eliminación masiva. ## Autorización La API utiliza el protocolo de autorización SMART on FHIR con los siguientes ámbitos obligatorios: + `system/Patient.read`— Necesaria para buscar y comparar los recursos de los pacientes. + `system/Coverage.read`— Necesario para validar la información de cobertura. + `system/Group.write`— Necesario para crear los recursos del grupo de resultados. + `system/Organization.read`— Condicional, obligatorio si la cobertura hace referencia a organizaciones. + `system/Practitioner.read`— Condicional, obligatorio si la cobertura hace referencia a profesionales. + `system/PractitionerRole.read`— Condicional, obligatorio si la cobertura hace referencia a las funciones de los profesionales. + `system/Consent.write`— Condicional, obligatorio si se proporcionan recursos de consentimiento. La operación también admite la autorización de la versión 4 (SiGv4) de AWS IAM Signature para el acceso programático. ## Reglas de validación En el paso 1, se aplican las siguientes reglas de validación MemberBundle a cada una de ellas. Los miembros que no pasan la validación se registran como errores y no aparecen en ningún grupo de salida. ### MemberPatient | Campo | ¿Cómo lo HealthLake usa | Fallo de validación si... | | --- | --- | --- | | `name.family` | Búsqueda demográfica | Missing (Ausente) | | `name.given` | Búsqueda demográfica | Falta (se requiere al menos uno) | | `birthDate` | Búsqueda demográfica | Missing (Ausente) | | `gender` | Búsqueda demográfica; si no está presente, se utiliza la extensión de nacimiento y sexo | No hay presencia de sexo ni sexo de nacimiento (hrex-pat-1) | | `identifier` | Se incluye en la búsqueda cuando está presente; mejora la confianza | Nunca provoca fallos (opcional) | ### CoverageToMatch / CoverageToLink | Campo | ¿Cómo lo HealthLake usa | Fallo de validación si... | | --- | --- | --- | | `status` | Confirma que la cobertura es procesable | Missing (Ausente) | | `beneficiary` | Vincula la cobertura a un paciente candidato | Missing (Ausente) | | `payor` | Desambiguación cuando existen varios candidatos | Falta o hay más de un pagador | | `relationship` | Confirma la relación entre el suscriptor y el beneficiario | Missing (Ausente) | | `identifier (MB) or subscriberId` | Clave de desambiguación principal | Ninguno de los presentes | ### Consentimiento | Campo | ¿Cómo lo HealthLake usa | Fallo de validación si... | | --- | --- | --- | | `scope` | Confirma que el alcance del consentimiento es la privacidad del paciente | Falta el código de privacidad del paciente o no existe | | `category` | Confirma la clasificación de la divulgación | Missing (Ausente) | | `patient` | Identifica al sujeto del consentimiento | Missing (Ausente) | | `performer` | Identifica quién está de acuerdo | Missing (Ausente) | | `sourceReference` | Documenta la fuente del consentimiento | Missing (Ausente) | | `policy.uri` | Determina el alcance del intercambio de datos | Falta o el URI no termina en \#regular o \#sensitive | | `provision.type` | Debe ser «permiso» según el perfil de HRex Consent | Falta o no el «permiso» (incluido el «denegar») | | `provision.period` | Se evaluó en el paso 4 para comprobar si el consentimiento estaba restringido | Falta o no start/end | | `status` | Se evaluó en el paso 4 (NO en el paso 1) | Nunca provoca un error en el paso 1: HealthLake acepta cualquier estado válido y lo evalúa en el paso 4 | **nota** El perfil HRex Consent define el estado con un valor fijo de «activo». HealthLake flexibiliza intencionalmente esta restricción para que un consentimiento inactivo reciba una clasificación significativa (ConsentConstrainedMembers) en lugar de un rechazo general por validación. ## Comportamiento coincidente + **Búsqueda de pacientes (paso 2)**: HealthLake busca utilizando el signo `name.family` \+ `name.given` (exacto, no distingue mayúsculas de minúsculas), `birthDate` (exacto), `gender` (exacto; se utiliza el sexo de nacimiento si no existe el género) y `identifier` (si está presente, opcional). + **Desambiguación de la cobertura (paso 3)**: cuando se encuentran varios pacientes candidatos, `CoverageToMatch` se utiliza para seleccionar uno solo. Una cobertura es «válida» cuando existe un recurso de cobertura activo en el almacén de datos que coincide con `subscriberId` o `identifier` (tipo MB) y. `payor` + **Evaluación del consentimiento (paso 4)**: solo se realiza después de una coincidencia única exitosa. Consulte la sección anterior sobre los detalles de la evaluación del consentimiento. ## Gestión de errores La operación gestiona las siguientes condiciones de error: + **400 Solicitud errónea**: el formato de solicitud no es válido, faltan los parámetros necesarios o la carga útil supera los límites de tamaño (500 miembros o 5 MB). + **422 Entidad inprocesable**: errores de procesamiento durante la ejecución del trabajo. + **Errores de miembros individuales**: cuando un miembro específico no se procesa, la operación continúa con los miembros restantes e incluye los detalles del error en el NonMatchedMembers grupo con los códigos de motivo correspondientes. Por ejemplo, si `MemberBundle` a un paciente le falta el `birthDate` parámetro, se devolverá el siguiente error: ``` "errors": [ { "memberIndex": 1, "jsonBlob": { "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "invalid", "diagnostics": "MemberPatient.birthDate is required" } ], "statusCode": 400 } } ] ``` Los detalles del error están disponibles en el punto final del sondeo de estado e incluyen: + `numberOfMembersWithCustomerError`: Recuento de miembros con errores de validación o introducción de datos. + `numberOfMembersWithServerError`: Recuento de miembros con errores de procesamiento en el servidor. ## Operaciones de relacionadas + [`$member-match`operación para HealthLake](reference-fhir-operations-member-match.md)— Operación de emparejamiento de miembros individuales. + [Funcionamiento FHIR R4 `$davinci-data-export` para HealthLake](reference-fhir-operations-davinci-data-export.md)— Exportación masiva de datos utilizando recursos del grupo. + [FHIR R4 para `$operations` HealthLake](reference-fhir-operations.md)— Lista completa de operaciones compatibles.