Supporté SMART sur les FHIR OAuth oscilloscopes par HealthLake - AWS 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.

Supporté SMART sur les FHIR OAuth oscilloscopes 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 les FHIR ressources de votre magasin de HealthLake données auxquelles une application cliente peut également avoir un accès en lecture et/ou en écriture.

Le FHIR framework SMART on définit un ensemble de portées qui peuvent être demandées au serveur d'autorisation. Pour consulter les définitions du champ d'application dans le FHIR framework SMART on, voir SMARTle guide FHIR des HL7 FHIR ressources sur les champs d'application.

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 (sur FHIR REST demande) read des scopes. Pour les définir comme scope, vous devez fournir une chaîne comme celle-cipatient/Observation.read. Cela permettrait à l'application cliente de demander l'accès au type de Observation ressource en lecture seule sur le type de Patient ressource.

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éeDescription

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.

HealthLake portées spécifiques aux FHIR ressources du magasin de données

HealthLake définit trois niveaux de portée.

  • Les scopes spécifiques au patient donnent accès à des données spécifiques concernant un seul patient. Quel patient est spécifié dans le contexte de lancement.

  • Les étendues au niveau de l'utilisateur accordent l'accès à des données spécifiques auxquelles un utilisateur peut accéder.

  • Les étendues au niveau du système accordent un accès en lecture/écriture à toutes les FHIR ressources présentes dans le magasin de données. HealthLake

Le tableau suivant indique la syntaxe permettant de créer des étendues liées aux FHIR ressources prises en charge par HealthLake. Le format général est le suivant :

( 'patient' | 'user' | 'system' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )
Étendue d'autorisation prise en charge sur les magasins HealthLake de données
Syntaxe ScopeExemple de portéeRésultat

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

patient/AllergyIntolerance.*Une application cliente aurait un accès en lecture/écriture aux allergies.

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

user/Observation.readUne application cliente aurait un accès en lecture à toutes les observations enregistrées.
system/('read' | 'write' | *)system/*.*Une application cliente aurait un accès en lecture/écriture à toutes les données.