AnpherosAnpheros PlatformDevelopers

Patient consent platform for health apps

Consent built into the data layer: OAuth 2.1 and SMART scopes, purpose and expiry chosen by the person, an access log they can see, revocation on the next request, and what your app still owns.

A patient consent platform lets a person decide which applications may read or change their health record, for what purpose and for how long, and lets them see and revoke that access at any time. Anpheros builds consent into the data layer: an application reaches a patient's FHIR R4 record only through a grant the person approved on the Anpheros consent page, every read and write under that grant is logged where the person can see it, and revocation takes effect on the next request. This page shows how that works, what your application has to do, and what it does not have to build.

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

Why consent belongs in the data layer

Most health apps record consent as a checkbox in their own database and then enforce it in application code. That works until a second app, a clinic integration or an AI feature needs the same data: each one must re-implement the rules, and the person has no single place to see who has access. When the platform that stores the record also enforces the consent, every client gets the same rules and the person gets one list of applications to review.

Consent as a flag in your app Consent in the data layer (Anpheros)
Where it is enforced In each application's code On every API request, by the platform
Scope of access Whatever the app decides to read Only the granted resource types and categories
Expiry Rarely implemented Chosen by the person: 30, 90, 180 or 365 days
What the person sees Depends on the app Every application, its scopes and expiry, and an access log
Revocation Must be propagated by hand Next request fails; the refresh token stops working

What the patient controls

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

How your application asks for consent

Anpheros uses OAuth 2.1 with PKCE and SMART on FHIR v2 scopes. Your app sends the person to the consent page with the scopes it needs and an optional purpose; after approval it receives an access token (30 minutes) and a rotating refresh token (30 days) for exactly one 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)

A scope such as patient/Observation.rs?category=laboratory limits reading to laboratory results; the category filter is enforced by the server. A resource type outside the grant returns 403; a patient outside the grant returns 404, so ids cannot be probed.

Reacting to revocation

When the person ends a grant, the next request with that token fails and the refresh token cannot bring access back. To clean up straight away, subscribe to the consent.revoked webhook, which carries the grant_id, the patient id you see, the scopes and revoked_at.

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

What Anpheros does not do

Frequently asked questions

What is a patient consent platform?

Software that records which applications a person allows to access their health data, enforces those choices on every request, shows the person who accessed what, and lets them withdraw access. In Anpheros, consent is part of the FHIR R4 record itself rather than a separate service.

Which standards does Anpheros use for patient consent?

OAuth 2.1 with PKCE for the authorization flow and SMART on FHIR v2 patient scopes (patient/<Type>.<cruds> with an optional ?category= filter) for what an application may read or write. OpenID Connect adds an ID token when you ask for openid fhirUser.

Can a patient limit access to only some of their data?

Yes. Access is limited to the resource types and categories in the granted scopes, for example only laboratory Observations. Everything else returns an error.

How long does consent last?

The person chooses 30, 90, 180 or 365 days on the consent page. After that the grant expires and the application must ask again.

Can the patient see what an application did with the access?

Yes. The person sees every application with access, its scopes and expiry, and an access log listing what each application read or wrote.

What happens when consent is revoked?

The next request with that access token fails, the refresh token cannot be used to get a new one, and your server receives a consent.revoked webhook if it subscribed.

Related