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

Use Case Catalog

This page is the registry of Permission Ticket use cases. Each use case maps to a single ticket_type URI that identifies the ticket's schema and processing rules. The base protocol — transport, validation pipeline, access calculation — is defined on the main specification page; each ticket type has its own page defining what it requires and how a Data Holder processes it.

This specification currently defines four ticket types:

Use Case	ticket_type URI
Patient Self Access	https://smarthealthit.org/permission-ticket-type/patient-self-access-v1
Patient-Delegated Access	https://smarthealthit.org/permission-ticket-type/patient-delegated-access-v1
Payer Claims Adjudication	https://smarthealthit.org/permission-ticket-type/payer-claims-adjudication-v1
Payer Quality Gap Queries	https://smarthealthit.org/permission-ticket-type/payer-quality-gap-v1

Ticket types are identified by their ticket_type URIs and referred to by name. Public Health Investigation is fully modeled but has lived on Future Use Cases since June 2026, alongside the other candidates; the near-term catalog holds the flows implementers on the project are ready to exercise.

Status

Status	Meaning
Ready	The underlying workflow is real today; ready for first implementations.
Modeled	Fields and processing rules are drafted in detail, but no real-world deployments exercise this flow yet.

Patient Self Access is Ready; the other three ticket types are Modeled.

Per-Profile Constraints

The table below summarizes required and optional fields for each ticket type. Each profile pulls in the access constraints it needs; the Constraints section on each profile's page states which it draws and where the values come from.

Use Case	presenter_binding	Requester	Identity Evidence	Access Constraints
Patient Self Access	Required	—	subject_identity_evidence SHOULD	smart_scopes required; data_period, data_holder_filter optional
Patient-Delegated Access	Required	RelatedPerson (required)	subject_identity_evidence SHOULD; requester_identity_evidence SHOULD	smart_scopes required; data_period, data_holder_filter optional
Payer Claims Adjudication	Optional	Organization (required)	— (requester is an organization)	claim_linkage required (encounter-anchored)
Payer Quality Gap Queries	Optional	Organization (required)	— (requester is an organization)	smart_scopes (every scope narrowed), data_period required

The Identity Evidence column applies the base rule from Identity Evidence — evidence accompanies each natural person whose verified identity is the basis of the grant; per-type detail lives on each profile page.

Each profile page follows a common template, including Policy Selection Inputs. ticket_type tells the Data Holder what kind of request this is (self-access, proxy access, claims review, …); the inputs listed per use case are the ticket fields that help it pick the right one of its own internal policies for this request. Tickets help the Data Holder pick a policy; they do not create new policies or override existing ones.