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

Plateforme de consentement patient pour applications de santé

Le consentement intégré à la couche de données : scopes OAuth 2.1 et SMART, objectif et expiration choisis par la personne, journal d'accès consultable, révocation à la prochaine requête, et ce que votre application conserve.

Une plateforme de consentement patient permet à une personne de décider quelles applications peuvent lire ou modifier son dossier de santé, dans quel but et pendant combien de temps, et lui permet de consulter et de révoquer cet accès à tout moment. Anpheros intègre le consentement à la couche de données : une application n'accède au dossier FHIR R4 d'un patient qu'à travers une autorisation approuvée par la personne sur la page de consentement Anpheros, chaque lecture et écriture sous cette autorisation est enregistrée là où la personne peut la consulter, et la révocation prend effet à la prochaine requête. Cette page montre comment cela fonctionne, ce que votre application doit faire, et ce qu'elle n'a pas besoin de construire.

How one consent works, end to end

1 · Your app asksOAuth 2.1 with PKCE: SMART scopes, a purpose and the patient's language
2 · The person decidesOn the Anpheros consent page: what, for whom and for how long — 30, 90, 180 or 365 days
3 · Your app readsOne patient's record, only the granted resource types and categories
4 · Every access is loggedThe person sees each read and write by your application
5 · The person revokesThe next request fails; a refresh token cannot bring access back

Pourquoi le consentement appartient à la couche de données

La plupart des applications de santé enregistrent le consentement sous forme de case à cocher dans leur propre base de données, puis l'appliquent dans le code de l'application. Cela fonctionne jusqu'à ce qu'une deuxième application, une intégration de clinique ou une fonctionnalité d'IA ait besoin des mêmes données : chacune doit réimplémenter les règles, et la personne n'a pas d'endroit unique pour voir qui a accès. Lorsque la plateforme qui stocke l'enregistrement applique également le consentement, chaque client bénéficie des mêmes règles et la personne obtient une liste d'applications à examiner.

	Consentement comme indicateur dans votre application	Consentement dans la couche de données (Anpheros)
Où il est appliqué	Dans le code de chaque application	Sur chaque requête API, par la plateforme
Portée de l'accès	Ce que l'application décide de lire	Uniquement les types de ressources et les catégories accordés
Expiration	Rarement implémenté	Choisi par la personne : 30, 90, 180 ou 365 jours
Ce que la personne voit	Dépend de l'application	Chaque application, sa portée et son expiration, et un journal d'accès
Révocation	Doit être propagée manuellement	La prochaine requête échoue ; le jeton de rafraîchissement cesse de fonctionner

Ce que le patient contrôle

What the patient controls

WhoEach application is listed by name with its own grant

WhatResource types and categories, e.g. only laboratory Observations

WhyThe purpose your app declares is shown on the consent page

How long30, 90, 180 or 365 days; access ends by itself

What happenedAn access log of every read and write under the grant

StopRevocation takes effect on the next request

Comment votre application demande le consentement

Anpheros utilise OAuth 2.1 avec PKCE et les scopes SMART on FHIR v2. Votre application redirige la personne vers la page de consentement avec les scopes dont elle a besoin et un objectif optionnel ; après approbation, elle reçoit un jeton d'accès (30 minutes) et un jeton de rafraîchissement rotatif (30 jours) pour un seul patient.

import { OAuthFlow, generatePkce } from '@anpheros/sdk';

const flow = new OAuthFlow({
  baseUrl: 'https://platform.anpheros.com',
  clientId: process.env.ANPHEROS_CLIENT_ID!,
  redirectUri: 'https://your.app/callback',
});
const pkce = await generatePkce();
const url = flow.authorizeUrl({
  scopes: ['patient/Observation.rs?category=laboratory', 'patient/Condition.rs', 'offline_access'],
  purpose: 'treatment',
  state: crypto.randomUUID(),
  pkce,
  lang: 'en',
});
// redirect the person to `url`; on the callback exchange the code (see the authentication guide)

Un scope tel que patient/Observation.rs?category=laboratory limite la lecture aux résultats de laboratoire ; le filtre de catégorie est appliqué par le serveur. Un type de ressource en dehors de l'autorisation renvoie 403 ; un patient en dehors de l'autorisation renvoie 404, de sorte que les identifiants ne peuvent pas être sondés.

Réagir à la révocation

Lorsque la personne met fin à une autorisation, la prochaine requête avec ce token échoue et le refresh token ne peut pas rétablir l'accès. Pour nettoyer immédiatement, abonnez-vous au webhook consent.revoked, qui transporte le grant_id, l'identifiant du patient que vous voyez, les scopes et revoked_at.

await anpheros.webhooks.create('https://your.app/anpheros/hook', { events: ['consent.granted', 'consent.revoked'] });

Ce que Anpheros ne fait pas

Il ne collecte pas de consentement pour des finalités autres que l'accès aux données, telles que le marketing ou la participation à la recherche.
Il ne détermine pas votre base légale. Le consentement d'accès est un contrôle ; votre avis de confidentialité, vos contrats et vos registres de traitement restent les vôtres.
La clé API d'un projet voit les patients que ce projet a créés, sans autorisation. Le consentement régit l'accès par d'autres applications.

Foire aux questions

Qu'est-ce qu'une plateforme de consentement patient ?

Un logiciel qui enregistre quelles applications une personne autorise à accéder à ses données de santé, applique ces choix à chaque requête, montre à la personne qui a accédé à quoi, et lui permet de retirer l'accès. Dans Anpheros, le consentement fait partie de l'enregistrement FHIR R4 lui-même plutôt que d'un service distinct.

Quels standards Anpheros utilise-t-il pour le consentement patient ?

OAuth 2.1 avec PKCE pour le flux d'autorisation et les scopes patient SMART on FHIR v2 (patient/<Type>.<cruds> avec un filtre optionnel ?category=) pour ce qu'une application peut lire ou écrire. OpenID Connect ajoute un ID token lorsque vous demandez openid fhirUser.

Un patient peut-il limiter l'accès à seulement une partie de ses données ?

Oui. L'accès est limité aux types de ressources et aux catégories dans les scopes accordés, par exemple uniquement aux Observations de laboratoire. Tout le reste renvoie une erreur.

Quelle est la durée du consentement ?

La personne choisit 30, 90, 180 ou 365 jours sur la page de consentement. Après cela, la concession expire et l'application doit redemander.

Le patient peut-il voir ce qu'une application a fait avec l'accès ?

Oui. La personne voit chaque application ayant accès, ses scopes et son expiration, ainsi qu'un journal d'accès listant ce que chaque application a lu ou écrit.

Que se passe-t-il lorsque le consentement est révoqué ?

La prochaine requête avec ce token d'accès échoue, le refresh token ne peut pas être utilisé pour en obtenir un nouveau, et votre serveur reçoit un webhook consent.revoked s'il y est abonné.

Liens pertinents

Modèle de consentement et d'accès : les règles dans leur intégralité
Authentification et OAuth : jetons, scopes et échange de code
Comment implémenter le consentement patient avec SMART on FHIR
Webhooks : consent.granted et consent.revoked
Provenance des données médicales expliquée
API de données patient longitudinales

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