Usage Démarrage rapide Paramètres pris en charge Demande POST pour soumettre un job correspondant en masse à des membres Réponse à la tâche terminée avec sortie Comment HealthLake classifie les membres en groupes de sortie Comportement de correspondance de couverture Gestion des références aux exécutants du consentement Ressources du groupe de sortie Consent-Patient lien Ce qui est stocké par rapport à ce qui est transitoire Intégration avec $davinci-data-export Caractéristiques de performance Autorisation Règles de validation Comportement correspondant Gestion des erreurs Opérations liées

`opération $bulk-member-match` pour HealthLake

AWS HealthLake prend en charge l'$bulk-member-matchopération de traitement asynchrone des demandes de correspondance de plusieurs membres. Cette opération permet aux établissements de santé de faire correspondre efficacement les identifiants uniques de centaines de membres dans différents systèmes de santé en utilisant des informations démographiques et de couverture dans une seule demande groupée. Cette capacité est essentielle pour l'échange de données de payeur à payeur à grande échelle, les transitions de membres et les exigences de conformité du CMS et est conforme à la spécification FHIR.

Note

L'$bulk-member-matchopération est basée sur une spécification FHIR sous-jacente qui est actuellement expérimentale et sujette à modification. Au fur et à mesure de l'évolution des spécifications, le comportement et l'interface de cette API seront mis à jour en conséquence. Il est conseillé aux développeurs de surveiller les notes de HealthLake publication d'AWS et les mises à jour pertinentes des spécifications FHIR afin de rester informés de toute modification susceptible d'avoir un impact sur leurs intégrations.

Cette opération est particulièrement utile lorsque vous devez :

Procédez au jumelage des membres à grande échelle pendant les périodes d'inscription ouvertes
Faciliter les transitions de membres en masse entre les payeurs
Support des exigences d'échange de données de conformité des CMS à grande échelle
Associez efficacement les cohortes de membres à travers les réseaux de santé
Minimisez les appels d'API et améliorez l'efficacité opérationnelle pour les scénarios de mise en correspondance de volumes élevés

Usage

L'$bulk-member-matchopération est une opération asynchrone invoquée sur les ressources du groupe à l'aide de la méthode POST :


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

Après avoir soumis une demande de correspondance groupée, vous pouvez consulter le statut du poste en utilisant :


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

Chaque demande prend en charge jusqu'à 500 membres avec une charge utile maximale de 5 Mo.

Démarrage rapide

Pour commencer à utiliser Bulk Member Match, procédez comme suit :

Soumettez une demande de correspondance groupée à MemberBundles l'aide de l'Group/$bulk-member-matchopération. La réponse inclut un identifiant de tâche.
Vérifiez l'état de la tâche à l'aide de l'$bulk-member-match-statusopération jusqu'à ce que le statut soit TERMINÉ.
Extrayez l'ID de MatchedMembers groupe de la réponse à la tâche terminée.
Exportez les données cliniques en utilisant l'Group/$davinci-data-exportopération sur le groupe correspondant.

Paramètres pris en charge

HealthLake prend en charge les $bulk-member-match paramètres FHIR suivants :

Paramètre	Type	Obligatoire	Description
`MemberPatient`	Patient	Oui	Ressource destinée aux patients contenant des informations démographiques pour le membre à jumeler.
`CoverageToMatch`	Couverture	Oui	Ressource de couverture qui sera utilisée pour la comparaison avec les enregistrements existants.
`CoverageToLink`	Couverture	Non	Ressource de couverture à associer pendant le processus de mise en correspondance.
`Consent`	Consentement	Oui	La ressource de consentement à des fins d'autorisation est également stockée. Cela est différent de l'`$member-match`opération individuelle pour laquelle le consentement n'est pas requis.

Demande POST pour soumettre un job correspondant en masse à des membres

L'exemple suivant montre une demande POST visant à soumettre un job de mise en relation groupé de membres. Chaque membre est encapsulé dans un MemberBundle paramètre contenant les Consent ressources requises MemberPatientCoverageToMatch, ainsi qu'un paramètre facultatifCoverageToLink.


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

Réponse à la tâche terminée avec sortie

Lorsque le travail est terminé, la réponse inclut les métadonnées du travail et une ressource de paramètres FHIR contenant trois ressources de groupe qui catégorisent les résultats du match.


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

Comment HealthLake classifie les membres en groupes de sortie

Chaque membre soumis dans une $bulk-member-match demande est évalué par le biais d'un pipeline séquentiel. Le résultat de chaque étape détermine le groupe de sortie dans lequel le membre est placé.

Validation structurale — MemberBundle Sont-ils conformes aux profils requis ? En cas d'échec : erreur (dans aucun groupe).
Correspondance des patients : puis-je HealthLake trouver des patients correspondant aux données démographiques soumises ? En cas de panne : NonMatchedMembers.
Confirmation de couverture — Est-il possible de se HealthLake limiter à un seul patient valide CoverageToMatch ? En cas de panne : NonMatchedMembers.
Évaluation du consentement — Est-ce que cela provision.period couvre la date actuelle ? En cas de panne : ConsentConstrainedMembers.
Succès — Tous les chèques sont réussis. Consentement stocké dans une banque de données. Membre inscrit MatchedMembers.

Principe de base : un membre ne peut apparaître que dans une seule destination. La première étape défaillante détermine le placement. Les membres qui échouent aux étapes 2 ou 3 ne sont jamais inclus. Ce groupe est exclusivement réservé aux membres qui ont réussi le jumelage mais dont le consentement ne peut être honoré. ConsentConstrainedMembers

Détails de l'évaluation du consentement (étape 4) :

Période de mise à disposition : provision.period couvre la date actuelle ? Si la date actuelle est antérieure period.start ou postérieure period.end → ConsentConstrainedMembers.

Toutes les vérifications doivent être passées pour que le membre soit inscrit MatchedMembers et pour que le consentement soit conservé.

Note

L'opération ne valide pas la performer référence par rapport au patient champ. Un parent ou un tuteur peut donner son consentement au nom d'une personne à charge.

Le tableau suivant décrit comment la classification du consentement détermine le placement des membres :

Type de prestation	URI de la politique	Statut	Period	Outcome
`permit`	`#regular`	`active`	Couvre la date actuelle	MatchedMembers (Consentement enregistré)
`permit`	`#sensitive`	`active`	Couvre la date actuelle	MatchedMembers (Consentement enregistré)
`permit`	`#regular` ou `#sensitive`	`active`	Expiré ou non démarré	ConsentConstrainedMembers
`deny`	N’importe lequel	N’importe lequel	N’importe lequel	400 Mauvaise demande (étape 1)
`permit`	Ne se terminant pas par `#regular` ou `#sensitive`	N’importe lequel	N’importe lequel	400 Mauvaise demande (étape 1)
N’importe lequel	N’importe lequel	Non `active`	N’importe lequel	400 Mauvaise demande (étape 1)

Comportement de correspondance de couverture

Lors de la mise en correspondance des membres, seule la validation CoverageToMatch est effectuée par rapport à la banque de données du payeur répondant. CoverageToLinkappartient au new/requesting payeur et n'est pas validé par rapport à la banque de données de l'ancien payeur. L'inclusion CoverageToLink dans la demande n'affectera pas les résultats correspondants.

Chaque combinaison patient+couverture figurant dans la demande est traitée indépendamment. Le même patient peut être soumis plusieurs fois avec différents plans de couverture, et chaque inscription reçoit son propre résultat en fonction de sa couverture spécifique.

Gestion des références aux exécutants du consentement

Le nouveau payeur peut envoyer une référence de patient temporaire ou locale Consent.performer (par exemple, la même référence utilisée dansConsent.patient). HealthLake résout automatiquement ces références :

S'il Consent.performer contient la même référence locale queConsent.patient, il la HealthLake remplace par la référence réelle du patient correspondant une fois l'appariement réussi.
HealthLake prend en charge les références d'intervenants de type Patient RelatedPerson PractitionerRole, Practitioner et Organization (références directes et références d'identification logiques).
La performer référence n'est pas validée par rapport àpatient. Un parent/guardian consentement au nom d'une personne à charge est valide et ne dirigera pas le membre vers ConsentConstrainedMembers.

Ressources du groupe de sortie

La tâche terminée renvoie une ressource Parameters contenant trois ressources de groupe :

MatchedMembers Groupe: Contient les références des patients pour tous les membres correspondants dont le consentement est actif et valide au moment de la demande. La ressource Consent est créée et stockée dans la banque de données pour chaque membre correspondant. Ce groupe est instancié dans la banque de données et peut être utilisé directement avec. $davinci-data-export
NonMatchedMembers Groupe: Contient des références à des membres pour lesquels aucune correspondance unique n'a été trouvée. Un membre est placé ici lorsqu'aucun patient de la banque de données ne correspond aux données démographiques fournies, qu'il n'existe aucune couverture valide pour un patient candidat correspondant, ou lorsque plusieurs patients correspondent aux données démographiques et que plusieurs d'entre eux ont une couverture valide (ambigu). Ce groupe n'est pas instancié dans la banque de données. Il n'existe que dans la réponse à la tâche terminée.
ConsentConstrainedMembers Groupe: Contient des références de patients pour les membres qui ont été jumelés avec succès (données démographiques et couverture confirmées) mais dont le consentement ne peut être honoré au moment de la demande. La ressource de consentement n'est pas stockée pour les membres soumis à des contraintes de consentement. L'identité du membre correspondant (MemberIdentifier et MemberId) est toujours incluse afin que le payeur demandeur sache qui a été contraint. Ce groupe n'est pas instancié dans la banque de données. Il n'existe que dans la réponse à la tâche terminée.

Le Group.quantity champ contient le nombre total de membres dans chacun de leurs groupes respectifs.

Références des membres du groupe :

Group.member.entity.reference— Pour MatchedMembers et ConsentConstrainedMembers, contient l'identifiant patient du membre correspondant dans le système du payeur répondant. Pour NonMatchedMembers, fait référence à l'entrée Patient contenue.
Group.member.entity.extension (base-ext-match-parameters)— Contient l'identifiant du patient issu de la demande d'entrée initiale (l'identifiant soumis par le payeur demandeurPatient.id, dérivé deCoverage.beneficiary.reference, ouConsent.patient.reference).

Important

La ressource de consentement stockée conserve la référence du patient exactement telle qu'elle a été soumise par le payeur demandeur. HealthLake ne met pas automatiquement à jour le champ patient du consentement pour qu'il pointe vers le patient correspondant dans la banque de données réceptrice.

Pour lier un consentement enregistré au patient correspondant, utilisez le résultat de la tâche : chaque membre du MatchedMembers groupe member.entity.reference pointe vers le patient correspondant et un member.entity.extension (base-ext-match-parameters) pointant vers le patient saisi contenu. Cross-reference ceux-ci avec le champ patient du consentement pour créer le mappage dans votre couche d'application.

Ce qui est stocké par rapport à ce qui est transitoire

Le tableau suivant décrit ce qui est HealthLake conservé dans la banque de données pendant le $bulk-member-match traitement et ce qui n'existe que dans la réponse à la tâche :

Ressource	Stocké ?	Interrogable via REST ?	Remarques
MemberPatient (entrée)	Non	Non	Utilisé uniquement pour la mise en correspondance ; non persistant
CoverageToMatch (entrée)	Non	Non	Utilisé uniquement pour confirmer la couverture
CoverageToLink (entrée)	Non	Non	Non validé par rapport à la banque de données ; appartient au nouveau payeur
Consentement (membres correspondants)	Oui	Oui — GET [base] /Consent/ {id}	Stocké tel qu'il a été reçu du payeur demandeur
Consentement (membres limités)	Non	Non	Non stocké. L'identité du membre est toujours incluse dans la réponse.
MatchedMembers Groupe (sortie)	Oui	Oui — GET [base] /Group/ {id}	Instancié ; utilisable avec $davinci-data-export
NonMatchedMembers Groupe	Non	Non	Réponse au job uniquement
ConsentConstrainedMembers Groupe	Non	Non	Réponse au job uniquement

Intégration avec $davinci-data-export

La ressource de MatchedMembers groupe renvoyée par $bulk-member-match peut être directement utilisée avec l'$davinci-data-exportopération de récupération des données des membres en masse :


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

Cette intégration permet des flux de travail efficaces dans lesquels vous identifiez d'abord les membres correspondants en masse, puis exportez leurs dossiers médicaux complets à l'aide de la ressource de groupe qui en résulte.

Utiliser $member-remove avant l'exportation

Si vous devez exclure des membres spécifiques de l'exportation après le rapprochement (par exemple, un membre révoque son consentement entre le rapprochement et l'exportation), utilisez-le $member-remove sur le MatchedMembers groupe.

Important

La suppression d'un membre $member-remove marque le membre comme inactif dans le groupe, mais exclut $davinci-data-export uniquement les membres inactifs une fois que le groupe est passé au statut « final ». Si vous faites appel $davinci-data-export à un groupe qui possède toujours le statut par défaut, les membres supprimés peuvent toujours apparaître dans les résultats d'exportation.

Flux de travail :

POST [base]/Group/{id}/$member-remove— marque les membres inactifs
PUT [base]/Group/{id}— mettre à jour le statut du groupe à « final »
POST [base]/Group/{id}/$davinci-data-export— l'export exclut désormais les membres supprimés

Caractéristiques de performance

L'$bulk-member-matchopération est conçue pour le traitement de gros volumes et s'exécute de manière asynchrone :

Simultanéité : maximum de 5 opérations simultanées par magasin de données.
Évolutivité : gère jusqu'à 500 membres par demande (limite de charge utile de 5 Mo).
Opérations parallèles : compatible avec les opérations simultanées d'importation, d'exportation ou de suppression en bloc.

Autorisation

L'API utilise le protocole d'autorisation SMART on FHIR avec les étendues requises suivantes :

system/Patient.read— Nécessaire pour rechercher et associer les ressources destinées aux patients.
system/Coverage.read— Nécessaire pour valider les informations de couverture.
system/Group.write— Nécessaire pour créer des ressources de groupe de résultats.
system/Organization.read— Conditionnel, obligatoire si la couverture fait référence à des organisations.
system/Practitioner.read— Conditionnel, obligatoire si la couverture fait référence à des praticiens.
system/PractitionerRole.read— Conditionnel, obligatoire si la couverture fait référence aux rôles des praticiens.
system/Consent.write— Conditionnel, obligatoire si des ressources de consentement sont fournies.

L'opération prend également en charge AWS l'autorisation IAM Signature Version 4 (SigV4) pour l'accès programmatique.

Règles de validation

Les règles de validation suivantes sont appliquées à chacune MemberBundle à l'étape 1. Les membres dont la validation échoue sont signalés comme des erreurs et n'apparaissent dans aucun groupe de sortie.

MemberPatient

Champ	Comment HealthLake l'utilise	Échec de validation si...
`name.family`	Recherche démographique	Manquant
`name.given`	Recherche démographique	Manquant (au moins un élément requis)
`birthDate`	Recherche démographique	Manquant
`gender`	Recherche démographique ; en cas d'absence, extension Birth Sex utilisée	Ni sexe ni sexe de naissance présents (hrex-pat-1)
`identifier`	Inclus dans la recherche lorsqu'il est présent ; améliore la confiance	Ne cause jamais de panne (facultatif)

CoverageToMatch / CoverageToLink

Champ	Comment HealthLake l'utilise	Échec de validation si...
`status`	Confirme que la couverture est exploitable	Manquant
`beneficiary`	Associe la couverture à un patient candidat	Manquant
`relationship`	Confirme la relation abonné-bénéficiaire	Manquant
`identifier (MB) or subscriberId`	Clé de désambiguïsation principale	Aucun des deux

Champ	Comment HealthLake l'utilise	Échec de validation si...
`scope`	Confirme que la portée du consentement est axée sur la confidentialité des patients	Code de confidentialité des patients manquant ou inexistant
`category`	Confirme la classification des informations	Manquant
`patient`	Identifie le sujet du consentement	Manquant
`performer`	Identifie qui est d'accord	Manquant
`sourceReference`	Documente la source du consentement	Manquant
`policy.uri`	Détermine l'étendue du partage de données	URI manquant ou ne se terminant pas par #regular ou #sensitive
`provision.type`	Doit être un « permis » selon le profil de consentement HRex	« Permis » manquant ou non (y compris « refus »)
`provision.period`	Évalué à l'étape 4 pour une vérification sous réserve de consentement	Manquant ou non start/end
`provision.actor`	Identifie les payeurs sources et destinataires	Manquant ou n'inclut pas les acteurs source et destinataire requis selon le profil HReX
`provision.action`	Confirme l'action de divulgation	Code « à divulguer » manquant ou inexistant
`status`	Doit être « actif » selon HRex IG	Non « actif » : renvoie 400 erreurs de validation

Note

Selon le HRex IG, Consent.status il est fixé à « actif ». HealthLake applique cela à l'étape 1 (validation structurelle) et renvoie une erreur de validation 400 si un autre statut est fourni. Non-active le consentement ne sera pas traité ni classé en ConsentConstrainedMembers : il est rejeté dès le départ.

Comportement correspondant

Recherche d'un patient (étape 2) : HealthLake recherche en utilisant name.family + name.given (exact, sans distinction birthDate majuscules/majuscules), gender (exact ; sexe de naissance utilisé en l'absence de sexe) et identifier (le cas échéant, facultatif).
Désambiguïsation de la couverture (étape 3) — Lorsque plusieurs patients candidats sont trouvés, elle CoverageToMatch est utilisée pour se limiter à un seul. Une couverture est « valide » lorsqu'une ressource de couverture active existe dans la banque de données correspondant à subscriberId ou identifier (type MB).
Évaluation du consentement (étape 4) — Effectuée uniquement après une correspondance unique réussie. Consultez la section sur les détails de l'évaluation du consentement ci-dessus.

Gestion des erreurs

L'opération gère les conditions d'erreur suivantes :

400 Mauvaise demande : format de demande non valide, paramètres requis manquants ou charge utile supérieure aux limites de taille (500 membres ou 5 Mo).
422 Entité intraitable : erreurs de traitement lors de l'exécution de la tâche.

Erreurs relatives à un membre individuel : lorsqu'un membre en particulier échoue, l'opération se poursuit avec les membres restants et inclut les détails de l'erreur avec les codes de motif appropriés. Par exemple, un MemberBundle Patient dont le birthDate paramètre est absent renverra le message d'erreur suivant :


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

Les détails de l'erreur sont disponibles via le point de terminaison du sondage d'état et incluent :

numberOfMembersWithCustomerError: Nombre de membres présentant des erreurs de validation ou de saisie.
numberOfMembersWithServerError: nombre de membres présentant des erreurs de traitement côté serveur.

$member-matchopération pour HealthLake— Opération de mise en correspondance de membres individuels.
Opération FHIR R4 $davinci-data-export pour HealthLake— Exportation de données en masse à l'aide des ressources du groupe.
FHIR R4 pour $operations HealthLake— Liste complète des opérations prises en charge.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

$bulk-delete

$confirm-attribution-list

opération $bulk-member-match pour HealthLake

Note

Usage

Démarrage rapide

Paramètres pris en charge

Demande POST pour soumettre un job correspondant en masse à des membres

Réponse à la tâche terminée avec sortie

Comment HealthLake classifie les membres en groupes de sortie

Note

Comportement de correspondance de couverture

Gestion des références aux exécutants du consentement

Ressources du groupe de sortie

Consent-Patient lien

Important

Ce qui est stocké par rapport à ce qui est transitoire

Intégration avec $davinci-data-export

Utiliser $member-remove avant l'exportation

Important

Caractéristiques de performance

Autorisation

Règles de validation

MemberPatient

CoverageToMatch / CoverageToLink

Consentement

Note

Comportement correspondant

Gestion des erreurs

Opérations liées

`opération $bulk-member-match` pour HealthLake