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.
# FHIR R4 pour `$operations` HealthLake
Les opérations FHIR \$1 (également appelées « opérations dollar ») sont des fonctions spéciales côté serveur qui vont au-delà des opérations CRUD (`Create`,, `Read``Update`,`Delete`) standard de la spécification FHIR. Ces opérations sont identifiées par le préfixe « \$1 » et permettent un traitement complexe, une transformation de données et des opérations en masse qui seraient difficiles ou inefficaces à effectuer à l'aide d'appels d'API REST standard. Les opérations \$1 peuvent être invoquées au niveau du système, au niveau du type de ressource ou sur des instances de ressources spécifiques, offrant ainsi des moyens flexibles d'interagir avec les données FHIR. AWS HealthLake prend en charge plusieurs FHIR`$operations`. Veuillez vous référer à chacune des pages ci-dessous pour plus de détails.
**Topics**
+ [Fonctionnement du FHIR R4 `$attribution-status` pour HealthLake](reference-fhir-operations-attribution-status.md)
+ [Supprimer des types de ressources avec `$bulk-delete`](reference-fhir-operations-bulk-delete.md)
+ [`$bulk-member-match`opération pour HealthLake](reference-fhir-operations-bulk-member-match.md)
+ [Fonctionnement du FHIR R4 `$confirm-attribution-list` pour HealthLake](reference-fhir-operations-confirm-attribution-list.md)
+ [Fonctionnement du FHIR R4 `$davinci-data-export` pour HealthLake](reference-fhir-operations-davinci-data-export.md)
+ [Génération de documents cliniques avec `$document`](reference-fhir-operations-document.md)
+ [Suppression permanente de ressources avec `$erase`](reference-fhir-operations-erase.md)
+ [Obtenir les données des patients avec `Patient/$everything`](reference-fhir-operations-everything.md)
+ [Récupération de ValueSet codes avec `$expand`](reference-fhir-operations-expand.md)
+ [Exporter HealthLake des données avec FHIR `$export`](reference-fhir-operations-export.md)
+ [`$inquire`Opération FHIR pour HealthLake](reference-fhir-operations-inquire.md)
+ [Récupération des détails du concept avec `$lookup`](reference-fhir-operations-lookup.md)
+ [`$member-add`opération pour HealthLake](reference-fhir-operations-member-add.md)
+ [`$member-match`opération pour HealthLake](reference-fhir-operations-member-match.md)
+ [`$member-remove`opération pour HealthLake](reference-fhir-operations-member-remove.md)
+ [Supprimer les ressources du compartiment réservé aux patients grâce à `$purge`](reference-fhir-operations-purge.md)
+ [`$questionnaire-package`Opération FHIR pour HealthLake](reference-fhir-operations-questionnaire-package.md)
+ [`$submit`Opération FHIR pour HealthLake](reference-fhir-operations-submit.md)
+ [Validation des ressources FHIR avec `$validate`](reference-fhir-operations-validate.md)
# Fonctionnement du FHIR R4 `$attribution-status` pour HealthLake
Récupère le statut d'attribution d'un membre spécifique, renvoyant un bundle contenant toutes les ressources d'attribution liées au patient. Cette opération fait partie de la mise en œuvre de la [version 2.1.0 de la liste d'attribution des membres FHIR (ATR) List IG](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Endpoint
```
POST [base]/Group/[id]/$attribution-status
```
## Paramètres de demande
L'opération accepte les paramètres facultatifs suivants :
| Paramètre | Type | Description |
| --- | --- | --- |
| memberId | Identifiant | Le MemberId membre pour lequel le statut d'attribution est demandé |
| Référence du patient | Référence | Référence à la ressource pour les patients dans le système du producteur |
**Note**
L'un `memberId` ou l'autre `patientReference` peut être fourni, ou les deux à des fins de validation.
## Exemple de demande
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org",
"value": "MBR123456789"
}
},
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123",
"display": "John Doe"
}
}
]
}
```
## Réponse
Renvoie un bundle contenant des ressources d'attribution liées au patient :
| Ressource | Cardinalité | Location |
| --- | --- | --- |
| Patient | 1..1 | Groupe.membre/entité |
| Couverture | 0,1 | Group.Member.Extension : CoverageReference |
| Organization/Practitioner/PractitionerRole | 0,1 | group.member.extension : fournisseur attribué |
| N'importe quelle ressource | 0,1 | group.member.extension : données associées |
### Exemple de réponse
```
{
"resourceType": "Bundle",
"id": "bundle-response",
"meta": {
"lastUpdated": "2014-08-18T01:43:33Z"
},
"type": "collection",
"entry": [
{
"fullUrl": "http://example.org/fhir/Patient/12423",
"resource": {
"resourceType": "Patient",
"id": "12423",
"meta": {
"versionId": "1",
"lastUpdated": "2014-08-18T01:43:31Z"
},
"active": true,
"name": [
{
"use": "official",
"family": "Chalmers",
"given": ["Peter", "James"]
}
],
"gender": "male",
"birthDate": "1974-12-25"
}
},
{
"fullUrl": "http://example.org/fhir/Coverage/123456",
"resource": {
"resourceType": "Coverage",
"id": "1"
// ... additional Coverage resource details
}
},
{
"fullUrl": "http://example.org/fhir/Organization/666666",
"resource": {
"resourceType": "Organization",
"id": "2"
// ... additional Organization resource details
}
}
]
}
```
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
| Erreur | État du protocole HTTP | Description |
| --- | --- | --- |
| Demande d'opération non valide | 400 | Paramètres ou structure de demande non conformes |
| Ressource de groupe introuvable | 404 | L'ID de groupe spécifié n'existe pas |
| Ressource pour les patients introuvable | 404 | La référence du patient spécifiée n'existe pas |
## Autorisation et sécurité
Exigences relatives à SMART Scope
Les clients doivent disposer des privilèges appropriés pour lire les ressources du groupe et les ressources d'attribution associées
Les mécanismes d'autorisation FHIR standard s'appliquent à toutes les opérations
# Supprimer des types de ressources avec `$bulk-delete`
AWS HealthLake prend en charge l'`$bulk-delete`opération en permettant de supprimer toutes les ressources d'un type spécifique au sein d'une banque de données. Cette opération est particulièrement utile lorsque vous devez :
+ Réaliser un audit saisonnier et un nettoyage
+ Gérez le cycle de vie des données à grande échelle
+ Supprimer des types de ressources spécifiques
+ Respectez les politiques de conservation des données
## Usage
L'`$bulk-delete`opération peut être invoquée à l'aide des méthodes POST :
```
POST [base]/[ResourceType]/$bulk-delete?isHardDelete=false&deleteAuditEvent=true
```
## Parameters
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| isHardDelete | booléen | Non | false | Lorsque c'est vrai, supprime définitivement les ressources du stockage |
| deleteAuditEvent | boolean | Non | true | Lorsque c'est vrai, supprime les événements d'audit associés |
| \$1since | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite de début pour rechercher les ressources en fonction de leur heure de dernière modification. Ne peut pas être utilisé avec le début ou la fin |
| start | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite pour rechercher les ressources en fonction de leur heure de dernière modification. Peut être utilisé avec extrémité |
| end | chaîne | Non | Heure de soumission des offres d'emploi | Une fois saisi, sélectionne l'heure limite de fin pour rechercher les ressources en fonction de leur heure de dernière modification |
## Exemples
**Exemple de requête**
```
POST [base]/Observation/$bulk-delete?isHardDelete=false
```
**Exemple de réponse**
```
{
"jobId": "jobId",
"jobStatus": "SUBMITTED"
}
```
## Statut de la tâche
Pour vérifier le statut d'une tâche de suppression en bloc, procédez comme suit :
```
GET [base]/$bulk-delete/[jobId]
```
L'opération renvoie les informations relatives à l'état de la tâche :
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2025-10-09T15:09:51.336Z"
}
```
## Comportement
L'`$bulk-delete`opération :
1. Processus asynchrones pour gérer de gros volumes de ressources
1. Maintient les transactions ACID pour garantir l'intégrité des données
1. Fournit un suivi de l'état des tâches avec le nombre de ressources supprimées
1. Supporte les modes de suppression souple et rigide
1. Inclut un enregistrement d'audit complet des activités de suppression
1. Permet la suppression sélective des versions historiques et des événements d'audit
## Journalisation des audits
L'`$bulk-delete`opération est enregistrée sous les noms Start FHIRBulk DeleteJob et Describe FHIRBulk DeleteJob avec des informations détaillées sur l'opération.
## Limitations
+ Lorsque `isHardDelete` ce paramètre est défini sur true, les ressources supprimées définitivement n'apparaissent pas dans les résultats de recherche ni dans les `_history` requêtes.
+ Les ressources supprimées par cette opération peuvent être temporairement inaccessibles pendant le traitement
+ La mesure du stockage est ajustée uniquement sur les versions historiques - deleteVersionHistory =false n'ajustera pas le stockage de la banque de données
# `$bulk-member-match`opération pour HealthLake
AWS HealthLake prend en charge l'`$bulk-member-match`opé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 fonctionnalité est essentielle pour l'échange de payer-to-payer données à grande échelle, les transitions de membres et les exigences de conformité au CMS et est conforme à la [spécification](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html) FHIR.
**Note**
L'`$bulk-member-match`opé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-match`opé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}
```
## 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 en masse un job correspondant à un nombre de 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 `MemberPatient``CoverageToMatch`, ainsi qu'un paramètre facultatif`CoverageToLink`.
```
POST [base]/Group/$bulk-member-match
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberBundle",
"part": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-0"
}
],
"name": [
{
"family": "Smith",
"given": ["James"]
}
],
"gender": "male",
"birthDate": "1950-01-01"
}
},
{
"name": "CoverageToMatch",
"resource": {
"resourceType": "Coverage",
"status": "active",
"identifier": [
{
"system": "http://example.org/coverage-id",
"value": "cov-0"
}
],
"subscriberId": "sub-0",
"beneficiary": {
"reference": "Patient/patient123"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self"
}
]
},
"payor": [
{
"reference": "Organization/org123"
}
]
}
},
{
"name": "Consent",
"resource": {
"resourceType": "Consent",
"status": "active",
"scope": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentscope",
"code": "patient-privacy"
}
]
},
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IDSCL"
}
]
}
],
"patient": {
"reference": "Patient/patient123"
},
"performer": [
{
"reference": "Patient/patient123"
}
],
"sourceReference": {
"reference": "http://example.org/DocumentReference/consent-source"
},
"policy": [
{
"uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular"
}
],
"provision": {
"type": "permit",
"period": {
"start": "2024-01-01",
"end": "2025-12-31"
},
"actor": [
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "performer"
}
]
},
"reference": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "9876543210"
},
"display": "Old Health Plan"
}
},
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
"code": "IRCP"
}
]
},
"reference": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "0123456789"
},
"display": "New Health Plan"
}
}
],
"action": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentaction",
"code": "disclose"
}
]
}
]
}
}
},
{
"name": "CoverageToLink",
"resource": {
"resourceType": "Coverage",
"status": "active",
"identifier": [
{
"system": "http://example.org/coverage-link-id",
"value": "cov-link-0"
}
],
"subscriberId": "new-sub-0",
"beneficiary": {
"reference": "Patient/patient123"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self"
}
]
},
"payor": [
{
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "0123456789"
},
"display": "New Health Plan"
}
]
}
}
]
}
]
}
```
## 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": "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"
}
}
]
}
}
]
}
}
```
## 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 correctement mis en correspondance et n'est pas classé dans la catégorie des contraintes de consentement.
Le `Group.quantity` champ contient le nombre total de membres dans chacun de leurs groupes respectifs.
**NonMatchedMembers Groupe**
Contient des références aux membres pour lesquels aucune correspondance n'a été trouvée ou plusieurs correspondances ont été identifiées.
**ConsentConstrainedMembers Groupe**
Contient des références de patients pour tous les membres mis en correspondance avec succès lorsque les contraintes de consentement empêchent le partage de données. Une ressource de consentement est considérée comme limitée lorsque les deux conditions suivantes sont présentes :
+ **L'URI de la politique se termine par `#sensitive`** — Il s'agit du signal le plus clair et le plus direct. Le payeur soumissionnaire déclare explicitement : « Les données de ce membre sont sensibles, manipulez-les avec soin ».
```
"policy": [{ "uri": "...hrex-consent.html#sensitive" }]
```
+ **Le type de disposition de niveau supérieur est** le `deny` suivant : le membre a largement refusé le partage de données.
```
"provision": { "type": "deny" }
```
## Intégration avec \$1 davinci-data-export
La ressource de MatchedMembers groupe renvoyée par `$bulk-member-match` peut être directement utilisée avec l'`$davinci-data-export`opé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.
## Caractéristiques de performance
L'`$bulk-member-match`opé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.
## 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 dans le NonMatchedMembers groupe 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.
## Opérations liées
+ [`$member-match`opération pour HealthLake](reference-fhir-operations-member-match.md)— Opération de mise en correspondance de membres individuels.
+ [Fonctionnement du FHIR R4 `$davinci-data-export` pour HealthLake](reference-fhir-operations-davinci-data-export.md)— Exportation de données en masse à l'aide des ressources du groupe.
+ [FHIR R4 pour `$operations` HealthLake](reference-fhir-operations.md)— Liste complète des opérations prises en charge.
# Fonctionnement du FHIR R4 `$confirm-attribution-list` pour HealthLake
Indique au producteur que le consommateur n'a plus aucune modification à apporter à la liste d'attribution. Cette opération finalise la liste d'attribution en supprimant les membres inactifs de la liste, en modifiant le statut en « final » et en accusant réception de l'opération. Cette opération fait partie de la mise en œuvre de la [version 2.1.0 de la liste d'attribution des membres FHIR (ATR) List IG](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Endpoint
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Demande
Aucun paramètre n'est requis.
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Réponse
Renvoie HTTP 201 avec un message de confirmation.
### Exemple de réponse
```
HTTP Status Code: 201
{
"resourceType": "Parameters",
"parameter": [
{
"name": "message",
"valueString": "Accepted."
}
]
}
```
## État du groupe après confirmation
Une fois la confirmation réussie, le statut de la liste d'attribution de la ressource du groupe sera défini sur « final » :
```
{
"resourceType": "Group",
"id": "fullexample",
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-atr/StructureDefinition/ext-attributionListStatus",
"valueCode": "final"
}
]
// ... other Group properties
}
```
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
| Erreur | État du protocole HTTP | Description |
| --- | --- | --- |
| Demande d'opération non valide | 400 | Paramètres ou structure de demande non conformes |
| Ressource de groupe introuvable | 404 | L'ID de groupe spécifié n'existe pas |
## Autorisation et sécurité
Exigences relatives à SMART Scope
Les clients doivent disposer des privilèges appropriés pour lire les ressources du groupe et les ressources d'attribution associées
En effet`$confirm-attribution-list`, les clients doivent également disposer de privilèges d'écriture pour modifier les ressources du groupe
Les mécanismes d'autorisation FHIR standard s'appliquent à toutes les opérations
# Fonctionnement du FHIR R4 `$davinci-data-export` pour HealthLake
Il s'agit d'une `$davinci-data-export` opération FHIR asynchrone à partir de laquelle vous pouvez exporter des données de santé. AWS HealthLake Cette opération prend en charge plusieurs types d'exportation, notamment l'attribution de membres (ATR) Payer-to-Payer, l'accès au PDex fournisseur et l'accès aux membres APIs. Il s'agit d'une version spécialisée de l'`$export`opération FHIR standard, conçue pour répondre aux exigences des guides de mise DaVinci en œuvre.
## Fonctionnalités principales
+ *Traitement asynchrone* : suit le modèle de demande asynchrone FHIR standard
+ Exportation *au niveau du groupe : exporte* les données pour les membres d'une ressource de groupe spécifique
+ *Plusieurs types d'exportation* : prend en charge l'ATR (attribution de membres) Payer-to-Payer, l'accès aux PDex fournisseurs et l'accès aux membres APIs
+ *Support complet pour les profils* : inclut US Core, CARIN Blue Button et PDex profils
+ *Filtrage flexible* : prend en charge le filtrage par patients, types de ressources et plages de temps
+ *Sortie NDJSON* : fournit des données au format JSON délimité par de nouvelles lignes
## Opération Endpoint
```
GET [base]/Group/[id]/$davinci-data-export
POST [base]/Group/[id]/$davinci-data-export
```
## Paramètres de demande
| Paramètre | Cardinalité | Description |
| --- | --- | --- |
| patient | 0.. \$1 | Membres spécifiques dont les données doivent être exportées. En cas d'omission, tous les membres du groupe sont exportés. |
| \$1type | 0,1 | Liste séparée par des virgules des types de ressources FHIR à exporter. |
| \$1since | 0,1 | N'incluez que les ressources mises à jour après cette date et cette heure. |
| \$1until | 0,1 | N'incluez que les ressources mises à jour avant cette date et cette heure. |
| exportType | 0,1 | Type d'export à effectuer. Valeurs valides: hl7.fhir.us.davinci-atr, hl7.fhir.us.davinci-pdex, hl7.fhir.us.davinci-pdex.p2p, hl7.fhir.us.davinci-pdex.member. Valeur par défaut : hl7.fhir.us.davinci-atr. |
| \$1includeEOB2xWoFinancial | 0,1 | Spécifie s'il faut inclure les ExplanationOfBenefit ressources CARIN BB 2.x avec les données financières supprimées. Valeur par défaut : false. |
### Types de ressource pris en charge
Les types de ressources pris en charge dépendent du type d'exportation que vous spécifiez. Pour les exportations ATR, les types de ressources suivants sont pris en charge :
+ `Group`
+ `Patient`
+ `Coverage`
+ `RelatedPerson`
+ `Practitioner`
+ `PractitionerRole`
+ `Organization`
+ `Location`
Pour les PDex exportations (accès fournisseur et accès membre), tous les types de ressources cliniques et de réclamations sont pris en charge en plus des types précédents. Payer-to-Payer Pour une liste complète des types de ressources pris en charge, consultez le [US Core Implementation Guide (STU 6.1)](https://hl7.org/fhir/us/core/STU6.1/), le [CARIN Blue Button Implementation Guide](https://hl7.org/fhir/us/carin-bb/) et le [Da Vinci Prior Authorization Support Implementation](https://hl7.org/fhir/us/davinci-pas/) Guide.
## Types d'exportation
L'`$davinci-data-export`opération prend en charge les types d'exportation suivants. Vous spécifiez le type d'exportation à l'aide du `exportType` paramètre.
| Type d'exportation | Objectif | Étendue des données | Limite temporelle |
| --- | --- | --- | --- |
| hl7.fhir.us.davinci-atr | Liste d'attribution des membres | Ressources liées à l'attribution | Aucune |
| hl7.fhir.us.davinci-pdex | API d'accès aux fournisseurs | Données cliniques et relatives aux demandes de remboursement pour les patients concernés | 5 ans |
| hl7.fhir.us.davinci-pdex.p2p | Payer-to-Payer Échange | Données historiques sur les membres pour les transitions d'assurance | 5 ans |
| hl7.fhir.us.davinci-pdex.member | API d'accès aux membres | Données de santé propres au membre | 5 ans |
**Note**
Pour les PDex exportations, la limite temporelle de 5 ans ne s'applique pas aux types de ressources ATR (`Group``Patient`,`Coverage`,`RelatedPerson`,`Practitioner`,`PractitionerRole`,`Organization`,`Location`). Ces ressources sont toujours incluses quel que soit l'âge.
### ATR (hl7.fhir.us.davinci-atr)
Avec le type d'exportation ATR, vous pouvez exporter les données de la liste d'attribution des membres. Utilisez ce type d'exportation pour récupérer les ressources liées à l'attribution pour les membres d'un groupe. Pour plus d'informations, consultez l'[opération d'exportation de Da Vinci ATR](https://build.fhir.org/ig/HL7/davinci-atr/OperationDefinition-davinci-data-export.html).
Types de ressource pris en charge
`Group`, `Patient`, `Coverage`, `RelatedPerson`, `Practitioner`, `PractitionerRole`, `Organization`, `Location`
Filtrage temporel
Aucun filtrage temporel n'est appliqué. Toutes les ressources correspondantes sont exportées quelle que soit la date.
### PDex Types d'exportation
Tous les types PDex d'exportation partagent les mêmes profils pris en charge et la même logique de filtrage. Pour plus d'informations, consultez l'[API Da Vinci PDex Provider Access](https://build.fhir.org/ig/HL7/davinci-epdx/provider-access-api.html). Les profils suivants sont pris en charge :
+ US Core 3.1.1, 6.1.0 et 7.0.0
+ PDex Autorisation préalable (non prise en charge pour l'accès des membres)
+ CARIN BB 2.x Profils de base : établissement hospitalier, établissement ambulatoire, professionnel, oral, pharmacie NonClinician
Accès au fournisseur (`hl7.fhir.us.davinci-pdex`)
Permet aux fournisseurs du réseau de récupérer les données des patients pour les patients auxquels ils ont été attribués.
Payer-to-Payer (`hl7.fhir.us.davinci-pdex.p2p`)
Permet l'échange de données entre les payeurs lorsqu'un patient change d'assurance.
Accès aux membres (`hl7.fhir.us.davinci-pdex.member`)
Permet aux membres d'accéder à leurs propres données de santé. Ce type d'exportation peut inclure des données financières dans les ressources relatives aux sinistres.
## Support du profil et logique d'inclusion
Pour les PDex exportations, l'`$davinci-data-export`opération utilise des déclarations de profil dans l'`meta.profile`élément pour déterminer les ressources à inclure dans l'exportation.
### ExplanationOfBenefit Gestion des ressources
`ExplanationOfBenefit`Les ressources (EOB) sont incluses ou exclues des PDex exportations en fonction de leurs `meta.profile` déclarations :
+ ExplanationOfBenefit les ressources dotées d'un profil CARIN BB 1.x sont exclues de l'exportation.
+ ExplanationOfBenefit les ressources non `meta.profile` définies sont exclues de l'exportation.
+ ExplanationOfBenefit les ressources avec un profil CARIN BB 2.x Basis sont toujours incluses.
+ ExplanationOfBenefit les ressources dotées d'un profil CARIN BB 2.x contenant des données financières sont exclues par défaut. Lorsqu'il `_includeEOB2xWoFinancial=true` est défini, ils sont inclus dans les données financières supprimées et la ressource est transformée selon le profil de base correspondant.
+ ExplanationOfBenefit les ressources avec un profil d'autorisation PDex préalable sont toujours incluses.
### Transformation des données financières
Lorsque vous le définissez`_includeEOB2xWoFinancial=true`, l'opération transforme les ExplanationOfBenefit ressources [CARIN BB 2.x](https://hl7.org/fhir/us/carin-bb/) en leurs profils de base correspondants en supprimant les données financières. Par exemple, une `C4BB ExplanationOfBenefit Oral` ressource est transformée en`C4BB ExplanationOfBenefit Oral Basis`, ce qui supprime les données financières de l'enregistrement conformément à la spécification FHIR.
Les éléments de données financières suivants sont supprimés lors de la transformation :
+ Tous les éléments sont tranchés `total`
+ Tous les `adjudication` éléments avec `amounttype` tranche
+ Tous les `item.adjudication` éléments avec des informations sur le montant
L'opération met également à jour les métadonnées du profil lors de la transformation :
+ `meta.profile`est mis à jour vers l'URL canonique du profil Basis
+ La version est mise à jour vers la version CARIN BB 2.x Basis
+ Les ressources existantes dans le magasin de données ne sont pas modifiées
+ Les ressources exportées ne sont pas renvoyées dans le magasin de données
### Règles de détection des profils
L'opération utilise les règles suivantes pour détecter et valider les profils :
+ La détection des versions est basée sur la norme `meta.profile` canonique URLs
+ Une ressource est incluse si l'un de ses profils déclarés correspond aux critères d'exportation
+ La validation du profil a lieu pendant le traitement de l'exportation
## Filtrage temporel quinquennal pour les PDex exportations
Pour tous les types PDex d'exportation, HealthLake applique un filtre temporel de 5 ans basé sur la date de dernière mise à jour de la ressource. Le filtre temporel s'applique à toutes les ressources, à l'exception des types de ressources d'attribution de base suivants, qui sont toujours exportés quel que soit leur âge :
+ `Patient`
+ `Coverage`
+ `Organization`
+ `Practitioner`
+ `PractitionerRole`
+ `RelatedPerson`
+ `Location`
+ `Group`
Ces ressources administratives et démographiques sont exemptées car elles fournissent un contexte essentiel pour les données exportées. Les exportations ATR ne sont soumises à aucun filtrage temporel.
## Exemple de demandes
Les exemples suivants montrent comment démarrer des tâches d'exportation pour différents types d'exportation.
*Exportation ATR*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
POST https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
Content-Type: application/json
{
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
"JobName": "attribution-export-job",
"OutputDataConfig": {
"S3Configuration": {
"S3Uri": "s3://your-export-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
}
}
```
*Exportation de l'accès au fournisseur avec suppression des données ExplanationOfBenefit financières*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,MedicationRequest,ExplanationOfBenefit&exportType=hl7.fhir.us.davinci-pdex&_includeEOB2xWoFinancial=true
```
*Payer-to-Payer exportation*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Coverage,ExplanationOfBenefit,Condition,Procedure&exportType=hl7.fhir.us.davinci-pdex.p2p&_includeEOB2xWoFinancial=true
```
*Exportation de l'accès aux membres pour un patient spécifique*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,ExplanationOfBenefit,MedicationRequest&exportType=hl7.fhir.us.davinci-pdex.member&patient=Patient/example-patient-id
```
## Exemple de réponse
```
{
"datastoreId": "eaee622d8406b41eb86c0f4741201ff9",
"jobStatus": "SUBMITTED",
"jobId": "48d7b91dae4a64d00d54b70862f33f61"
}
```
## Relations avec les ressources
L'opération exporte les ressources en fonction de leurs relations au sein de la liste d'attribution des membres :
```
Group (Attribution List)
├── Patient (Members)
├── Coverage → RelatedPerson (Subscribers)
├── Practitioner (Attributed Providers)
├── PractitionerRole → Location
└── Organization (Attributed Providers)
```
### Sources de ressources
| Ressource | Emplacement de la source | Description |
| --- | --- | --- |
| Patient | Group.member.entity | Les patients membres de la liste d'attribution |
| Coverage | Group.member.extension:coverageReference | Couverture qui a donné lieu à l'adhésion du patient |
| Organization | Group.member.extension:attributedProvider | Organisations auxquelles les patients sont attribués |
| Practitioner | Group.member.extension:attributedProvider | Praticiens individuels auxquels les patients sont attribués |
| PractitionerRole | Group.member.extension:attributedProvider | Rôles de praticiens auxquels les patients sont attribués |
| RelatedPerson | Coverage.subscriber | Abonnés de la couverture |
| Location | PractitionerRole.location | Lieux associés aux rôles des praticiens |
| Group | Point final d'entrée | La liste d'attribution elle-même |
## Gestion du Job
Vérifier le statut du job
`GET [base]/export/[job-id]`
Annuler une tâche
`DELETE [base]/export/[job-id]`
### Cycle de vie d'une tâche
+ `SUBMITTED`- Le job a été reçu et mis en file d'attente
+ `IN_PROGRESS`- Job en cours de traitement actif
+ `COMPLETED`- Job terminé avec succès, fichiers disponibles au téléchargement
+ `FAILED`- Job a rencontré une erreur
## Format de sortie
+ *Format de fichier* : NDJSON (JSON délimité par une nouvelle ligne)
+ *Organisation des fichiers* : fichiers distincts pour chaque type de ressource
+ *Extension de fichier* : .ndjson
+ *Emplacement* : compartiment et chemin S3 spécifiés
## Gestion des erreurs
L'opération renvoie une mauvaise demande HTTP 400 avec un OperationOutcome pour les conditions suivantes :
Erreurs d'autorisation
Le rôle IAM spécifié dans `DataAccessRoleArn` ne dispose pas des autorisations suffisantes pour effectuer l'opération d'exportation. Pour obtenir la liste complète des autorisations S3 et KMS requises, voir [Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
Erreurs de validation des paramètres
+ Le `patient` paramètre n'est pas formaté comme `Patient/id,Patient/id,...`
+ Une ou plusieurs références de patients ne sont pas valides ou n'appartiennent pas au groupe spécifié
+ La valeur du `exportType` paramètre n'est pas un type d'exportation pris en charge
+ Le `_type` paramètre contient les types de ressources qui ne sont pas pris en charge pour le type d'exportation spécifié
+ Le `_type` paramètre ne contient pas les types de ressources requis (`Group`,`Patient`,`Coverage`) pour le type `hl7.fhir.us.davinci-atr` d'exportation
+ La valeur du `_includeEOB2xWoFinancial` paramètre n'est pas une valeur booléenne valide
Erreurs de validation des ressources
+ La ressource de groupe spécifiée n'existe pas dans le magasin de données
+ La ressource de groupe spécifiée n'a aucun membre
+ Un ou plusieurs membres du groupe font référence à des ressources pour patients qui n'existent pas dans le magasin de données
## Sécurité et autorisation
+ Les mécanismes d'autorisation FHIR standard s'appliquent
+ Le rôle d'accès aux données doit disposer des autorisations IAM requises pour les opérations S3 et KMS. Pour obtenir la liste complète des autorisations requises, voir [Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
## Bonnes pratiques
+ *Sélection du type de ressource* : demandez uniquement les types de ressources dont vous avez besoin pour minimiser la taille des exportations et le temps de traitement
+ *Filtrage basé sur le temps* : utilisez le `_since` paramètre pour les exportations incrémentielles
+ *Filtrage des patients* : utilisez le `patient` paramètre lorsque vous n'avez besoin de données que pour des membres spécifiques
+ *Surveillance des tâches* : vérifiez régulièrement l'état des tâches pour les exportations importantes
+ *Gestion des erreurs* : implémentez une logique de nouvelle tentative appropriée pour les tâches ayant échoué
+ *Connaissance du filtre temporel* : pour les PDex exportations, considérez le filtre temporel de 5 ans lorsque vous sélectionnez les types de ressources
+ *Suppression des données financières* : à utiliser `_includeEOB2xWoFinancial=true` lorsque vous avez besoin de données relatives aux réclamations sans informations financières
+ *Gestion des profils* : assurez-vous que les ressources disposent de déclarations de profil appropriées, validez par rapport aux profils cibles avant l'ingestion et utilisez le versionnement des profils pour contrôler le comportement d'exportation
## Limitations
+ Un maximum de 500 patients peut être spécifié dans le `patient` paramètre
+ L'exportation est limitée aux opérations au niveau du groupe uniquement
+ Supporte uniquement l'ensemble prédéfini de types de ressources pour chaque type d'exportation
+ La sortie est toujours au format NDJSON
+ PDex les exportations sont limitées à 5 ans de données cliniques et de réclamations
+ La transformation des données financières ne s'applique qu'aux profils CARIN BB 2.x ExplanationOfBenefit
## Ressources supplémentaires
+ [Liste d'attribution des membres de Da Vinci IG](https://build.fhir.org/ig/HL7/davinci-atr/)
+ [Da Vinci Payer Data Exchange IG](https://hl7.org/fhir/us/davinci-pdex/)
+ [CARIN Consumer Directed Payer Data Exchange IG](https://build.fhir.org/ig/HL7/carin-bb/)
+ [Guide de mise en œuvre de base aux États-Unis](https://www.hl7.org/fhir/us/core/)
+ [Spécification d'accès aux données en masse FHIR](https://hl7.org/fhir/uv/bulkdata/)
# Génération de documents cliniques avec `$document`
AWS HealthLake prend désormais en charge le `$document` fonctionnement des ressources de composition, ce qui vous permet de générer un document clinique complet en regroupant la composition et toutes ses ressources référencées dans un seul package cohérent. Cette opération est essentielle pour les applications de santé qui doivent :
+ Créez des documents cliniques standardisés
+ Échangez les dossiers complets des patients
+ Stockez une documentation clinique complète
+ Générez des rapports qui incluent tous les contextes pertinents
## Usage
L'`$document`opération peut être invoquée sur les ressources de composition à l'aide des méthodes GET et POST :
**Opérations prises en charge**
```
GET/POST [base]/Composition/[id]/$document
```
## Paramètres pris en charge
HealthLake prend en charge le `$document` paramètre FHIR suivant :
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| persist | booléen | Non | false | Booléen indiquant si le serveur doit stocker le paquet de documents généré |
## Exemples
**Demande GET**
```
GET [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document?persist=true
```
**Requête POST avec paramètres**
```
POST [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "persist",
"valueBoolean": true
}
]
}
```
**Exemple de réponse**
L'opération renvoie une ressource Bundle de type « document » contenant la composition et toutes les ressources référencées :
```
{
"resourceType": "Bundle",
"id": "180f219f-97a8-486d-99d9-ed631fe4fc57",
"type": "document",
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:uuid:0c3151bd-1cbf-4d64-b04d-cd9187a4c6e0"
},
"timestamp": "2024-06-21T15:30:00Z",
"entry": [
{
"fullUrl": "http://example.org/fhir/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57",
"resource": {
"resourceType": "Composition",
"id": "180f219f-97a8-486d-99d9-ed631fe4fc57",
"status": "final",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "34133-9",
"display": "Summary of Episode Note"
}
]
},
"subject": {
"reference": "Patient/example"
},
"section": [
{
"title": "Allergies",
"entry": [
{
"reference": "AllergyIntolerance/123"
}
]
}
]
}
},
{
"fullUrl": "http://example.org/fhir/Patient/example",
"resource": {
"resourceType": "Patient",
"id": "example",
"name": [
{
"family": "Smith",
"given": ["John"]
}
]
}
},
{
"fullUrl": "http://example.org/fhir/AllergyIntolerance/123",
"resource": {
"resourceType": "AllergyIntolerance",
"id": "123",
"patient": {
"reference": "Patient/example"
},
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "418689008",
"display": "Allergy to penicillin"
}
]
}
}
}
]
}
```
## Comportement
L'`$document`opération :
1. Utilise la ressource de composition spécifiée comme base du document
1. Identifie et récupère toutes les ressources directement référencées par la composition
1. Regroupe la composition et toutes les ressources référencées dans un ensemble de type « document »
1. Stocke le paquet de documents généré dans la banque de données lorsque le paramètre persist est défini sur true
1. Identifie et récupère les ressources référencées indirectement par la composition pour une génération complète de documents
L'`$document`opération prend actuellement en charge la récupération de références de ressources au format suivant :
1.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Ressource/ID
Les références de ressources non prises en charge dans la ressource Composition seront éliminées du document généré.
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ 400 Mauvaise demande : `$document` opération non valide (demande non conforme) ou si le document obtenu échoue à la validation FHIR en raison du filtrage des références lorsque persist est défini sur true
+ 404 Introuvable : ressource de composition introuvable
Pour plus d'informations sur les spécifications de `$document` fonctionnement, consultez la documentation de [composition `$document` du FHIR R4](https://www.hl7.org/fhir/R4/composition-operation-document.html).
# Suppression permanente de ressources avec `$erase`
AWS HealthLake prend en charge l'`$erase`opération, permettant la suppression permanente d'une ressource spécifique et de ses versions historiques. Cette opération est particulièrement utile lorsque vous devez :
+ Supprimer définitivement des ressources individuelles
+ Supprimer des historiques de versions spécifiques
+ Gérez le cycle de vie des ressources individuelles
+ Respectez les exigences spécifiques en matière de suppression des données
## Usage
L'`$erase`opération peut être invoquée à deux niveaux :
**Niveau de l'instance de ressource**
```
POST [base]/[ResourceType]/[ID]/$erase?deleteAuditEvent=true
```
**Niveau spécifique à la version**
```
POST [base]/[ResourceType]/[ID]/_history/[VersionID]/$erase
```
## Parameters
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booléen | Non | false | Lorsque c'est vrai, supprime les événements d'audit associés |
## Exemples
**Exemple de requête**
```
POST [base]/Patient/example-patient/$erase
```
**Exemple de réponse**
```
{
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"jobStatus": "SUBMITTED"
}
```
## Statut de la tâche
Pour vérifier le statut d'une tâche d'effacement :
```
GET [base]/$erase/[jobId]
```
L'opération renvoie les informations relatives à l'état de la tâche :
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"status": "COMPLETED",
"submittedTime": "2025-10-30T16:39:24.160Z"
}
```
## Comportement
L'`$erase`opération :
1. Traite de manière asynchrone pour garantir l'intégrité des données
1. Maintient les transactions ACID
1. Assure le suivi de l'état des tâches
1. Supprime définitivement la ressource spécifiée et ses versions
1. Inclut un enregistrement d'audit complet des activités de suppression
1. Supporte la suppression sélective des événements d'audit
## Journalisation des audits
L'`$erase`opération est enregistrée sous forme DeleteResource d'ID utilisateur, d'horodatage et de détails sur les ressources.
## Limitations
+ `$erased`la ressource n'apparaîtra pas dans les résultats de recherche ou `_history` les requêtes.
+ Les ressources en cours d'effacement peuvent être temporairement inaccessibles pendant le traitement
+ La mesure du stockage est ajustée immédiatement lorsque les ressources sont définitivement supprimées
# Obtenir les données des patients avec `Patient/$everything`
L'`Patient/$everything`opération est utilisée pour interroger une `Patient` ressource FHIR, ainsi que toute autre ressource associée à celle-ci`Patient`. L'opération peut être utilisée pour permettre à un patient d'accéder à l'intégralité de son dossier ou pour qu'un fournisseur effectue un téléchargement massif de données relatives à un patient. HealthLakesoutiens `Patient/$everything` pour un patient spécifique`id`.
`Patient/$everything`est une opération d'API REST FHIR qui peut être invoquée comme indiqué dans les exemples ci-dessous.
------
#### [ GET request ]
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything
```
------
**Note**
Les ressources en réponse sont triées par type de ressource et par ressource`id`.
La réponse est toujours renseignée avec`Bundle.total`.
## Paramètres dans l’`Patient/$everything`
HealthLake prend en charge les paramètres de requête suivants
| Paramètre | Détails |
| --- | --- |
| démarrer | Obtenez toutes les `Patient` données après une date de début spécifiée. |
| end | Obtenez toutes les `Patient` données avant une date de fin spécifiée. |
| since | Mettez toutes les `Patient` données à jour après une date spécifiée. |
| \$1type | Obtenez `Patient` des données pour des types de ressources spécifiques. |
| \$1compter | Obtenez `Patient` des données et spécifiez le format de page. |
**Example - Obtenez toutes les données du patient après une date de début spécifiée**
`Patient/$everything`peut utiliser le `start` filtre pour interroger uniquement les données après une date précise.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?start=2024-03-15T00:00:00.000Z
```
**Example - Obtenez toutes les `Patient` données avant une date de fin spécifiée**
Patient \$1everything peut utiliser le `end` filtre pour n'interroger que des données antérieures à une date précise.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?end=2024-03-15T00:00:00.000Z
```
**Example - Mettre à jour toutes les `Patient` données après une date spécifiée**
`Patient/$everything`peut utiliser le `since` filtre pour n'interroger que les données mises à jour après une date précise.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?since=2024-03-15T00:00:00.000Z
```
**Example - Obtenir `Patient` des données pour des types de ressources spécifiques**
Le patient \$1everything peut utiliser le `_type` filtre pour spécifier des types de ressources spécifiques à inclure dans la réponse. Plusieurs types de ressources peuvent être spécifiés dans une liste séparée par des virgules.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_type=Observation,Condition
```
**Example - Obtenez `Patient` des données et spécifiez le format de page**
Le patient \$1everything peut utiliser le `_count` pour définir le format de page.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_count=15
```
## `Patient/$everything``start`et `end` attributs
HealthLake prend en charge les attributs de ressource suivants pour les paramètres de `end` requête `Patient/ $everything` `start` et.
| Ressource | Élément de ressource |
| --- | --- |
| Compte | Account.ServicePeriod.Start |
| AdverseEvent | AdverseEvent.date |
| AllergyIntolerance | AllergyIntolerance. Date d'enregistrement |
| Rendez-vous | Rendez-vous.Start |
| AppointmentResponse | AppointmentResponse.démarrer |
| AuditEvent | AuditEvent.period.start |
| Base | Basic. Créé |
| BodyStructure | AUCUNE DATE |
| CarePlan | CarePlan.period.start |
| CareTeam | CareTeam.period.start |
| ChargeItem | ChargeItem. occurrenceDateTime, ChargeItem .occurrencePeriod.start, .occurrenceTiming.Event ChargeItem |
| Demander | Réclamer. Période facturable. Début |
| ClaimResponse | ClaimResponse.créé |
| ClinicalImpression | ClinicalImpression.date |
| Communication | Communication. Envoyée |
| CommunicationRequest | CommunicationRequest. occurrenceDateTime, CommunicationRequest .occurrencePeriod.start |
| Montage | Date de composition |
| Condition | État. Date d'enregistrement |
| Consentement | Consent.Date/Heure |
| Couverture | Couverture.Period.Start |
| CoverageEligibilityRequest | CoverageEligibilityRequest.créé |
| CoverageEligibilityResponse | CoverageEligibilityResponse.créé |
| DetectedIssue | DetectedIssue.identifié |
| DeviceRequest | DeviceRequest. Rédigé le |
| DeviceUseStatement | DeviceUseStatement. Enregistré le |
| DiagnosticReport | DiagnosticReport.efficace |
| DocumentManifest | DocumentManifest.créé |
| DocumentReference | DocumentReference.context .period .start |
| Rencontre | Encounter.Period.Start |
| EnrollmentRequest | EnrollmentRequest.créé |
| EpisodeOfCare | EpisodeOfCare.period.start |
| ExplanationOfBenefit | ExplanationOfBenefit. Période facturable. Début |
| FamilyMemberHistory | AUCUNE DATE |
| Indicateur | Flag.Period.Start |
| Objectif | Objectif. Date d'état |
| Groupe | AUCUNE DATE |
| ImagingStudy | ImagingStudy.démarré |
| Immunisation | Vaccination enregistrée |
| ImmunizationEvaluation | ImmunizationEvaluation.date |
| ImmunizationRecommendation | ImmunizationRecommendation.date |
| Invoice | Date de facturation |
| List | Date de la liste |
| MeasureReport | MeasureReport.period.start |
| Multimédia | Publié dans les médias |
| MedicationAdministration | MedicationAdministration.efficace |
| MedicationDispense | MedicationDispense. Une fois préparé |
| MedicationRequest | MedicationRequest. Rédigé le |
| MedicationStatement | MedicationStatement. Date affirmée |
| MolecularSequence | AUCUNE DATE |
| NutritionOrder | NutritionOrder.Date/Heure |
| Observation | Observation. Efficace |
| Patient | AUCUNE DATE |
| Personne | AUCUNE DATE |
| Procédure | Procédure. Exécutée |
| Provenance | Provenance. Période survenue. Début, provenance. occurredDateTime |
| QuestionnaireResponse | QuestionnaireResponse.écrit |
| RelatedPerson | AUCUNE DATE |
| RequestGroup | RequestGroup. Rédigé le |
| ResearchSubject | ResearchSubject.période |
| RiskAssessment | RiskAssessment. occurrenceDateTime, RiskAssessment .occurrencePeriod.start |
| Planning | Calendrier. Horizon de planification |
| ServiceRequest | ServiceRequest. Rédigé le |
| Spécimen | Spécimen. Heure de réception |
| SupplyDelivery | SupplyDelivery. occurrenceDateTime, SupplyDelivery .occurrencePeriod.start, .occurrenceTiming.Event SupplyDelivery |
| SupplyRequest | SupplyRequest. Rédigé le |
| VisionPrescription | VisionPrescription. Date de rédaction |
# Récupération de ValueSet codes avec `$expand`
AWS HealthLake prend désormais en charge les `$expand` opérations ValueSets que vous avez ingérées en tant que client, ce qui vous permet de récupérer la liste complète des codes contenus dans ces ValueSet ressources. Cette opération est particulièrement utile lorsque vous devez :
+ Récupérez tous les codes possibles à des fins de validation
+ Afficher les options disponibles dans les interfaces utilisateur
+ Effectuez des recherches de code complètes dans un contexte terminologique spécifique
## Usage
L'`$expand`opération peut être invoquée sur les ValueSet ressources à l'aide des méthodes GET et POST :
**Opérations prises en charge**
```
GET/POST [base]/ValueSet/[id]/$expand
GET [base]/ValueSet/$expand?url=http://example.com
POST [base]/ValueSet/$expand
```
## Paramètres pris en charge
HealthLake prend en charge un sous-ensemble de paramètres FHIR `$expand` R4 :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| url | uri | Non | URL canonique du ValueSet à développer |
| id | id | Non | ValueSet identifiant de ressource à étendre (pour les opérations GET ou POST) |
| filter | chaîne | Non | Filtrer le résultat de l'extension du code |
| count | entier | Non | Nombre de codes à retourner |
| offset | entier | Non | Nombre de codes correspondants à ignorer avant de retourner. S'applique après le filtrage et uniquement aux codes correspondants, et non à l'intégralité du contenu non filtré de l'original ValueSet |
## Exemples
**Demande GET par identifiant**
```
GET [base]/ValueSet/example-valueset/$expand
```
**Requête GET par URL avec filtre**
```
GET [base]/ValueSet/$expand?url=http://example.com/ValueSet/my-valueset&filter=male&count=5
```
**Requête POST avec paramètres (par ID)**
```
POST [base]/ValueSet/example-valueset/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "count",
"valueInteger": 10
},
{
"name": "filter",
"valueString": "admin"
}
]
}
```
**Requête POST avec paramètres (par URL)**
```
POST [base]/ValueSet/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "http://hl7.org/fhir/ValueSet/administrative-gender"
},
{
"name": "count",
"valueInteger": 10
}
]
}
```
**Exemple de réponse**
L'opération renvoie une ValueSet ressource avec un `expansion` élément contenant les codes développés :
```
{
"resourceType": "ValueSet",
"id": "administrative-gender",
"status": "active",
"expansion": {
"identifier": "urn:uuid:12345678-1234-1234-1234-123456789abc",
"timestamp": "2024-01-15T10:30:00Z",
"total": 4,
"parameter": [
{
"name": "count",
"valueInteger": 10
}
],
"contains": [
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "male",
"display": "Male"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "female",
"display": "Female"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "other",
"display": "Other"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "unknown",
"display": "Unknown"
}
]
}
}
```
La réponse inclut :
+ expansion.total : nombre total de codes dans l'extension ValueSet
+ expansion.contains : tableau de codes étendus avec leur système, leur code et leurs valeurs d'affichage
+ expansion.parameter : paramètres utilisés dans la demande d'extension
Pour plus d'informations sur les spécifications de `$expand` fonctionnement, consultez la documentation du [FHIR R4 ValueSet `$expand`](https://build.fhir.org/valueset-operation-expand.html).
# Exporter HealthLake des données avec FHIR `$export`
Vous pouvez exporter des données en masse depuis votre magasin de HealthLake données à l'aide de l'opération FHIR \$1export. HealthLake prend en charge l'`$export`utilisation `POST` et les `GET` demandes de FHIR. Pour effectuer une demande d'exportation avec`POST`, vous devez disposer d'un utilisateur, d'un groupe ou d'un rôle IAM doté des autorisations requises, le spécifier dans le `$export` cadre de la demande et inclure les paramètres souhaités dans le corps de la demande.
**Note**
Toutes les demandes HealthLake d'exportation effectuées à l'aide de FHIR `$export` sont renvoyées au `ndjson` format et exportées vers un compartiment Amazon S3, où chaque objet Amazon S3 ne contient qu'un seul type de ressource FHIR.
Vous pouvez mettre en file d'attente les demandes d'exportation conformément aux quotas de service du AWS compte. Pour de plus amples informations, veuillez consulter [Quotas de service](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas).
HealthLake prend en charge les trois types suivants de demandes de terminaux d'exportation en masse.
**HealthLake `$export`types en vrac**
| Type d’exportation | Description | Syntaxe |
| --- | --- | --- |
| Système | Exportez toutes les données depuis le serveur HealthLake FHIR. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export` |
| Tous les patients | Exportez toutes les données relatives à tous les patients, y compris les types de ressources associés au type de ressource Patient. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` |
| Groupe de patients | Exportez toutes les données relatives à un groupe de patients spécifié par un identifiant de groupe. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` |
## Avant de commencer
Répondez aux exigences suivantes pour effectuer une demande d'exportation à l'aide de l'API REST FHIR pour HealthLake.
+ Vous devez avoir configuré un utilisateur, un groupe ou un rôle disposant des autorisations nécessaires pour effectuer la demande d'exportation. Pour en savoir plus, veuillez consulter la section [Autoriser une demande `$export`](#export-rest-auth).
+ Vous devez avoir créé un rôle de service qui accorde l' HealthLake accès au compartiment Amazon S3 vers lequel vous souhaitez que vos données soient exportées. Le rôle de service doit également être spécifié HealthLake comme principal de service. Pour plus d'informations sur la configuration des autorisations, consultez[Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
## Autoriser une demande `$export`
Pour effectuer une demande d'exportation réussie à l'aide de l'API REST FHIR, autorisez votre utilisateur, votre groupe ou votre rôle à l'aide d'IAM ou OAuth2 .0. Vous devez également avoir un rôle de service.
**Autoriser une demande à l'aide d'IAM**
Lorsque vous faites une `$export` demande, les actions IAM de l'utilisateur, du groupe ou du rôle doivent être incluses dans la politique. Pour de plus amples informations, veuillez consulter [Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
**Autoriser une demande à l'aide de SMART sur FHIR (2.0) OAuth**
Lorsque vous faites une `$export` demande sur un magasin de HealthLake données compatible SMART sur FHIR, les étendues appropriées doivent vous être attribuées. Pour de plus amples informations, veuillez consulter [SMART sur les champs de ressources FHIR pour HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest).
**Note**
Le FHIR `$export` avec `GET` demandes nécessite la même méthode d'authentification ou le même jeton porteur (dans le cas de SMART sur FHIR) pour demander l'exportation et la récupération de fichiers. Les fichiers exportés à l'aide de FHIR `$export` avec `GET` peuvent être téléchargés pendant 48 heures.
## Faire une `$export` demande
Cette section décrit les étapes obligatoires que vous devez suivre lorsque vous effectuez une demande d'exportation à l'aide de l'API REST FHIR.
Pour éviter des frais accidentels sur votre AWS compte, nous vous recommandons de tester vos demandes en effectuant une `POST` demande sans fournir de `$export` syntaxe.
Pour faire la demande, vous devez effectuer les opérations suivantes :
1. Spécifiez `$export` dans l'URL de `POST` demande un point de terminaison pris en charge.
1. Spécifiez les paramètres d'en-tête requis.
1. Spécifiez un corps de demande qui définit les paramètres requis.
### Étape 1 : Spécifiez `$export` dans l'URL de `POST` demande un point de [terminaison](reference-healthlake-endpoints-quotas.md#reference-healthlake-endpoints) pris en charge.
HealthLake prend en charge trois types de demandes d'exportation groupées pour les terminaux. Pour effectuer une demande d'exportation groupée, vous devez effectuer une demande `POST` basée sur l'un des trois points de terminaison pris en charge. Les exemples suivants montrent où spécifier `$export` dans l'URL de la demande.
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export`
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export`
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export`
Vous pouvez utiliser les paramètres de recherche pris en charge suivants dans la chaîne de `POST` requête.
#### Paramètres de recherche pris en charge
HealthLake prend en charge les modificateurs de recherche suivants dans les demandes d'exportation groupées.
Les exemples suivants incluent des caractères spéciaux qui doivent être codés avant de soumettre votre demande.
| Nom | Obligatoire ? | Description | Exemple |
| --- | --- | --- | --- |
| \$1outputFormat | Non | Format des fichiers de données en masse demandés à générer. Les valeurs acceptées sont application/fhir\$1ndjsonapplication/ndjson,ndjson. | |
| \$1type | Non | Chaîne de types de ressources FHIR séparés par des virgules que vous souhaitez inclure dans votre tâche d'exportation. Nous vous recommandons de l'inclure, \$1type car cela peut avoir une incidence financière lorsque toutes les ressources sont exportées. | &\$1type=MedicationStatement, Observation |
| \$1since | Non | Types de ressources modifiés le jour ou après l'horodatage. Si un type de ressource n'a pas d'heure de dernière mise à jour, il sera inclus dans votre réponse. | &\$1since=2024-05-09T00%3A00%3A00Z |
| \$1until | Non | Types de ressources modifiés le jour ou avant l'horodatage. Utilisé en combinaison avec \$1since pour définir une plage de temps spécifique pour l'exportation. Si un type de ressource n'a pas d'heure de dernière mise à jour, il sera exclu de votre réponse. | &\$1until=2024-12-31T23%3A59%3A59Z |
### Étape 2 : Spécifier les paramètres d'en-tête requis
Pour effectuer une demande d'exportation à l'aide de l'API REST FHIR, vous devez spécifier les paramètres d'en-tête suivants.
+ Type de contenu : `application/fhir+json`
+ Préférez : `respond-async`
Ensuite, vous devez spécifier les éléments requis dans le corps de la demande.
### Étape 3 : Spécifiez un corps de demande qui définit les paramètres requis.
La demande d'exportation nécessite également un corps au `JSON` format. Le corps peut inclure les paramètres suivants.
| Clé | Obligatoire ? | Description | Value |
| --- | --- | --- | --- |
| DataAccessRoleArn | Oui | L'ARN d'un rôle HealthLake de service. Le rôle de service utilisé doit être spécifié HealthLake comme principal de service. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| JobName | Non | Nom de la demande d'exportation. | your-export-job-name |
| S3Uri | Oui | Partie d'une OutputDataConfig clé. L'URI S3 du compartiment de destination dans lequel vos données exportées seront téléchargées. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Oui | Partie d'une OutputDataConfig clé. L'ARN de la AWS KMS clé utilisée pour sécuriser le compartiment Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example Corps d'une demande d'exportation effectuée à l'aide de l'API REST FHIR**
Pour effectuer une demande d'exportation à l'aide de l'API REST FHIR, vous devez spécifier un corps, comme indiqué ci-dessous.
```
{
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
"JobName": "your-export-job",
"OutputDataConfig": {
"S3Configuration": {
"S3Uri": "s3://amzn-s3-demo-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region-of-bucket:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
}
}
```
Lorsque votre demande sera acceptée, vous recevrez la réponse suivante.
*En-tête de réponse*
```
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
*Organisme de réponse*
```
{
"datastoreId": "your-data-store-id",
"jobStatus": "SUBMITTED",
"jobId": "your-export-request-job-id"
}
```
## Gestion de votre demande d'exportation
Après avoir effectué une demande d'exportation réussie, vous pouvez la gérer en `$export` décrivant le statut d'une demande d'exportation en cours et `$export` en annulant une demande d'exportation en cours.
Lorsque vous annulez une demande d'exportation à l'aide de l'API REST, vous n'êtes facturée que pour la partie des données exportées jusqu'au moment où vous avez soumis la demande d'annulation.
Les rubriques suivantes décrivent comment vous pouvez obtenir le statut d'une demande d'exportation en cours ou l'annuler.
### Annulation d'une demande d'exportation
Pour annuler une demande d'exportation, faites une `DELETE` demande et indiquez l'ID de tâche dans l'URL de la demande.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
Lorsque votre demande est acceptée, vous recevez ce qui suit.
```
{
"exportJobProperties": {
"jobId": "your-original-export-request-job-id",
"jobStatus": "CANCEL_SUBMITTED",
"datastoreId": "your-data-store-id"
}
}
```
Lorsque votre demande n'aboutit pas, vous recevez ce qui suit.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-supported",
"diagnostics": "Interaction not supported."
}
]
}
```
### Décrire une demande d'exportation
Pour connaître le statut d'une demande d'exportation, faites une `GET` demande en utilisant `export` et votre`export-request-job-id`.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-id
```
La réponse JSON contiendra un `ExportJobProperties` objet. Il peut contenir les paires clé:valeur suivantes.
| Nom | Obligatoire ? | Description | Value |
| --- | --- | --- | --- |
| DataAccessRoleArn | Non | L'ARN d'un rôle HealthLake de service. Le rôle de service utilisé doit être spécifié HealthLake comme principal de service. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| SubmitTime | Non | Date à laquelle une tâche d'exportation a été soumise. | Apr 21, 2023 5:58:02 |
| EndTime | Non | Heure à laquelle une tâche d'exportation a été terminée. | Apr 21, 2023 6:00:08 PM |
| JobName | Non | Nom de la demande d'exportation. | your-export-job-name |
| JobStatus | Non | | Les valeurs valides sont :SUBMITTED | IN_PROGRESS | COMPLETED_WITH_ERRORS | COMPLETED |
FAILED
|
| S3Uri | Oui | Partie d'un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objet. L'URI Amazon S3 du compartiment de destination dans lequel vos données exportées seront téléchargées. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Oui | Partie d'un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objet. L'ARN de la AWS KMS clé utilisée pour sécuriser le compartiment Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example : corps d'une demande d'exportation de description effectuée à l'aide de l'API REST FHIR**
En cas de succès, vous obtiendrez la réponse JSON suivante.
```
{
"exportJobProperties": {
"jobId": "your-export-request-id",
"JobName": "your-export-job",
"jobStatus": "SUBMITTED",
"submitTime": "Apr 21, 2023 5:58:02 PM",
"endTime": "Apr 21, 2023 6:00:08 PM",
"datastoreId": "your-data-store-id",
"outputDataConfig": {
"s3Configuration": {
"S3Uri": "s3://amzn-s3-demo-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region-of-bucket:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab""
}
},
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
}
}
```
# `$inquire`Opération FHIR pour HealthLake
L'`$inquire`opération vous permet de vérifier le statut d'une demande d'autorisation préalable soumise précédemment. Cette opération met en œuvre le [guide de mise en œuvre du Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), fournissant un flux de travail standardisé basé sur le FHIR pour récupérer la décision d'autorisation actuelle.
## Comment ça marche
+ **Soumettre une demande** : vous envoyez un bundle FHIR contenant la réclamation que vous souhaitez vérifier et les informations justificatives
+ **Rechercher** : HealthLake recherche le correspondant ClaimResponse dans votre magasin de données
+ **Récupérer** : le statut d'autorisation le plus récent est récupéré
+ **Répondre** : vous recevez une réponse immédiate avec le statut d'autorisation actuel (en file d'attente, approuvé, refusé, etc.)
**Note**
`$inquire`est une **opération en lecture seule** qui permet de récupérer le statut d'autorisation existant. Il ne modifie ni ne met à jour aucune ressource de votre banque de données.
## Point de terminaison d’API
```
POST /datastore/{datastoreId}/r4/Claim/$inquire
Content-Type: application/fhir+json
```
## Structure de la demande
### Exigences relatives au bundle
Votre demande doit être une ressource FHIR Bundle contenant :
+ **Bundle.type** : Doit être `"collection"`
+ **Bundle.entry** : Doit contenir exactement **une** ressource Claim avec :
+ `use = "preauthorization"`
+ `status = "active"`
+ **Ressources référencées** : Toutes les ressources référencées par la réclamation doivent être incluses dans le bundle
**Requête par exemple**
Les ressources de votre bundle d'entrée servent de modèle de recherche. HealthLake utilise les informations fournies pour localiser le correspondant ClaimResponse.
### Ressources requises
| Ressource | Cardinalité | Profil | Description |
| --- | --- | --- | --- |
| Réclamation | 1 | Demande de réclamation PAS | L'autorisation préalable que vous demandez |
| Patient | 1 | Patient bénéficiaire du PAS | Informations démographiques sur les patients |
| Organisation (assureur) | 1 | Organisation d'assurance PAS | Compagnie d'assurance |
| Organisation (fournisseur) | 1 | Organisation demandeuse du PAS | Prestataire de santé qui a soumis la demande |
### Critères de recherche importants
HealthLake recherche l' ClaimResponse utilisation de :
+ **Référence du patient** tirée de la réclamation
+ **Référence de l'assureur** tirée de la réclamation
+ **Référence du fournisseur** figurant dans la réclamation
+ **Date de création** à partir de la réclamation (en tant que filtre temporel)
**Demandes spécifiques au patient uniquement**
Toutes les demandes doivent être liées à un patient en particulier. Les requêtes à l'échelle du système sans identification du patient ne sont pas autorisées.
## Exemple de demande
```
POST /datastore/example-datastore/r4/Claim/$inquire
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType": "Bundle",
"id": "PASClaimInquiryBundleExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-inquiry-request-bundle"]
},
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269368"
},
"type": "collection",
"timestamp": "2005-05-02T14:30:00+05:00",
"entry": [
{
"fullUrl": "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource": {
"resourceType": "Claim",
"id": "MedicalServicesAuthorizationExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:01:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"provider": {
"reference": "Organization/UMOExample"
}
}
},
{
"fullUrl": "http://example.org/fhir/Patient/SubscriberExample",
"resource": {
"resourceType": "Patient",
"id": "SubscriberExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary"]
},
"name": [{
"family": "SMITH",
"given": ["JOE"]
}],
"gender": "male"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/UMOExample",
"resource": {
"resourceType": "Organization",
"id": "UMOExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"name": "Provider Organization"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/InsurerExample",
"resource": {
"resourceType": "Organization",
"id": "InsurerExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"name": "Insurance Company"
}
}
]
}
```
## Format de la réponse
### Réponse positive (200 OK)
Vous recevrez un ensemble de réponses aux demandes de renseignements PAS contenant :
+ **ClaimResponse**avec le statut d'autorisation actuel ; multiple **ClaimResponse**s'il correspond aux critères de recherche
+ Toutes les ressources originales de votre demande (renvoyées)
+ Horodatage du moment où la réponse a été assemblée
**ClaimResponse Résultats possibles**
| Outcome | Description |
| --- | --- |
| queued | La demande d'autorisation est toujours en attente d'examen |
| complete | La décision d'autorisation a été prise (vérifier si elle est disposition approuvée/refusée) |
| error | Une erreur s'est produite lors du traitement |
| partial | Autorisation partielle accordée |
```
{
"resourceType": "Bundle",
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269367"
},
"type": "collection",
"timestamp": "2005-05-02T14:30:15+05:00",
"entry": [
{
"fullUrl": "http://example.org/fhir/ClaimResponse/InquiryResponseExample",
"resource": {
"resourceType": "ClaimResponse",
"id": "InquiryResponseExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:05:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"request": {
"reference": "Claim/MedicalServicesAuthorizationExample"
},
"outcome": "complete",
"disposition": "Approved",
"preAuthRef": "AUTH12345"
}
},
{
"fullUrl": "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource": {
"resourceType": "Claim",
"id": "MedicalServicesAuthorizationExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:01:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"provider": {
"reference": "Organization/UMOExample"
}
}
},
{
"fullUrl": "http://example.org/fhir/Patient/SubscriberExample",
"resource": {
"resourceType": "Patient",
"id": "SubscriberExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary"]
},
"name": [{
"family": "SMITH",
"given": ["JOE"]
}],
"gender": "male"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/UMOExample",
"resource": {
"resourceType": "Organization",
"id": "UMOExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"name": "Provider Organization"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/InsurerExample",
"resource": {
"resourceType": "Organization",
"id": "InsurerExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"name": "Insurance Company"
}
}
]
}
```
## Réponses d'erreur
### 400 Requête erronée
Renvoyé lorsque le format de demande n'est pas valide ou que la validation échoue.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "required",
"diagnostics": "Reference 'Patient/SubscriberExample' at path 'patient' for 'CLAIM' resource not found(at Bundle.entry[0].resource)"
}
]
}
```
### 401 Accès non autorisé
Renvoyé lorsque les informations d'authentification sont manquantes ou non valides.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "Invalid authorization header"
}
]
}
```
### 403 Forbidden
Renvoyé lorsque l'utilisateur authentifié n'est pas autorisé à accéder à la ressource demandée.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Insufficient SMART scope permissions."
}
]
}
```
### 400 Quand aucun n'est trouvé
Renvoyé lorsqu'aucune correspondance n' ClaimResponse est trouvée pour la demande.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "not-found",
"diagnostics": "Resource not found. No ClaimResponse found from the input Claim that matches the specified Claim properties patient, insurer, provider, and created(at Bundle.entry[0].resource)"
}]
}
```
### 415 Type de média non pris en charge
Renvoyé lorsque l'en-tête Content-Type n'est pas application/fhir\$1json.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "value",
"diagnostics": "Incorrect MIME-type. Update request Content-Type header."
}]
}
```
### 429 Trop de demandes
Renvoyé lorsque les limites de débit sont dépassées.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "throttled",
"diagnostics": "Rate limit exceeded. Please retry after some time."
}]
}
```
## Règles de validation
HealthLake effectue une validation complète de votre demande :
### Validation du bundle
+ Doit être conforme au profil du bundle PAS Inquiry Request
+ `Bundle.type`doit être `"collection"`
+ Doit contenir exactement une ressource de réclamation
+ Toutes les ressources référencées doivent être incluses dans le bundle
### Validation des réclamations
+ Doit être conforme au profil PAS Claim Inquiry
+ `Claim.use`doit être `"preauthorization"`
+ `Claim.status`doit être `"active"`
+ Champs obligatoires : `patient``insurer`,`provider`, `created`
### Validation des ressources
+ Toutes les ressources doivent être conformes à leurs profils d'enquête PAS respectifs
+ Les ressources de soutien requises doivent être présentes (patient, organisme assureur, organisme fournisseur)
+ Les références croisées doivent être valides et résolvables dans le bundle
## Spécifications de performance
| Métrique | Spécification de |
| --- | --- |
| Limite du nombre de ressources | 500 ressources par bundle |
| Limite de taille du bundle | 5 Mo maximum |
## Autorisations requises
Pour utiliser l'`$inquire`opération, assurez-vous que votre rôle IAM possède les éléments suivants :
+ `healthlake:InquirePreAuthClaim`- Pour appeler l'opération
**SMART sur les oscilloscopes FHIR**
**Étendue minimale requise :**
+ **SMART version 1** : `user/ClaimResponse.read`
+ **SMART v2** : `user/ClaimResponse.s`
## Remarques de mise en œuvre importantes
### Comportement de recherche
Lorsque vous soumettez une demande, recherchez l' HealthLake utilisateur à l' ClaimResponse aide de :
+ **Référence du patient** tirée de la demande d'entrée
+ **Référence de l'assureur** tirée de la demande d'entrée
+ **Référence du fournisseur** à partir de la demande d'entrée
+ **Date de création** à partir de la demande d'entrée (en tant que filtre temporel)
**Correspondances multiples** : si plusieurs ClaimResponses correspondent à vos critères de recherche, HealthLake renvoie tous les résultats correspondants. Vous devez utiliser l'`ClaimResponse.created`horodatage le plus récent pour identifier le dernier statut.
### Demandes mises à jour
Si vous avez soumis plusieurs mises à jour pour la même autorisation préalable (par exemple, Claim v1.1, v1.2, v1.3), l'`$inquire`opération récupérera la version ClaimResponse associée à la **version la plus récente** en fonction des critères de recherche fournis.
### Fonctionnement en lecture seule
L'`$inquire`opération :
+ **Récupère le** statut d'autorisation existant
+ **Renvoie** le plus récent ClaimResponse
+ **Ne modifie ni ne** met à jour aucune ressource
+ **Ne crée pas** de nouvelles ressources
+ **Ne déclenche pas** de nouveau traitement d'autorisation
## Exemple de flux de travail
**Flux de travail typique de demande d'autorisation préalable**
```
1. Provider submits PA request
POST /Claim/$submit
→ Returns ClaimResponse with outcome="queued"
2. Payer reviews request (asynchronous)
→ Updates ClaimResponse status internally
3. Provider checks status
POST /Claim/$inquire
→ Returns ClaimResponse with outcome="queued" (still pending)
4. Provider checks status again later
POST /Claim/$inquire
→ Returns ClaimResponse with outcome="complete", disposition="Approved"
```
## Opérations liées
+ `Claim/$submit`- Soumettre une nouvelle demande d'autorisation préalable ou mettre à jour une demande existante
+ `Patient/$everything`- Récupérez les données complètes du patient pour le contexte de l'autorisation préalable
# Récupération des détails du concept avec `$lookup`
AWS HealthLake prend désormais en charge les `$lookup` opérations relatives aux CodeSystem ressources, ce qui vous permet de récupérer les détails d'un concept spécifique dans un système de code en fournissant des informations d'identification telles que son code. Cette opération est particulièrement utile lorsque vous devez :
+ Récupérez des informations détaillées sur des codes médicaux spécifiques
+ Valider la signification et les propriétés du code
+ Définitions et relations des concepts d'accès
+ Support à la prise de décisions cliniques grâce à des données terminologiques précises
## Usage
L'`$lookup`opération peut être invoquée sur les CodeSystem ressources à l'aide des méthodes GET et POST :
**Opérations prises en charge**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=73211009&version=20230901
POST [base]/CodeSystem/$lookup
```
## Paramètres pris en charge
HealthLake prend en charge un sous-ensemble de paramètres FHIR `$lookup` R4 :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| code | code | Oui | Le code conceptuel que vous recherchez (par exemple, « 71620000 » dans SNOMED CT) |
| system | uri | Oui | L'URL canonique du système de code (par exemple, "[http://snomed.info/sct](http://snomed.info/sct) «) |
| version | chaîne | Non | Version spécifique du système de code |
## Exemples
**Demande GET**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=71620000&version=2023-09
```
**Demande POST**
```
POST [base]/CodeSystem/$lookup
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "system",
"valueUri": "http://snomed.info/sct"
},
{
"name": "code",
"valueCode": "71620000"
},
{
"name": "version",
"valueString": "2023-09"
}
]
}
```
**Exemple de réponse**
L'opération renvoie une ressource Parameters contenant les détails du concept :
```
{
"resourceType": "Parameters",
"parameter": [{
"name": "name",
"valueString": "SNOMED CT Fractures"
},
{
"name": "version",
"valueString": "2023-09"
},
{
"name": "display",
"valueString": "Fracture of femur"
},
{
"name": "property",
"part": [{
"name": "code",
"valueCode": "child"
},
{
"name": "value",
"valueCode": "263225007"
},
{
"name": "description",
"valueString": "Fracture of neck of femur"
}
]
},
{
"name": "property",
"part": [{
"name": "code",
"valueCode": "child"
},
{
"name": "value",
"valueCode": "263227004"
},
{
"name": "description",
"valueString": "Fracture of shaft of femur"
}
]
}
]
}
```
## Paramètres de réponse
La réponse inclut les paramètres suivants lorsqu'ils sont disponibles :
| Paramètre | Type | Description |
| --- | --- | --- |
| name | chaîne | Nom du système de code |
| version | chaîne | Version du système de code |
| display | chaîne | Afficher le nom du concept |
| designation | BackboneElement | Des représentations supplémentaires pour ce concept. |
| property | BackboneElement | Propriétés supplémentaires du concept (définition, relations, etc.) |
## Comportement
L'`$lookup`opération :
1. Valide les paramètres requis (`code`et`system`)
1. Recherche le concept dans le système de code spécifié stocké dans la banque de données
1. Renvoie des informations détaillées sur le concept, notamment le nom d'affichage, les désignations et les propriétés.
1. Prend en charge les recherches spécifiques à la version lorsque le paramètre est fourni `version`
1. Fonctionne uniquement sur les systèmes de code explicitement stockés dans la HealthLake banque de données
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ 400 Mauvaise demande : `$lookup` opération non valide (demande non conforme ou paramètres requis manquants)
+ 404 Introuvable : système de code introuvable ou code introuvable dans le système de code spécifié
## Mises en garde
Dans cette version, les éléments suivants ne sont pas pris en charge :
+ `$lookup`opération en appelant des serveurs terminologiques externes
+ `$lookup`opération sur CodeSystems gérée par HealthLake mais non explicitement stockée dans la banque de données
Pour plus d'informations sur les spécifications de `$lookup` fonctionnement, consultez la documentation du [FHIR R4 CodeSystem `$lookup`](https://www.hl7.org/fhir/R4/codesystem-operation-lookup.html).
# `$member-add`opération pour HealthLake
L'`$member-add`opération FHIR ajoute un membre (patient) à une ressource de groupe, en particulier à une liste d'attribution de membres. Cette opération fait partie du guide de mise en œuvre de l'attribution des DaVinci membres et soutient le processus de rapprochement pour la gestion des attributions des membres.
## Opération Endpoint
```
POST [base]/datastore/{datastoreId}/r4/Group/{groupId}/$member-add
Content-Type: application/json
```
## Parameters
L'opération accepte une ressource de paramètres FHIR avec les combinaisons de paramètres suivantes :
### Options de paramètres
Vous pouvez utiliser l'une des combinaisons de paramètres suivantes :
Option 1 : ID de membre \$1 NPI du fournisseur
`memberId` \$1 `providerNpi`
`memberId` \$1 `providerNpi` \$1 `attributionPeriod`
Option 2 : référence du patient et référence du fournisseur
`patientReference` \$1 `providerReference`
`patientReference` \$1 `providerReference` \$1 `attributionPeriod`
### Détails des paramètres
ID de membre (facultatif)
Identifiant du membre à ajouter au groupe.
Type : Identifiant
Système : système d'identification du patient
```
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
}
```
ProviderNPI (facultatif)
L'identifiant national du fournisseur (NPI) du fournisseur attribué.
Type : Identifiant
Système : http://terminology.hl7. org/CodeSystem/NPI
```
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
}
```
Référence du patient (facultatif)
Référence directe à la ressource patient à ajouter.
Type : Référence
```
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
}
```
Référence du fournisseur (facultatif)
Référence directe à la ressource du fournisseur.
Type : Référence
```
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
}
```
Période d'attribution (facultatif)
Période pendant laquelle le patient est attribué au prestataire.
Type : Période
```
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
```
## Exemples de demandes
### Utilisation de l'ID de membre et du NPI du fournisseur
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
},
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
},
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
]
}
```
### Utilisation des références des patients et des prestataires
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
},
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
]
}
```
## Format de la réponse
### Réponse d'ajout réussie
```
HTTP Status: 200 OK
Content-Type: application/fhir+json
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "success",
"code": "informational",
"details": {
"text": "Member Patient/patient-new successfully added to the Member Attribution List."
}
}
]
}
```
### Réponses d’erreur
Syntaxe de demande non valide
État HTTP : 400 demandes incorrectes
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"details": {
"text": "Invalid parameter combination provided"
}
}
]
}
```
Ressource introuvable
État HTTP : 404 introuvable
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Resource not found."
}
}
]
}
```
Conflit de version
État HTTP : 409 Conflit
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "conflict",
"details": {
"text": "Resource version conflict detected"
}
}
]
}
```
État d'attribution non valide
État HTTP : 422 Entité non traitable
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "business-rule",
"details": {
"text": "Cannot add member to Attribution List with status 'final'. Status must be 'draft' or 'open'."
}
}
]
}
```
## Règles commerciales
Validation du statut d'attribution
L'opération ne peut être effectuée que lorsque le statut d'attribution du groupe est :
+ `draft`
+ `open`
Les opérations ne sont pas autorisées lorsque le statut est défini`final`.
Prévention des doublons de membres
Le système empêche l'ajout de membres dupliqués sur la base de la combinaison unique de :
+ Identifiant du membre
+ Identifiant du payeur
+ Identifiant de couverture
Validation des périodes de couverture
Lorsqu'une offre `attributionPeriod` est fournie, elle doit se situer dans les limites de la période de couverture du membre. Le système va :
+ Recherchez la ressource de couverture du membre
+ Utiliser la couverture la plus récente (versionID le plus élevé) s'il en existe plusieurs
+ Validez que la période d'attribution ne dépasse pas la période de couverture
Validation des références
Lorsque l'identifiant et la référence sont fournis pour la même ressource (patient ou fournisseur), le système valide qu'ils correspondent à la même ressource.
Lorsque les champs ID et reference.identifier sont fournis pour la même ressource (patient ou fournisseur), une erreur est générée.
## Authentification et autorisation
L'opération nécessite une autorisation SMART on FHIR pour :
+ Permissions de lecture : pour valider les ressources du patient, du fournisseur et du groupe
+ Autorisations de recherche : pour rechercher des ressources par identifiant
+ Mettre à jour les autorisations : pour modifier la ressource du groupe
## Comportement opérationnel
Mise à jour des ressources
+ Met à jour l'ID de version de la ressource du groupe
+ Crée une entrée d'historique avec l'état de la ressource d'origine avant l'opération
+ Ajoute des informations sur les membres au tableau Group.member avec :
+ Référence du patient dans entity.reference
+ Période d'attribution dans la période
+ Couverture et informations sur les fournisseurs dans les domaines d'extension
Étapes de validation
+ Validation des paramètres : garantit la validité des combinaisons de paramètres
+ Existence des ressources : valide l'existence des ressources du patient, du fournisseur et du groupe
+ État d'attribution : confirme que le statut du groupe autorise les modifications
+ Duplicate Check - Empêche l'ajout de membres existants
+ Validation de la couverture : garantit que la période d'attribution se situe dans les limites de couverture
## Limitations
+ Toutes les ressources référencées doivent exister dans la même banque de données
+ L'opération ne fonctionne qu'avec les ressources du groupe de listes d'attribution de membres
+ Les périodes d'attribution doivent se situer dans les limites de couverture
+ Impossible de modifier les groupes ayant le statut « final »
# `$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
# `$member-remove`opération pour HealthLake
L'`$member-remove`opération vous permet de supprimer des membres d'une liste d'attribution de membres FHIR (ressource de groupe) dans AWS HealthLake. Cette opération fait partie du guide de mise en œuvre de l'attribution des DaVinci membres et soutient le processus de rapprochement pour la gestion des attributions des membres.
## Conditions préalables
+ AWS HealthLake Banque de données FHIR
+ Autorisations IAM appropriées pour les opérations HealthLake
+ Liste d'attribution des membres (ressource du groupe) en version provisoire ou ouverte
## Détails de l'opération
Endpoint
`POST /Group/{id}/$member-remove`
Type de contenu
`application/fhir+json`
## Parameters
L'opération accepte une ressource de paramètres FHIR avec les paramètres facultatifs suivants :
| Paramètre | Cardinalité | Type | Description |
| --- | --- | --- | --- |
| memberId | 0,1 | Identifiant | Identifiant professionnel du membre à supprimer |
| Fournisseur NPI | 0,1 | Identifiant | NPI du fournisseur attribué |
| Référence du patient | 0,1 | Référence | Référence directe à la ressource destinée aux patients |
| Référence du fournisseur | 0,1 | Référence | Référence directe à la ressource du fournisseur (praticien ou organisation) PractitionerRole |
| Référence de couverture | 0,1 | Référence | Référence à la ressource Coverage |
### Combinaisons de paramètres prises en charge
Les combinaisons de paramètres suivantes sont prises en charge :
+ `memberId`uniquement - Supprime toutes les attributions pour le membre spécifié
+ `memberId`\$1 `providerNpi` - Supprime les attributions pour la combinaison membre-fournisseur spécifique
+ `patientReference`uniquement - Supprime toutes les attributions pour le patient spécifié
+ `patientReference`\$1 `providerReference` - Supprime les attributions pour la combinaison patient-fournisseur spécifique
+ `patientReference`\$1 `providerReference` \$1 `coverageReference` - Supprime l'attribution spécifique en fonction du patient, du fournisseur et de la couverture
## Exemple de requête
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/12345"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/67890"
}
}
]
}
```
## Réponse
### Réponse réussie
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": true
},
{
"name": "effectiveDate",
"valueDate": "2024-06-30"
},
{
"name": "status",
"valueCode": "inactive"
},
{
"name": "message",
"valueString": "Member successfully removed from attribution list"
}
]
}
```
## Comportement
Exigences relatives au statut
L'opération ne fonctionne que sur les listes d'attribution avec statut `draft` ou `open`
Les listes avec un `final` statut rejetteront l'opération avec une erreur 422
Processus de suppression d'un membre
*Brouillons de listes de statut* : les membres sont marqués comme inactifs (`inactive: true`) et leur `changeType` extension est mise à jour pour `changed`
*Listes de statut ouvertes* : comportement similaire à celui du statut des brouillons
*Listes de statut final* : l'opération est rejetée
Validation
Les références sont validées pour garantir leur existence dans la HealthLake banque de données
Si l'identifiant et la référence sont fournis pour le même type de ressource, ils doivent correspondre à la même ressource
Les combinaisons de paramètres sont validées selon les modèles pris en charge
## Gestion des erreurs
### Réponses aux erreurs courantes
Ressource introuvable (404)
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Patient with identifier 'http://example.org/fhir/identifiers|99999' not found in system"
},
"diagnostics": "Cannot remove member from attribution list. Verify patient identifier and try again.",
"expression": ["memberId"]
}
]
}
```
État final de la liste d'attribution (422)
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "business-rule",
"details": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-atr/CodeSystem/atr-error-codes",
"code": "list-final",
"display": "Attribution list is final and cannot be modified"
}
]
},
"diagnostics": "Cannot modify attribution list with status 'final'. List modifications are not permitted after finalization.",
"expression": ["Group.status"]
}
]
}
```
Opération non valide (400)
Renvoyé lorsque les combinaisons de paramètres ne sont pas valides ou sont mal formées.
Plusieurs résultats trouvés (412)
Renvoyé lorsque les paramètres fournis correspondent à plusieurs membres de la liste d'attribution.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Multiple members found matching the criteria"
}
]
}
```
## Bonnes pratiques
+ *Utiliser des paramètres spécifiques* : Dans la mesure du possible, utilisez la combinaison de paramètres la plus spécifique pour éviter les suppressions involontaires
+ État de *la liste de vérification : vérifiez l'état* de la liste d'attribution avant de tenter de le supprimer
+ *Gérez les erreurs avec élégance* : implémentez une gestion des erreurs appropriée pour toutes les conditions d'erreur possibles
+ *Valider les références* : assurez-vous que toutes les ressources référencées existent avant de faire la demande
# Supprimer les ressources du compartiment réservé aux patients grâce à `$purge`
AWS HealthLake soutient l'`$purge`opération, permettant la suppression permanente de toutes les ressources présentes dans le compartiment du patient. Cette opération est particulièrement utile lorsque vous devez :
+ Supprimer toutes les données associées à un patient
+ Respectez les demandes de suppression des données des patients
+ Gérer le cycle de vie des données des patients
+ Effectuez un nettoyage complet des dossiers des patients
## Usage
L'`$purge`opération peut être invoquée sur les ressources du patient :
```
POST [base]/Patient/[ID]/$purge?deleteAuditEvent=true
```
## Parameters
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booléen | Non | false | Lorsque c'est vrai, supprime les événements d'audit associés |
| \$1since | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite de début pour rechercher les ressources en fonction de leur heure de dernière modification. Ne peut pas être utilisé avec le début ou la fin |
| start | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite pour rechercher les ressources en fonction de leur heure de dernière modification. Peut être utilisé avec extrémité |
| end | chaîne | Non | Heure de soumission des offres d'emploi | Une fois saisi, sélectionne l'heure limite de fin pour rechercher les ressources en fonction de leur heure de dernière modification |
## Exemples
**Exemple de requête**
```
POST [base]/Patient/example-patient/$purge?deleteAuditEvent=true
```
**Exemple de réponse**
```
{
"resourceType": "OperationOutcome",
"id": "purge-job",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Purge job started successfully. Job ID: 12345678-1234-1234-1234-123456789012"
}
]
}
```
## Statut de la tâche
Pour vérifier l'état d'une tâche de purge :
```
GET [base]/$purge/[jobId]
```
L'opération renvoie les informations relatives à l'état de la tâche :
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "3dd1c7a5b6c0ef8c110f566eb87e2ef9",
"status": "COMPLETED",
"submittedTime": "2025-10-31T18:43:21.822Z"
}
```
## Comportement
L'`$purge`opération :
1. Processus asynchrones pour gérer plusieurs ressources
1. Maintient les transactions ACID pour garantir l'intégrité des données
1. Fournit un suivi de l'état des tâches avec le nombre de ressources supprimées
1. Supprime définitivement toutes les ressources du compartiment du patient
1. Inclut un enregistrement d'audit complet des activités de suppression
1. Supporte la suppression sélective des événements d'audit
## Journalisation des audits
L'`$purge`opération est enregistrée sous les noms Start FHIRBulk DeleteJob et Describe FHIRBulk DeleteJob avec des informations détaillées sur l'opération.
## Limitations
+ Les ressources purgées n'apparaîtront pas dans les réponses de recherche
+ Les ressources en cours de purge peuvent être temporairement inaccessibles pendant le traitement
+ Toutes les ressources du compartiment patient sont définitivement supprimées
# `$questionnaire-package`Opération FHIR pour HealthLake
L'`$questionnaire-package`opération récupère un ensemble complet contenant un questionnaire FHIR et toutes ses dépendances nécessaires au rendu et au traitement du questionnaire. Cette opération met en œuvre le [guide de mise en œuvre des modèles et règles de documentation Da Vinci (DTR)](https://hl7.org/fhir/us/davinci-dtr/OperationDefinition-questionnaire-package.html), permettant le rendu dynamique des formulaires pour les exigences en matière de documentation dans les flux de travail du secteur de la santé.
## Comment ça marche
+ **Demande** : vous envoyez des paramètres identifiant le ou les questionnaires nécessaires, ainsi que la couverture et le contexte de la commande
+ **Récupérer** : HealthLake rassemble le questionnaire et toutes les dépendances (ValueSetsbibliothèques CQL, etc.)
+ **Package** : Toutes les ressources sont regroupées dans un format standardisé
+ **Répondre** : vous recevez un package complet prêt pour le rendu et la collecte de données
**Cas d'utilisation**
+ **Documentation d'autorisation préalable** : Collectez les informations cliniques requises pour les demandes d'autorisation préalable
+ **Exigences de couverture** : Rassemblez la documentation nécessaire pour satisfaire aux exigences de couverture du payeur
+ **Clinical Data Exchange** : structurez les données cliniques pour les soumettre aux payeurs
+ **Formulaires dynamiques** : créez des questionnaires avec des données préremplies sur les patients et une logique conditionnelle
## Point de terminaison d’API
```
POST /datastore/{datastoreId}/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
```
## Paramètres de demande
### Paramètres d’entrée
Le corps de la demande doit contenir une ressource de paramètres FHIR avec les paramètres suivants :
| Paramètre | Type | Cardinalité | Description |
| --- | --- | --- | --- |
| coverage | Couverture | 1.. \$1 (Obligatoire) | Ressource (s) de couverture pour établir le membre et couverture pour la documentation |
| questionnaire | canonial | 0.. \$1 | URL (s) canoniques pour un ou plusieurs questionnaires spécifiques à renvoyer (peut inclure la version) |
| order | Ressource | 0.. \$1 | Commandez des ressources (DeviceRequest, ServiceRequest, MedicationRequest, Encounter, Appointment) pour établir le contexte |
| changedSince | dateTime | 0,1 | Le cas échéant, ne renvoie que les ressources modifiées après cet horodatage |
### Règles de validation des paramètres
**Au moins UN des éléments suivants doit être fourni** (en plus de ce qui est obligatoire`coverage`) :
+ Un ou plusieurs `questionnaire` canoniques URLs
+ Une ou plusieurs `order` ressources
**Combinaisons de demandes valides :**
+ `coverage` \$1 `questionnaire`
+ `coverage` \$1 `order`
+ `coverage` \$1 `questionnaire` \$1 `order`
## Exemple de demande
```
POST /datastore/example-datastore/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"id": "example-coverage",
"status": "active",
"beneficiary": {
"reference": "Patient/example-patient"
},
"payor": [{
"reference": "Organization/example-payer"
}],
"class": [{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "group"
}]
},
"value": "12345"
}]
}
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/home-oxygen-therapy|2.0"
},
{
"name": "order",
"resource": {
"resourceType": "ServiceRequest",
"id": "example-service-request",
"status": "active",
"intent": "order",
"code": {
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "94660",
"display": "Continuous positive airway pressure ventilation (CPAP)"
}]
},
"subject": {
"reference": "Patient/example-patient"
}
}
},
{
"name": "changedSince",
"valueDateTime": "2024-01-01T00:00:00Z"
}
]
}
```
## Format de la réponse
### Réponse positive (200 OK)
L'opération renvoie une ressource de paramètres FHIR contenant un ou plusieurs **Package Bundles**. Chaque Package Bundle inclut :
| Type d'entrée | Cardinalité | Description |
| --- | --- | --- |
| Questionnaire | 1 | Le questionnaire à rendre |
| QuestionnaireResponse | 0,1 | Réponse préremplie ou partiellement complétée (le cas échéant) |
| d'outils | 0.. \$1 | Bibliothèques CQL contenant une logique de pré-peuplement et une logique conditionnelle |
| ValueSet | 0.. \$1 | Étendu ValueSets (pour les choix de réponses avec moins de 40 extensions) |
**Example Exemple de réponse**
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "PackageBundle",
"resource": {
"resourceType": "Bundle",
"id": "questionnaire-package-example",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-dtr/StructureDefinition/DTR-QPackageBundle"]
},
"type": "collection",
"timestamp": "2024-03-15T10:30:00Z",
"entry": [
{
"fullUrl": "http://example.org/fhir/Questionnaire/home-oxygen-therapy",
"resource": {
"resourceType": "Questionnaire",
"id": "home-oxygen-therapy",
"url": "http://example.org/fhir/Questionnaire/home-oxygen-therapy",
"version": "2.0",
"status": "active",
"title": "Home Oxygen Therapy Documentation",
"item": [
{
"linkId": "1",
"text": "Patient diagnosis",
"type": "choice",
"answerValueSet": "http://example.org/fhir/ValueSet/oxygen-diagnoses"
}
]
}
},
{
"fullUrl": "http://example.org/fhir/Library/oxygen-prepopulation",
"resource": {
"resourceType": "Library",
"id": "oxygen-prepopulation",
"url": "http://example.org/fhir/Library/oxygen-prepopulation",
"version": "1.0",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/library-type",
"code": "logic-library"
}]
},
"content": [{
"contentType": "text/cql",
"data": "bGlicmFyeSBPeHlnZW5QcmVwb3B1bGF0aW9u..."
}]
}
},
{
"fullUrl": "http://example.org/fhir/ValueSet/oxygen-diagnoses",
"resource": {
"resourceType": "ValueSet",
"id": "oxygen-diagnoses",
"url": "http://example.org/fhir/ValueSet/oxygen-diagnoses",
"status": "active",
"expansion": {
"timestamp": "2024-03-15T10:30:00Z",
"contains": [
{
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J44.0",
"display": "COPD with acute lower respiratory infection"
},
{
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J96.01",
"display": "Acute respiratory failure with hypoxia"
}
]
}
}
},
{
"fullUrl": "http://example.org/fhir/QuestionnaireResponse/example-prepopulated",
"resource": {
"resourceType": "QuestionnaireResponse",
"id": "example-prepopulated",
"questionnaire": "http://example.org/fhir/Questionnaire/home-oxygen-therapy|2.0",
"status": "in-progress",
"subject": {
"reference": "Patient/example-patient"
},
"basedOn": [{
"reference": "ServiceRequest/example-service-request"
}],
"item": [
{
"linkId": "1",
"text": "Patient diagnosis",
"answer": [{
"valueCoding": {
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J44.0",
"display": "COPD with acute lower respiratory infection"
}
}]
}
]
}
}
]
}
},
{
"name": "Outcome",
"resource": {
"resourceType": "OperationOutcome",
"issue": [{
"severity": "information",
"code": "informational",
"details": {
"text": "Successfully retrieved questionnaire package"
}
}]
}
}
]
}
```
## Flux de travail des opérations
**Comment HealthLake traite-t-on votre demande**
Lorsque vous appelez`$questionnaire-package`, HealthLake exécute les étapes suivantes :
1. **Identifier le patient et le payeur** : extrait le patient et l'organisme d'assurance de vos `coverage` paramètres.
1. **Trouvez le bon questionnaire** :
+ **Avec `questionnaire`** **paramètre** : utilise l'URL canonique que vous avez fournie
+ **Avec `order`** **paramètre** : fait correspondre le code de commande (CPT/HCPCS/LOINC) et le payeur pour trouver le questionnaire approprié
1. **Collecter les dépendances** : récupère automatiquement tout ce qui est nécessaire pour afficher le questionnaire :
+ **Bibliothèques CQL** - Logique pour les questions de prépopulation et les questions conditionnelles
+ **ValueSets**- Choix de réponses (automatiquement étendus si <40 options)
+ **QuestionnaireResponse**- Toutes les réponses existantes en cours ou terminées
1. **Emballez le tout ensemble** :
+ Regroupe toutes les ressources (chaque ressource n'est incluse qu'une seule fois)
+ Filtre par `changedSince` horodatage s'il est fourni
+ Ajoute des avertissements `Outcome` si des ressources sont manquantes
**Résultat** : un package complet et autonome prêt pour le rendu.
## Réponses d'erreur
### 400 Requête erronée
Renvoyé en cas d'échec de la validation de la demande.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"details": {
"text": "At least one of 'questionnaire' or 'order' must be provided along with 'coverage'"
}
}]
}
```
### 424 Dépendance défaillante
Renvoyé lorsqu'une ressource dépendante ne peut pas être récupérée.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "warning",
"code": "not-found",
"details": {
"text": "Referenced Library 'http://example.org/fhir/Library/missing-library' could not be retrieved"
}
}]
}
```
### 401 Accès non autorisé
Renvoyé lorsque les informations d'authentification sont manquantes ou non valides.
### 403 Forbidden
Renvoyé lorsque l'utilisateur authentifié n'est pas autorisé à accéder aux ressources demandées.
### 406 Non acceptable
Renvoyé lorsque le type de contenu demandé ne peut pas être fourni.
### 409 – Conflit
Renvoyé en cas de conflit de version ou de simultanéité.
### 410 Disparus
Renvoyé lorsque la ressource demandée a été définitivement supprimée.
### 429 Trop de demandes
Renvoyé lorsque les limites de débit sont dépassées.
### 500 Erreur de serveur interne
Renvoyé lorsqu'une erreur de serveur inattendue se produit.
### 501 Non implémenté
Renvoyé lorsque l'opération demandée n'est pas encore implémentée.
## Règles de validation
### Validation des entrées
+ `coverage`le paramètre est **obligatoire** (1.. \$1 cardinalité)
+ Au moins l'un `questionnaire` des éléments `order` suivants doit être fourni
+ Toutes les ressources de couverture doivent être des ressources FHIR valides
+ Toutes les ressources de la commande doivent être des ressources FHIR valides
+ Canonical URLs doit être correctement formaté
+ `changedSince`doit être un DateTime ISO 8601 valide
### QuestionnaireResponse validation
+ `status`doit être approprié (`in-progress`,`completed`,`amended`)
+ La structure doit correspondre au questionnaire référencé
+ `basedOn`doit faire référence à des ressources de commande valides
+ `subject`doit faire référence à des ressources valides pour les patients
### Déduplication des ressources
+ Chaque ressource n'apparaît qu'une seule fois dans le bundle
+ Exception : différentes versions de la même ressource peuvent toutes deux être incluses
+ Les ressources sont identifiées par leur URL canonique et leur version
## Spécifications de performance
| Métrique | Spécification de |
| --- | --- |
| Limite du nombre de ressources | 500 ressources par bundle |
| Limite de taille du bundle | 5 Mo maximum |
## Autorisations requises
Pour utiliser l'`$questionnaire-package`opération, assurez-vous que votre rôle IAM possède les éléments suivants :
+ `healthlake:QuestionnairePackage`- Pour appeler l'opération
+ `healthlake:ReadResource`- Pour récupérer le questionnaire et les ressources dépendantes
+ `healthlake:SearchWithPost`- Pour rechercher QuestionnaireResponse des ressources connexes
**SMART sur les oscilloscopes FHIR**
**Étendue minimale requise :**
+ **SMART version 1** : `user/Questionnaire.read user/Library.read user/ValueSet.read user/QuestionnaireResponse.read`
+ **SMART v2** : `user/Questionnaire.rs user/Library.rs user/ValueSet.rs user/QuestionnaireResponse.rs`
## Remarques de mise en œuvre importantes
### Stratégie de récupération des ressources
**Priorité d'identification du questionnaire :**
+ **URL canonique** (si le `questionnaire` paramètre est fourni) - Priorité la plus élevée
+ **Analyse de la commande** (si `order` le paramètre est fourni) :
+ Associez les codes de commande (CPT, HCPCS, LOINC) aux politiques médicales du payeur
+ Utilisez le payeur de couverture pour filtrer les questionnaires spécifiques au payeur
+ Tenez compte des codes de motif pour un contexte supplémentaire
### Résolution des dépendances
**Bibliothèques CQL :**
+ Récupéré via l'`cqf-library`extension sur les ressources du questionnaire
+ Récupère récursivement les bibliothèques dépendantes via le type `Library.relatedArtifact` `depends-on`
+ Toutes les dépendances de bibliothèque sont incluses dans le package
**ValueSets:**
+ Développé automatiquement s'ils contiennent moins de 40 concepts
+ ValueSets Les plus grands sont inclus sans extension
+ ValueSets référencées à la fois dans le questionnaire et les ressources de la bibliothèque sont incluses
### QuestionnaireResponse pré-population
L'opération peut renvoyer un fichier QuestionnaireResponse avec des données préremplies lorsque :
+ Une réponse existante en cours ou terminée est trouvée
+ La logique CQL des bibliothèques associées peut extraire des données des dossiers des patients
+ La réponse est liée à la commande et à la couverture pertinentes
**Critères de recherche pour QuestionnaireResponse :**
| Paramètre de recherche | Parcours FHIR | Description |
| --- | --- | --- |
| based-on | QuestionnaireResponse.basedOn | Liens vers ServiceRequest ou CarePlan |
| patient | QuestionnaireResponse.subject | Le patient qui est le sujet |
| questionnaire | QuestionnaireResponse.questionnaire | Le questionnaire auquel il est répondu |
### Filtrage des ressources modifié
Lorsque le `changedSince` paramètre est fourni :
+ Seules les ressources modifiées **après** l'horodatage spécifié sont incluses
+ Si aucune ressource n'a changé, retourne `200 OK` avec un package vide
+ Utile pour les mises à jour incrémentielles et les stratégies de mise en cache
+ La comparaison des horodatages utilise le champ de ressources `meta.lastUpdated`
### Forfaits groupés multiples
L'opération peut renvoyer **plusieurs Package Bundles** lorsque :
+ Plusieurs questionnaires sont demandés via Canonical URLs
+ Les commandes multiples nécessitent des questionnaires différents
+ Différentes versions du même questionnaire sont applicables
Chaque Package Bundle est autonome avec toutes les dépendances nécessaires.
## Cas d’utilisation courants
### Cas d'utilisation 1 : documentation relative à l'autorisation préalable
**Scénario** : Un fournisseur doit recueillir de la documentation pour une autorisation préalable d'oxygénothérapie à domicile.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Patient's insurance coverage */ }
},
{
"name": "order",
"resource": {
"resourceType": "ServiceRequest",
"code": {
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "94660"
}]
}
}
}
]
}
```
**Résultat** : renvoie un colis contenant le questionnaire d'oxygénothérapie, prérempli avec les données vitales du patient et les codes de diagnostic du dossier médical électronique.
### Cas d'utilisation 2 : récupérer une version spécifique du questionnaire
**Scénario** : un fournisseur a besoin d'une version spécifique d'un questionnaire pour se conformer.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme-request|3.1.0"
}
]
}
```
**Résultat** : renvoie exactement la version 3.1.0 du questionnaire de demande DME avec toutes les dépendances.
### Cas d'utilisation 3 : Vérifier les mises à jour
**Scénario** : un fournisseur souhaite vérifier si des ressources du questionnaire ont été mises à jour depuis la dernière extraction.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/medication-request"
},
{
"name": "changedSince",
"valueDateTime": "2024-03-01T00:00:00Z"
}
]
}
```
**Résultat** : renvoie uniquement les ressources qui ont été modifiées après le 1er mars 2024, ou un package vide si rien n'a changé.
### Cas d'utilisation 4 : commandes multiples
**Scénario** : un fournisseur soumet plusieurs demandes de service qui peuvent nécessiter différents questionnaires.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for imaging */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for DME */ }
}
]
}
```
**Résultat** : renvoie plusieurs Packages groupés, un pour chaque questionnaire applicable.
## Intégration avec d'autres Da Vinci IGs
### Découverte des exigences de couverture (CRD)
**Intégration du flux de travail :**
+ Le fournisseur commande un service dans son dossier électronique
+ Feux à l'hameçon CRD, vérification des exigences de couverture
+ Le payeur répond en indiquant que la documentation est nécessaire
+ Le fournisseur appelle `$questionnaire-package` pour récupérer le formulaire de documentation
+ Le fournisseur remplit le questionnaire
+ La documentation est soumise via PAS ou CDex
### Support d'autorisation préalable (PAS)
**Intégration du flux de travail :**
+ `$questionnaire-package`À utiliser pour récupérer les exigences en matière de documentation
+ Complétez le QuestionnaireResponse avec les données cliniques requises
+ Soumettez l'autorisation préalable `Claim/$submit` en utilisant le QuestionnaireResponse
+ Vérifiez le statut à l'aide de `Claim/$inquire`
### Échange de données cliniques (CDex)
**Intégration du flux de travail :**
+ Le payeur demande des documents supplémentaires pour une réclamation
+ Le fournisseur utilise `$questionnaire-package` pour récupérer le formulaire de collecte de données structuré
+ Le fournisseur complète le QuestionnaireResponse
+ La documentation est soumise au payeur via un flux de travail de CDex pièces jointes
## Guide de dépannage
### Problème : aucun questionnaire n'a été renvoyé
**Causes possibles :**
+ L'URL canonique ne correspond à aucun questionnaire du magasin de données
+ Le code de commande ne correspond à aucun questionnaire de la police médicale du payeur
+ Le payeur de couverture n'a pas de questionnaires associés
**Solutions :**
+ Vérifiez que l'URL canonique est correcte et que le questionnaire existe
+ Vérifiez que les codes de commande (CPT/HCPCS) sont correctement spécifiés
+ Vérifiez que l'organisation payeuse a configuré des questionnaires
### Problème : dépendances manquantes dans le package
**Causes possibles :**
+ Bibliothèque référencée ou ValueSet n'existe pas dans le magasin de données
+ Les références de bibliothèque sont cassées ou incorrectes
+ ValueSet échec de l'extension
**Solutions :**
+ Vérifiez le `Outcome` paramètre pour les avertissements concernant les ressources manquantes
+ Vérifiez que toutes les ressources référencées existent dans votre magasin de données
+ Assurez-vous qu' ValueSet URLs ils sont corrects et résolvables
### Problème : Package vide avec ChangedSince
**Causes possibles :**
+ Ce comportement est attendu : aucune ressource n'a été modifiée depuis l'horodatage spécifié
**Solutions :**
+ Utiliser la version mise en cache du package
+ Supprimer `changedSince` le paramètre pour récupérer le package complet
### Problème : QuestionnaireResponse Non prérempli
**Causes possibles :**
+ Aucun objet existant n' QuestionnaireResponse a été trouvé
+ La logique de la bibliothèque CQL n'a pas pu extraire les données requises
+ Les données du patient sont manquantes ou incomplètes
**Solutions :**
+ On peut s'y attendre, car tous les questionnaires ne reposent pas sur une logique de pré-population
+ Vérifiez que les données du patient existent dans le magasin de données
+ Vérifiez la logique de la bibliothèque CQL pour connaître les exigences en matière d'extraction de données
## Bonnes pratiques
### 1. Utiliser Canonical URLs avec les versions
Spécifiez toujours les numéros de version lorsque vous demandez des questionnaires spécifiques :
```
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme|2.1.0"
}
```
**Pourquoi** : Garantit la cohérence et empêche les changements inattendus lors de la mise à jour des questionnaires.
### 2. Tirez parti de ChangedSince pour améliorer les performances
Pour les questionnaires fréquemment consultés, utilisez `changedSince` pour minimiser le transfert de données :
```
{
"name": "changedSince",
"valueDateTime": "2024-03-10T15:30:00Z"
}
```
**Pourquoi** : réduit la latence et l'utilisation de la bande passante en ne récupérant que les ressources mises à jour.
### 3. Incluez des informations complètes sur la couverture
Fournissez des informations complètes sur la couverture afin de garantir une sélection correcte du questionnaire :
```
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"beneficiary": { "reference": "Patient/123" },
"payor": [{ "reference": "Organization/payer-abc" }],
"class": [{ /* Group/plan information */ }]
}
}
```
**Pourquoi** : aide à HealthLake identifier les questionnaires et les exigences spécifiques au payeur.
## Opérations liées
+ `Claim/$submit`- Soumettre les demandes d'autorisation préalable avec la documentation complète
+ `Claim/$inquire`- Vérifier l'état des autorisations antérieures soumises
+ `ValueSet/$expand`- Élargir ValueSets pour les choix de réponses
# `$submit`Opération FHIR pour HealthLake
L'`$submit`opération vous permet de soumettre électroniquement des demandes d'autorisation préalable aux payeurs pour approbation. Cette opération met en œuvre le [guide de mise en œuvre du Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), fournissant un flux de travail standardisé basé sur le FHIR pour les soumissions d'autorisations préalables.
## Comment ça marche
+ **Soumettre** : vous envoyez un bundle FHIR contenant votre demande d'autorisation préalable et les données cliniques à l'appui
+ **Valider** : HealthLake valide la soumission par rapport aux exigences du PAS
+ **Persister** : toutes les ressources sont stockées dans votre magasin HealthLake de données
+ **Répondre** : vous recevez une réponse immédiate avec le statut « en file d'attente »
+ **Processus** : La décision d'autorisation est traitée de manière asynchrone par le payeur
## Point de terminaison d’API
```
POST /datastore/{datastoreId}/r4/Claim/$submit
Content-Type: application/fhir+json
```
## Structure de la demande
### Exigences relatives au bundle
Votre demande doit être une ressource FHIR Bundle contenant :
+ **Bundle.type** : Doit être `"collection"`
+ **Bundle.entry** : doit contenir exactement **une** ressource Claim avec `use = "preauthorization"`
+ **Ressources référencées** : Toutes les ressources référencées par la réclamation doivent être incluses dans le bundle
### Ressources requises
| Ressource | Cardinalité | Profil | Description |
| --- | --- | --- | --- |
| Réclamation | 1 | Réclamation PAS | La demande d'autorisation préalable |
| Patient | 1 | Patient PAS | Informations démographiques sur les patients |
| Organisation (assureur) | 1 | Assureur PAS | Compagnie d'assurance |
| Organisation (fournisseur) | 1 | Demandeur PAS | Prestataire de santé soumettant la demande |
| Couverture | 1 ou plus | Couverture PAS | Détails de la couverture d'assurance |
### Ressources facultatives
| Ressource | Cardinalité | Profil | Description |
| --- | --- | --- | --- |
| Praticien | 0 ou plus | Praticien PAS | Praticiens de santé |
| PractitionerRole | 0 ou plus | PAS PractitionerRole | Rôles des praticiens |
| ServiceRequest | 0 ou plus | PAS ServiceRequest | Services médicaux demandés |
| DeviceRequest | 0 ou plus | PAS DeviceRequest | Dispositifs médicaux demandés |
| MedicationRequest | 0 ou plus | PAS MedicationRequest | Médicaments demandés |
| DocumentReference | 0 ou plus | PAS DocumentReference | Documentation clinique à l'appui |
## Exemple de demande
```
POST /datastore/example-datastore/r4/Claim/$submit
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType" : "Bundle",
"id" : "MedicalServicesAuthorizationBundleExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-request-bundle"]
},
"identifier" : {
"system" : "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value" : "5269367"
},
"type" : "collection",
"timestamp" : "2005-05-02T11:01:00+05:00",
"entry" : [{
"fullUrl" : "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource" : {
"resourceType" : "Claim",
"id" : "MedicalServicesAuthorizationExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim"]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:01:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"provider" : {
"reference" : "Organization/UMOExample"
},
"priority" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/processpriority",
"code" : "normal"
}]
},
"insurance" : [{
"sequence" : 1,
"focal" : true,
"coverage" : {
"reference" : "Coverage/InsuranceExample"
}
}],
"item" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceItemRequestType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1525",
"code" : "IN",
"display" : "Initial Medical Services Reservation"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1322",
"code" : "I",
"display" : "Initial"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-authorizationNumber",
"valueString" : "1122344"
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
"valueString" : "33441122"
}],
"sequence" : 1,
"category" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1365",
"code" : "1",
"display" : "Medical Care"
}]
},
"productOrService" : {
"coding" : [{
"system" : "http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets",
"code" : "99212",
"display" : "Established Office Visit"
}]
},
"servicedDate" : "2005-05-10",
"locationCodeableConcept" : {
"coding" : [{
"system" : "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
"code" : "11"
}]
}
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/UMOExample",
"resource" : {
"resourceType" : "Organization",
"id" : "UMOExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "8189991234"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "X3"
}]
}],
"name" : "DR. JOE SMITH CORPORATION",
"address" : [{
"line" : ["111 1ST STREET"],
"city" : "SAN DIEGO",
"state" : "CA",
"postalCode" : "92101",
"country" : "US"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/InsurerExample",
"resource" : {
"resourceType" : "Organization",
"id" : "InsurerExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "1234567893"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "PR"
}]
}],
"name" : "MARYLAND CAPITAL INSURANCE COMPANY"
}
},
{
"fullUrl" : "http://example.org/fhir/Coverage/InsuranceExample",
"resource" : {
"resourceType" : "Coverage",
"id" : "InsuranceExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage"]
},
"status" : "active",
"subscriberId" : "1122334455",
"beneficiary" : {
"reference" : "Patient/SubscriberExample"
},
"relationship" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code" : "self"
},
{
"system" : "https://codesystem.x12.org/005010/1069",
"code" : "18"
}]
},
"payor" : [{
"reference" : "Organization/InsurerExample"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Patient/SubscriberExample",
"resource" : {
"resourceType" : "Patient",
"id" : "SubscriberExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-subscriber"]
},
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-militaryStatus",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/584",
"code" : "RU"
}]
}
}],
"identifier" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MB"
}]
},
"system" : "http://example.org/MIN",
"value" : "12345678901"
}],
"name" : [{
"family" : "SMITH",
"given" : ["JOE"]
}],
"gender" : "male"
}
}]
}
```
## Format de la réponse
### Réponse positive (200 OK)
Vous recevrez un pack de réponses PAS contenant :
+ **ClaimResponse**avec `outcome: "queued"` et `status: "active"`
+ Toutes les ressources originales de votre demande
+ Horodatage confirmant la réception
```
{
"resourceType" : "Bundle",
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269367"
},
"type" : "collection",
"timestamp" : "2005-05-02T11:02:00+05:00",
"entry" : [{
"fullUrl" : "http://example.org/fhir/ClaimResponse/PractitionerRequestorPendingResponseExample",
"resource" : {
"resourceType" : "ClaimResponse",
"id" : "PractitionerRequestorPendingResponseExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse"]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:02:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"requestor" : {
"reference" : "PractitionerRole/ReferralPractitionerRoleExample"
},
"request" : {
"reference" : "Claim/MedicalServicesAuthorizationExample"
},
"outcome" : "queued"
}
},
{
"fullUrl" : "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource" : {
"resourceType" : "Claim",
"id" : "MedicalServicesAuthorizationExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim|2.1.0"
]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:01:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"provider" : {
"reference" : "Organization/UMOExample"
},
"priority" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/processpriority",
"code" : "normal"
}]
},
"insurance" : [{
"sequence" : 1,
"focal" : true,
"coverage" : {
"reference" : "Coverage/InsuranceExample"
}
}],
"item" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceItemRequestType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1525",
"code" : "IN",
"display" : "Initial Medical Services Reservation"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1322",
"code" : "I",
"display" : "Initial"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-authorizationNumber",
"valueString" : "1122344"
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
"valueString" : "33441122"
}],
"sequence" : 1,
"category" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1365",
"code" : "1",
"display" : "Medical Care"
}]
},
"productOrService" : {
"coding" : [{
"system" : "http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets",
"code" : "99212",
"display" : "Established Office Visit"
}]
},
"servicedDate" : "2005-05-10",
"locationCodeableConcept" : {
"coding" : [{
"system" : "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
"code" : "11"
}]
}
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/UMOExample",
"resource" : {
"resourceType" : "Organization",
"id" : "UMOExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor|2.1.0"
]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "8189991234"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "X3"
}]
}],
"name" : "DR. JOE SMITH CORPORATION",
"address" : [{
"line" : ["111 1ST STREET"],
"city" : "SAN DIEGO",
"state" : "CA",
"postalCode" : "92101",
"country" : "US"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/InsurerExample",
"resource" : {
"resourceType" : "Organization",
"id" : "InsurerExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer|2.1.0"
]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "1234567893"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "PR"
}]
}],
"name" : "MARYLAND CAPITAL INSURANCE COMPANY"
}
},
{
"fullUrl" : "http://example.org/fhir/Coverage/InsuranceExample",
"resource" : {
"resourceType" : "Coverage",
"id" : "InsuranceExample",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage|2.1.0"
]
},
"status" : "active",
"subscriberId" : "1122334455",
"beneficiary" : {
"reference" : "Patient/SubscriberExample"
},
"relationship" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code" : "self"
},
{
"system" : "https://codesystem.x12.org/005010/1069",
"code" : "18"
}]
},
"payor" : [{
"reference" : "Organization/InsurerExample"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Patient/SubscriberExample",
"resource" : {
"resourceType" : "Patient",
"id" : "SubscriberExample",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-subscriber",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary|2.1.0"
]
},
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-militaryStatus",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/584",
"code" : "RU"
}]
}
}],
"identifier" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MB"
}]
},
"system" : "http://example.org/MIN",
"value" : "12345678901"
}],
"name" : [{
"family" : "SMITH",
"given" : ["JOE"]
}],
"gender" : "male"
}
}]
}
```
## Réponses d'erreur
### 400 Requête erronée
Renvoyé lorsque le format de demande n'est pas valide ou est mal formé.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "invalid",
"diagnostics": "The provided payload was invalid and could not be parsed correctly."
}]
}
```
### 412 – Échec de condition préalable
Renvoyé lorsque la même demande d'autorisation préalable a déjà été soumise (envoi dupliqué détecté).
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "processing",
"diagnostics": "PreAuth Claim already exists"
}]
}
```
**Idempotence**
L'`$submit`opération est idempotente. Le fait de soumettre la même demande plusieurs fois ne créera pas de demandes d'autorisation préalable dupliquées. Au lieu de cela, vous recevrez un message d'erreur 412 vous demandant de `$inquire` vérifier le statut de votre envoi initial.
### 422 Entité non traitable
Renvoyé en cas d'échec de la validation FHIR.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"diagnostics": "Bundle contains more than one preauthorization claim"
}]
}
```
## Règles de validation
HealthLake effectue une validation complète de votre soumission :
### Validation du bundle
+ Doit être conforme au profil du bundle de demandes PAS
+ `Bundle.type`doit être `"collection"`
+ Peut contenir plusieurs ressources de réclamation
+ Cependant, il doit contenir exactement une ressource Claim avec une utilisation préautorisée
+ Et cette ressource Claim doit être la première entrée du bundle
+ Toutes les ressources référencées doivent être incluses dans le bundle
### Validation des réclamations
+ Doit être conforme au profil de réclamation PAS
+ `Claim.use`doit être `"preauthorization"`
+ Champs obligatoires : `patient``insurer`,`provider`,`created`, `priority`
+ Les identifiants commerciaux doivent être présents et valides
### Validation des ressources
+ Toutes les ressources doivent être conformes à leurs profils PAS respectifs
+ Les ressources de soutien requises doivent être présentes (patient, couverture, organisation)
+ Les références croisées doivent être valides et résolvables dans le bundle
## Spécifications de performance
| Métrique | Spécification de |
| --- | --- |
| Limite de taille du bundle | 5 Mo maximum |
| Limite du nombre de ressources | 500 ressources par bundle |
## Autorisations requises
Pour utiliser l'`$submit`opération, on peut utiliser AWS Sigv4 ou SMART sur FHIR :
+ Assurez-vous que votre rôle IAM comporte : `healthlake:SubmitPreAuthClaim` - Pour appeler l'opération
**SMART sur les oscilloscopes FHIR**
**Étendue minimale requise :**
+ **SMART version 1** : `user/Claim.write & .write`
+ **SMART v2** : `user/Claim.c & .c or system/*.*`
## Remarques de mise en œuvre importantes
### Persistance des ressources
+ Toutes les entrées du bundle sont conservées en tant que ressources FHIR individuelles dans votre magasin de données
+ Les produits fournis par le client IDs sont conservés lorsqu'ils sont fournis
+ L'historique des versions est conservé à des fins d'audit
+ La détection des doublons prévient les conflits de ressources
### Comportement de traitement
+ Chaque soumission valide donne lieu à exactement une ClaimResponse avec `"queued"` résultat
+ Les soumissions non valides renvoient 400 ou 422 codes d'état avec des informations d'erreur détaillées
+ Les erreurs du système renvoient les codes d'état 5xx appropriés
+ Toutes les soumissions réussies renvoient le statut 200 avec un statut en attente ClaimResponse
### Exigences relatives au bundle
+ `Bundle.entry.fullUrl`les valeurs doivent être soit au format REST, URLs soit `"urn:uuid:[guid]"` au format
+ Toutes les soumissions GUIDs doivent être uniques (sauf pour les mêmes instances de ressources)
+ Les ressources référencées doivent exister dans le bundle ou être résolvables
## Opérations liées
+ `Claim/$inquire`- Vérifier le statut d'une demande d'autorisation préalable soumise
+ `Patient/$everything`- Récupérez les données complètes du patient pour le contexte de l'autorisation préalable
# Validation des ressources FHIR avec `$validate`
AWS HealthLake prend désormais en charge le `$validate` fonctionnement des ressources FHIR, ce qui vous permet de valider une ressource par rapport à la spécification FHIR et de vérifier sa conformité à un profil spécifié ou à une définition de ressource de base sans effectuer d'opérations de stockage. Cette opération est particulièrement utile lorsque vous devez :
+ Valider les exigences de conformité du CMS FHIR
+ Testez les ressources avant de les utiliser en production
+ Fournir des commentaires de validation en temps réel lorsque les utilisateurs modifient les données cliniques
+ Réduisez les soumissions de données non valides pour la création et la mise à jour APIs
## Usage
L'`$validate`opération peut être invoquée sur les ressources FHIR à l'aide des méthodes POST :
**Opérations prises en charge**
```
POST [base]/[type]/[id]/$validate
POST [base]/[type]/$validate
```
## Charges utiles prises en charge
**Ressource de paramètres**
HealthLake prend en charge les `$validate` paramètres FHIR suivants :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| resource | Ressource | Oui | La ressource à valider |
| profile | canonial | Non | URL canonique du profil par rapport auquel valider |
| mode | code | Non | Mode de validation :create, ou update |
**Ressource directe avec paramètres de requête**
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| profile | canonial | Non | URL canonique du profil par rapport auquel valider |
| mode | code | Non | Mode de validation :create, ou update |
## Exemples
**Demande POST pour une ressource avec ID et paramètres (charge utile)**
```
POST [base]/Patient/example-patient/$validate
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
},
{
"name": "profile",
"valueCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
},
{
"name": "mode",
"valueString": "create"
}
]
}
```
**Demande POST pour le type de ressource et la charge utile des paramètres**
```
POST [base]/Patient/$validate
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Doe",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1985-05-15"
}
},
{
"name": "profile",
"valueCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
},
{
"name": "mode",
"valueString": "update"
}
]
}
```
**Demande de ressource POST avec identifiant et charge utile directe de la ressource**
```
POST [base]/Patient/example-patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient&mode=create
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
```
**Demande POST pour le type de ressource et la charge utile directe de la ressource**
```
POST [base]/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient&mode=create
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
```
**Exemple de réponse**
L'opération renvoie une OperationOutcome ressource avec les résultats de validation :
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Validation successful"
}
]
}
```
**Exemple de réponse avec erreurs de validation**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "required",
"details": {
"text": "Missing required element"
},
"diagnostics": "Patient.identifier is required by the US Core Patient profile",
"location": [
"Patient.identifier"
]
},
{
"severity": "warning",
"code": "code-invalid",
"details": {
"text": "Invalid code value"
},
"diagnostics": "The provided gender code is not from the required value set",
"location": [
"Patient.gender"
]
}
]
}
```
## Comportement
L'`$validate`opération :
1. Valide la ressource par rapport à la spécification FHIR et à la définition de la ressource de base
1. Vérifie la conformité aux profils spécifiés lorsque le `profile` paramètre est fourni
1. Valide en fonction du mode spécifié (`create`ou`update`)
1. Renvoie les résultats de validation détaillés, y compris les erreurs, les avertissements et les messages d'information
1. N'effectue aucune opération de stockage - validation uniquement
1. Renvoie HTTP 200 OK lorsque la validation peut être effectuée, que des problèmes de validation soient détectés ou non
## Modes de validation
+ **créer** : valide la ressource comme si elle était en cours de création (nouvelle ressource)
+ **mise à jour** : valide la ressource comme si elle était mise à jour (ressource existante)
## Gestion des erreurs
L'opération renvoie :
+ 200 OK : La validation a été effectuée avec succès (quel que soit le résultat de la validation)
+ 400 Demande incorrecte : format ou paramètres de demande non valides
+ 404 Introuvable : type de ressource ou profil introuvable
Pour plus d'informations sur les spécifications de `$validate` fonctionnement, consultez la documentation des [ressources `$validate` FHIR R4](https://www.hl7.org/fhir/R4/operation-resource-validate.html).