SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake - AWS HealthLake
Périmètre de lancement autonomeSMART sur les champs de ressources FHIR pour HealthLake

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.

SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake

HealthLake utilise le OAuth 2.0 comme protocole d'autorisation. L'utilisation de ce protocole sur votre serveur d'autorisation vous permet de définir HealthLake des autorisations de stockage de données (création, lecture, mise à jour, suppression et recherche) pour les ressources FHIR auxquelles une application cliente a accès.

Le framework SMART on FHIR définit un ensemble de champs d'application qui peuvent être demandés au serveur d'autorisation. Par exemple, une application client conçue uniquement pour permettre aux patients de consulter leurs résultats de laboratoire ou de consulter leurs coordonnées ne doit être autorisée qu'à demander read des scopes.

Note

HealthLake fournit un support pour SMART sur FHIR V1 et V2, comme décrit ci-dessous. Le SMART on FHIR AuthorizationStrategyest défini sur l'une des trois valeurs suivantes lors de la création de votre magasin de données :

  • SMART_ON_FHIR_V1— Support uniquement pour SMART sur FHIR V1, qui inclut les autorisations read (lecture/recherche) et write (create/update/delete).

  • SMART_ON_FHIR— Support de SMART sur FHIR V1 et V2, qui inclutcreate,read, updatedelete, et search les autorisations.

  • AWS_AUTH— La stratégie AWS HealthLake d'autorisation par défaut ; non affiliée à SMART on FHIR.

Périmètre de lancement autonome

HealthLake prend en charge le champ launch/patient d'application du mode de lancement autonome.

En mode de lancement autonome, une application client demande l'accès aux données cliniques du patient car l'utilisateur et le patient ne sont pas connus de l'application cliente. Ainsi, la demande d'autorisation de l'application cliente demande explicitement que le dossier du patient soit renvoyé. Une fois l'authentification réussie, le serveur d'autorisation émet un jeton d'accès contenant le champ d'application du patient de lancement demandé. Le contexte patient nécessaire est fourni avec le jeton d'accès dans la réponse du serveur d'autorisation.

Champs d'application du mode de lancement pris en charge
Portée Description

launch/patient

Paramètre d'une demande d'autorisation OAuth 2.0 demandant que les données du patient soient renvoyées dans la réponse d'autorisation.

SMART sur les champs de ressources FHIR pour HealthLake

HealthLake définit trois niveaux de SMART sur les étendues de ressources FHIR.

  • patientles scopes donnent accès à des données spécifiques concernant un seul patient.

  • userles étendues donnent accès à des données spécifiques auxquelles un utilisateur peut accéder.

  • systemles étendues donnent accès à toutes les ressources FHIR présentes dans le magasin de HealthLake données.

Les sections suivantes répertorient la syntaxe permettant de créer des étendues de ressources FHIR à l'aide de SMART sur FHIR V1 ou SMART sur FHIR V2.

Note

La stratégie d'autorisation SMART on FHIR est définie lors de la création de votre magasin de données. Pour plus d’informations, consultez AuthorizationStrategy dans la Référence d’API AWS HealthLake .

SMART sur les oscilloscopes FHIR V1 pris en charge par HealthLake

Lorsque vous utilisez SMART sur FHIR V1, la syntaxe générale pour la construction des étendues de ressources FHIR est la suivante. HealthLake Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton Copier.

('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
Champs d'autorisation pris en charge par SMART on FHIR v1
Syntaxe Scope Exemple de champ d'application Résultat

patient/(fhir-resource | '*').('read' | 'write' | '*')

 patient/AllergyIntolerance.* L'application client du patient dispose d'un accès en lecture/écriture au niveau de l'instance à toutes les allergies enregistrées.

user/(fhir-resource | '*').('read' | 'write' | '*')

 user/Observation.read L'application cliente utilisateur dispose d'un read/write accès au niveau de l'instance à toutes les observations enregistrées.
system/('read' | 'write' | *) system/*.* L'application cliente du système a read/write accès à toutes les données des ressources FHIR.

SMART sur les oscilloscopes FHIR V2 pris en charge par HealthLake

Lorsque vous utilisez SMART sur FHIR V2, la syntaxe générale pour la construction des étendues de ressources FHIR est la suivante. HealthLake Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton Copier.

('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
Note

Pour utiliser SMART sur FHIR V2, vous devez transmettre la valeur permission-v2dans la capabilities chaîne de métadonnées, qui est membre du type de IdentityProviderConfigurationdonnées.

HealthLake prend en charge les oscilloscopes granulaires. Pour plus d'informations, voir les étendues granulaires prises en charge dans le guide de mise en œuvre de FHIR US Core.

Étendue d'autorisation compatible avec SMART on FHIR V2
Syntaxe Scope Exemple de scope V1 Résultat

patient/Observation.rs

 user/Observation.read Autorisation de lire et de rechercher Observation une ressource pour le patient actuel.

system/*.cruds

 system/*.* L'application cliente du système dispose d'un create/read/update/delete/search accès complet à toutes les données de ressources FHIR.