Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# `$member-match`opération pour HealthLake
AWS HealthLake soutient désormais le `$member-match` fonctionnement des ressources destinées aux patients, permettant aux établissements de santé de trouver l'identifiant unique d'un membre dans différents systèmes de santé à l'aide d'informations démographiques et de couverture. Cette opération est essentielle pour garantir la conformité au CMS et faciliter l'échange de payer-to-payer données sécurisé tout en préservant la confidentialité des patients.
Cette opération est particulièrement utile lorsque vous devez :
+ Permettre un échange sécurisé de données de santé entre les organisations
+ Assurer la continuité des soins aux patients dans les différents systèmes
+ Support des exigences de conformité du CMS
+ Faciliter l'identification précise des membres dans les réseaux de santé
## Usage
L'`$member-match`opération peut être invoquée sur les ressources du patient à l'aide de la méthode POST :
```
POST [base]/Patient/$member-match
```
## Paramètres pris en charge
HealthLake prend en charge les `$member-match` paramètres FHIR suivants :
| Paramètre | Type | Obligatoire | Par défaut | 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 jumelage |
| Consentement | Consentement | Non | — | Ressource de consentement à des fins d'autorisation |
## Exemples
### Requête POST avec paramètres
```
POST [base]/Patient/$member-match
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Jones",
"given": ["Sarah"]
}
],
"gender": "female",
"birthDate": "1985-05-15"
}
},
{
"name": "CoverageToMatch",
"resource": {
"resourceType": "Coverage",
"status": "active",
"beneficiary": {
"reference": "Patient/1"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self",
"display": "Self"
}
]
},
"payor": [
{
"reference": "Organization/payer456"
}
]
}
},
{
"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/1"
},
"performer": [
{
"reference": "Patient/patient123"
}
],
"sourceReference": {
"reference": "Document/someconsent"
},
"policy": [
{
"uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular"
}
]
}
}
]
}
```
### Exemple de réponse
L'opération renvoie une ressource Parameters contenant les résultats correspondants :
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberIdentifier",
"valueIdentifier": {
"system": "http://hospital.org/medical-record-number",
"value": "MRN-123456"
}
},
{
"name": "MemberId",
"valueReference": {
"reference": "Patient/patient123"
}
},
{
"name": "matchAlgorithm",
"valueString": "DEMOGRAPHIC_MATCH"
},
{
"name": "matchDetails",
"valueString": "Demographic match: DOB + Name"
},
{
"name": "matchedFields",
"valueString": "given,birthdate,gender,family"
}
]
}
```
## Paramètres de réponse
La réponse inclut les paramètres suivants lorsqu'une correspondance est trouvée :
| Paramètre | Type | Description |
| --- | --- | --- |
| MemberIdentifier | Identifiant | L'identifiant unique du membre correspondant |
| MemberId | Référence | Référence à la ressource destinée aux patients |
| Algorithme de correspondance | String | Type d'algorithme de correspondance utilisé (EXACT\$1MATCH, STRONG\$1MATCH ou DEMOGRAPHIC\$1MATCH) |
| Détails du match | String | Informations détaillées sur le processus de mise en correspondance |
| Champs correspondants | String | Liste des champs spécifiques qui ont été correctement mis en correspondance |
## Algorithmes correspondants
L'`$member-match`API utilise une approche de correspondance à plusieurs niveaux pour garantir une identification précise des membres :
MATCH EXACT
Utilise l'identifiant du patient combiné à la couverture SubscriberId
Fournit le niveau de confiance le plus élevé pour le jumelage des membres
STRONG\$1MATCH
Utilise l'identifiant du patient avec les informations de couverture minimales
Offre un niveau de confiance élevé lorsque les critères de correspondance exacts ne sont pas respectés
MATCH DÉMOGRAPHIQUE
S'appuie sur des informations démographiques de base
Utilisé lorsque la correspondance basée sur un identifiant n'est pas possible
## Comportement
L'`$member-match`opération :
+ Accepte les données démographiques des patients, les détails de la couverture et les informations de consentement facultatives en entrée
+ Renvoie un identifiant de membre unique qui peut être utilisé pour les interactions suivantes
+ Met en œuvre un appariement à plusieurs niveaux (exact, solide, démographique) pour garantir l'identification précise des membres dans les différents systèmes de santé
+ Enregistre toutes les informations de consentement fournies à des fins d'autorisation futures
+ Permet un échange de payer-to-payer données sécurisé tout en préservant la confidentialité des patients
+ Conforme aux exigences du CMS pour l'échange de données de santé
## Autorisation
L'API utilise le protocole d'autorisation SMART on FHIR avec les étendues requises suivantes :
+ `system/Patient.read`
+ `system/Coverage.read`
+ `system/Organization.read`(conditionnel)
+ `system/Practitioner.read`(conditionnel)
+ `system/PractitionerRole.read`(conditionnel)
+ `system/Consent.write`(conditionnel)
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ `400 Bad Request`: `$member-match` opération non valide (demande non conforme ou paramètres obligatoires manquants)
+ `422 Unprocessable Entity`: Aucune correspondance ou plusieurs correspondances trouvées