SMART Permission Tickets, published by . This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/jmandel/smart-permission-tickets-wip/ and changes regularly. See the Directory of published versions

Quickstart: Data Holders

This page tells you what to build for one role. It is non-normative; the specification governs. Read it to scope the work, then implement against the normative sections it links to.

You are adding one grant type to your existing SMART-on-FHIR token endpoint. No new endpoints, no user-facing screens.

1. Accept token exchange. Handle grant_type=urn:ietf:params:oauth:grant-type:token-exchange with a subject_token_type of https://smarthealthit.org/token-type/permission-ticket. Advertise both in .well-known/smart-configuration, along with the ticket_type URIs you accept. (Transport)
2. Authenticate the client exactly as you already do for SMART Backend Services or UDAP. The ticket never replaces client authentication. (Trust and Client Registration)
3. Validate the ticket through the pipeline: signature against the issuer's published JWKS, issuer trust for this ticket type, exp/aud, revocation check, presenter binding, identity evidence, access constraints (reject any you cannot enforce), subject resolution. Implement it as written — the step order matters for correct error responses. (Server-Side Validation)
4. Resolve the subject to one local patient record from subject.patient demographics, corroborated by identity evidence when present. Zero or multiple matches → reject with invalid_grant. (Subject Resolution)
5. Issue a scoped access token: the intersection of requested scopes, the ticket's access, client eligibility, ticket-type rules, and your own policy. Enforce data_period by applying each resource type's designated date search parameter as an implicit filter — searches your server already supports. (Access Calculation, Data Period Enforcement)
6. Configure trusted issuers per ticket type. Trusting an issuer for patient self-access does not trust it for delegated access.

Start with patient self access: it has no requester, no profile claims, and a single policy question — can you match the patient. The conformance section is your checklist, Access Constraints defines what you enforce, and the signed examples are your test vectors.