View a markdown version of this page

operación $bulk-member-match para HealthLake - AWS HealthLake
De usoParámetros admitidosSolicitud POST para enviar un trabajo de emparejamiento masivo de miembrosRespuesta al trabajo completada con salida¿Cómo HealthLake clasifica los miembros en grupos de salidaComportamiento de coincidencia de coberturaConsentimiento, ejecutante, manejo de referenciasRecursos del grupo de salidaConsent-Patient vinculación¿Qué se almacena frente a qué es transitorioIntegración con $davinci-data-exportCaracterísticas de rendimientoAutorizaciónReglas de validaciónComportamiento coincidenteGestión de erroresOperaciones de relacionadas

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.

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 opcionalCoverageToLink. 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": "<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"
              }
            }
          ]
        }
      }
    ]
  }
}

¿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).

  2. Coincidencia de pacientes: ¿se pueden HealthLake encontrar pacientes que coincidan con los datos demográficos enviados? Sobre el fracaso: NonMatchedMembers.

  3. Confirmación de cobertura: ¿se puede HealthLake limitar a exactamente un paciente con validez CoverageToMatch? En caso de fallo: NonMatchedMembers.

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

  5. É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.periodcubre 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. CoverageToLinkpertenece 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 enConsent.patient). HealthLake resuelve estas referencias automáticamente:

  • Si Consent.performer contiene la misma referencia local queConsent.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.idCoverage.beneficiary.reference, oConsent.patient.reference).

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

  2. PUT [base]/Group/{id}— actualizar el estado del grupo a «definitivo»

  3. 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 usaFallo 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 usaFallo 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

Campo¿Cómo lo HealthLake usaFallo 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.