Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Demandes d'accès des cliniques avec approbation du patient (CIBA)

Le flux OpenID CIBA derrière les demandes d'accès des cliniques : la réception saisit l'e-mail du patient, le patient approuve dans l'application ou par e-mail pour 30, 90 ou 365 jours, et l'application de la clinique reçoit des jetons.

Une clinique n'accède au dossier d'un patient sur Anpheros que lorsque le patient l'approuve. L'application de la clinique envoie une demande nommant l'adresse e-mail du patient et l'accès dont elle a besoin. Le patient la reçoit dans l'application Anpheros et par e-mail, voit qui demande et pour quoi, choisit la durée d'autorisation, et approuve ou refuse. S'il approuve, l'application de la clinique reçoit des jetons et peut lire le dossier jusqu'à l'expiration de l'accès ou son retrait par le patient.

Le flux est le flux standard OpenID Connect Client-Initiated Backchannel Authentication (CIBA), en mode interrogation (poll mode). Il existe pour qu'un réceptionniste n'ait pas besoin de remettre un téléphone ou un lien au patient : la demande est adressée au patient, et non via l'écran de la clinique.

Étapes

1. La réception saisit l'e-mail du patient. L'application de la clinique appelle POST /oauth/bc-authorize avec ses identifiants client, l'e-mail du patient comme login_hint, le scope dont elle a besoin et un court binding_message que le patient verra.
2. La plateforme répond de la même manière pour chaque adresse. La réponse contient un auth_req_id, une date d'expiration et un intervalle d'interrogation, que cet e-mail ait ou non un compte Anpheros. Elle ne révèle pas qui a un dossier. Une requête pour une personne sans compte expire simplement.
3. Le patient décide. Il reçoit une notification dans l'application Anpheros et un e-mail. La requête affiche l'organisation, la portée et le message. Il choisit une période de 30, 90 ou 365 jours et clique sur autoriser ou refuser. Le lien dans l'e-mail n'approuve rien lorsqu'il est ouvert, car les scanners de messagerie ouvrent les liens ; le patient doit appuyer sur le bouton.
4. La clinique interroge. L'application appelle POST /oauth/token avec le type d'octroi urn:openid:params:grant-type:ciba et le auth_req_id. Tant que le patient n'a pas décidé, la réponse est authorization_pending. Après approbation, les jetons sont retournés une fois. Un refus renvoie access_denied et une requête sans réponse renvoie expired_token.
5. La clinique lit et écrit dans la portée accordée. Chaque lecture est enregistrée et visible par le patient. Une clinique ne peut modifier ou supprimer que ce qu'elle a écrit elle-même.

Ce qui protège le patient

• Email vérifié uniquement. Une requête ne correspond qu'à un compte dont l'adresse e-mail est vérifiée, ainsi personne ne peut recevoir les requêtes d'une autre personne en créant un compte avec son adresse.
• Limité en portée et en durée. L'accès est par type de ressource et par action, pour une période définie. Une requête à laquelle personne ne répond expire par défaut dans un délai d'un jour et au maximum sept jours.
• Révocable à tout moment. La révocation prend effet dès la prochaine requête. La clinique ne peut pas se reconnecter.
• Visible. Le patient voit chaque connexion et chaque accès dans l'application. Voir modèle de consentement et d'accès.

Ce dont une clinique a besoin pour construire

• Un client OAuth confidentiel enregistré auprès de la plateforme, avec son secret conservé sur le serveur.
• Une boucle de scrutation qui respecte l'intervalle et gère les quatre résultats.
• Un moyen d'afficher la décision du patient à la réception ("en attente du patient", "approuvé jusqu'au …", "refusé").
• Gestion des tokens retournés comme des identifiants de courte durée : les tokens d'accès durent 30 minutes et les tokens de rafraîchissement sont mis à jour à chaque utilisation. Voir authentification et OAuth.

Pour une clinique qui préfère ouvrir une page de consentement devant le patient, par exemple à la réception, le flux standard de code d'autorisation avec PKCE et le lancement autonome SMART on FHIR sont également pris en charge.

Questions fréquemment posées

Le patient doit-il être à la clinique ?

Non. Il peut approuver depuis son propre téléphone ou via le lien par e-mail, où qu'il soit. Une demande peut donc être envoyée avant le rendez-vous, et un patient qui est à l'étranger peut toujours l'approuver.

Et si le patient n'a pas de compte Anpheros ?

La demande est acceptée puis expire sans décision, et la clinique ne peut pas savoir si un compte existe. Le patient peut créer un compte et la clinique peut envoyer une nouvelle demande.

Combien de temps dure l'accès ?

Le patient choisit 30, 90 ou 365 jours lorsqu'il approuve. Il peut le retirer plus tôt.

La clinique peut-elle tout voir dans le dossier ?

Uniquement la portée que le patient a approuvée. Les portées sont définies par type de ressource et par action, et peuvent être filtrées par catégorie.

Le flux de demande est-il standard ?

Oui. Il s'agit d'OpenID Connect CIBA, donc les bibliothèques OAuth existantes peuvent être utilisées. Voir le guide API de santé avec consentement du patient pour le modèle plus large.

Est-ce en production ?

Oui, sur la plateforme en beta privée. L'accès en production nécessite une organisation vérifiée et un accord de traitement des données signé.

Liens connexes

• Une plateforme de données patient pour les cliniques et les hôpitaux
• Plateforme de consentement patient pour les applications de santé
• Comment implémenter le consentement patient avec SMART on FHIR
• Sécurité, confidentialité et résidence des données

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card