Interoperability
SMART Backend Services explained: system-to-system FHIR access
SMART Backend Services is the part of HL7's SMART App Launch guide for software that talks to a FHIR server with no user authorising access at run time. The client registers its public key with the server in advance, then gets a short-lived access token through the OAuth 2.0 client credentials flow, proving who it is with a signed JWT.
When it applies
The specification (SMART App Launch v2.2.0, STU 2.2) says to use it when all of these hold: the FHIR authorisation server can register the client and pre-authorise access to defined resources; the client runs on its own, or with users who aren't the ones authorising access; the client supports asymmetric (public key) authentication; and there's no compelling need for a user to authorise access at run time.
HL7's own examples read like a hospital operations list: a lab monitoring service that sees which patients are admitted, reviews incoming results and raises alerts; a data integration service that picks up newly registered patients; and a utilisation tracker that queries an EHR every minute for bed and room usage and shows it on a wall monitor.
How the flow works
- Register the client with the server once, sharing its public key (this can be done out of band).
- Discover the server's SMART configuration at
.well-known/smart-configuration, which includes the token endpoint. - Get a token: create a one-time authentication JWT signed with the private key and POST it to the token endpoint with
grant_type=client_credentials,client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerand the scopes requested. All exchanges must use TLS 1.2 or later. - Call the FHIR API with the access token until it expires. Refresh tokens should not be issued, so the client simply asks again.
Scopes and least privilege
Backend clients ask for system/ scopes, for example system/Observation.rs to read the Observations the client has been pre-authorised for. The server can refuse a request outside the client's scopes, and can withhold results that other local policies forbid, reporting that some results were withheld. For a hospital this is the point: register each integration as its own client, give it only the resources it needs, and rotate its keys like any other credential.
What it does not mean
- It isn't a user login. Nobody signs in; the client is pre-authorised. If an action needs a person's authority, that has to be handled separately.
- Scopes aren't the whole access decision. The specification lets servers apply further local rules and withhold data even within the granted scopes.
- It isn't only for bulk exports. It is designed to work with FHIR Bulk Data, but can be used with any FHIR endpoint, synchronous or asynchronous.
Where Thalix fits
Thalix's fhir driver supports SMART Backend Services with ES384 keys and private_key_jwt, publishes its keys as a JWKS and can rotate them. By default it requests read-only, least-privilege system/<Type>.rs scopes for the resources it polls, and its probe requests a real token so you can see the requested and granted scopes before go-live. Inside Thalix, people and agents never use that system credential directly: every read goes through the kernel's policy as the person (or agent) asking, and is audited.
Thalix is at pilot stage. Demos run on synthetic data, and a hospital deployment needs its own clinical safety case, information governance approval and security review. We don't claim any certification or assessment result the product doesn't have.
Questions people ask
What is the difference between SMART App Launch and SMART Backend Services?
App Launch is for apps where a user (or patient) authorises access at run time. Backend Services is for software that runs on its own with pre-authorised access and no user authorisation step.
Does SMART Backend Services use refresh tokens?
No. The specification says refresh tokens should not be issued; the client requests a new short-lived access token when it needs one.
What scopes does a backend client request?
System scopes such as system/Observation.rs. The specification doesn't prohibit user/ or patient/ scopes, but using them would need out-of-band agreement about which user or patient applies.
Sources
Each source below is an official page, read and checked in October 2026. Where a page and this guide differ, the official page wins.
- SMART App Launch: Backend Services HL7 · checked October 2026
- FHIR R4 (v4.0.1) HL7 · checked October 2026
General information only, written for hospital digital, IT, operations and clinical safety teams. It isn't legal, regulatory, information governance or clinical safety advice, and it doesn't replace your own organisation's processes or the official guidance linked above.