SMART on FHIR backend

What Anpheros implements of SMART on FHIR — discovery, standalone launch, PKCE, SMART v2 scopes, OpenID Connect, hosted consent — a launch in five requests, and what is not offered yet.

SMART on FHIR is the standard way an application obtains a user's permission to reach a FHIR record: OAuth 2.0/2.1 for the authorisation, a defined set of scopes for what can be read or written, and a discovery document that tells the application where to go. Anpheros is a SMART on FHIR backend: it hosts the authorisation server, the FHIR R4 server and the consent screen, so a SMART application built for it works with standard libraries and no custom login.

What Anpheros implements

Part of SMART	In Anpheros
Discovery	`/.well-known/smart-configuration` on the FHIR base, with the endpoints, scopes and PKCE methods supported
Launch	standalone launch (the application starts, then asks for access); EHR launch from within a clinical system is not offered
Authorisation	OAuth 2.1 with PKCE required, authorisation code flow
Scopes	SMART v2 patient scopes, `patient/<Resource>.<cruds>`, plus `openid` and `fhirUser`
Identity	an OpenID Connect `id_token` naming the patient as a FHIR resource
Consent	a hosted consent screen in the patient's language, with the duration chosen by the patient
Tokens	short-lived access tokens, refresh tokens bound to the consent, revocation
Conformance	the capability statement declares the SMART security service; the FHIR server passed the Inferno ONC test suite in September 2026

A standalone launch in five requests

1. GET  /fhir/R4/.well-known/smart-configuration
2. GET  {authorization_endpoint}?response_type=code&client_id=…&scope=openid fhirUser patient/Observation.rs&code_challenge=…
3.      the patient accepts on the Anpheros consent screen
4. POST {token_endpoint}   code + code_verifier  →  access_token, refresh_token, id_token, patient
5. GET  /fhir/R4/Observation?patient={patient}   with  Authorization: Bearer …

The patient field in the token response is the pairwise id of the patient for your application. Use it in every query; it is the only id you will see for that person.

Why a backend rather than a library

A SMART client library handles the dance on your side. What it needs on the other side is an authorisation server that knows the patient, a consent screen the patient trusts, scopes enforced on every request and a FHIR server that honours them. Running those yourself means an identity provider, a FHIR server, a policy layer and an audit log, each kept consistent with the others. Anpheros provides them as one service, with the audit visible to the patient and provenance on every write.

Writing through SMART

Write scopes (patient/Observation.c, .u, .d) work the same way. Everything written carries your application as the author. Writes are idempotent when you send an idempotency key, so retries never duplicate a measurement. Deletions are soft and leave history, as the Medical data API guide describes.

What is not there yet

EHR launch (the application opened from inside a hospital system with a launch context).
system/ scopes for backend services; organisations use API keys instead.
Bulk Data export ($export); $everything on a patient is available.

These are listed with the rest in Versioning and deprecation, and the capability statement is always the authoritative source.