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

Payer Claims Adjudication

This page defines one Permission Ticket type. The overview of all types is the Use Case Catalog; constraint definitions live on Access Constraints.

Status: Modeled

Purpose

A provider's system submits a claim and attaches a Permission Ticket. The payer presents the ticket back at the provider's own FHIR endpoint to read clinical data tied to the claim.

When a payer needs more than the claim itself — medical-necessity review, a request for additional information, post-submission documentation — today's path is document exchange: the payer guesses a document code, the provider assembles and pushes attachments. A ticket attached to the claim replaces that follow-up loop with a scoped read. The provider knows at submission time exactly which patient, which encounters, and which period the claim concerns, so it can mint the grant itself.

The issuer and the Data Holder are the same party. This is the ticket type with the fewest moving parts — one system mints tickets and later accepts them back — and trust validation is correspondingly simple. The signature still matters: the ticket travels through the payer's claims pipeline, and only an authenticated client the provider accepts as acting for the requester can redeem it.

CMS's Interoperability Framework names this flow among its criteria for aligned networks: "Payers, including CMS, can query for relevant data tied to a claim submitted in the last 60 days and receive clinical data for that encounter." The criterion names the goal and leaves the mechanism open; this profile is a candidate mechanism.

Typical Flow

Provider's system submits a claim (or prior authorization) → mints a ticket naming the payer as requester and linking the claim → the ticket travels with the submission (in an X12 275 attachment, a CDex Task, or by reference — tickets are a capability other exchange flows carry, and this profile does not pick the vehicle) → during adjudication, the payer's system presents the ticket at the provider's token endpoint → the provider validates its own signature, checks presenter binding, and issues an access token limited to records associated with the claim.

Required Claims

• Subject: Patient, with subject.recipient_record SHOULD — the issuer is the Data Holder, so it knows its own record identifier and the direct-target hint always resolves.
• Requester: Organization (the payer), identified well enough for the provider to match it to the claim's payer.
• Presenter binding: Optional (B2B): aud plus client authentication provide the trust boundary. requester identifies the principal, not necessarily the presenter — a contractor adjudicating on the payer's behalf may redeem with its own registered client when the delegation is tracked through registration or expressed in the trust framework (OpenID Federation can carry it explicitly). See the base specification on this distinction.
• Expiration: exp SHOULD cover the payer's documented additional-information window for the linked claim. Sixty days from submission matches the CMS criterion; the operational windows underneath run 45–75 days (Medicare ADR, PERM, commercial record-request periods), so the length is a deployment parameter, not a fixed rule.

Constraints

Draws from the constraint catalog. The authorizing party is the provider organization, disclosing under HIPAA's payment and operations permission — there is no patient authorization ceremony, but the patient's standing restriction rights bind (see Restricted Data).

• claim_linkage (required) — this profile's required bound on release: the encounters the submitted claim or prior authorization covers, optionally re-associated to the submission by the provider's own claim control number. The Data Holder releases the records it associates with those encounters.

This type carries only claim_linkage — it scopes one adjudication, never bulk retrieval; element-specific quality queries are Payer Quality Gap Queries, and chart-scale retrieval is out of scope for both. There is no smart_scopes ceiling: the linked encounters are the bound, and the Data Holder releases the resource types adjudication needs against them. That set is likely broader than US Core for some claim types — Claim, Coverage, and documentation resources are typical candidates — and which types to release is the Data Holder's release-policy decision, not a scope list in the ticket. data_period is not part of this type, and issuers SHALL NOT include it: the encounters are this type's time anchor — they bound event records, and the patient-level floor is deliberately current-state — so any data_period value is either redundant (inside the encounter bounds) or contradictory (cutting current medications out of the floor). data_holder_filter is likewise not part of this type: the audience is the single issuing Data Holder. Cross-cutting constraints defined elsewhere in the catalog, such as sensitivity_withhold, MAY be added, with the standard consequence for servers that do not enforce them.

Restricted Data

• Records restricted from disclosure to the payer are excluded silently. The base rule already covers this — a valid ticket does not override local rules — and the issuer is the Data Holder, which holds its own restriction flags. The leading case is the HIPAA right to restrict (45 CFR 164.522(a)(1)(vi)): a provider must honor a patient's request not to disclose to a health plan information about items or services paid out of pocket in full.
• The payer is told the response may be lawfully incomplete (see the claim_linkage constraint's "For the client" note). The payer must not treat a filtered response as the complete record.
• When the patient has authorized disclosure of restricted items to the plan, the ticket says so explicitly: a sensitivity_release_authorized claim per Proposal 005, using the v3-ActCode HIPAASelfPay security label policy code — never a silent widening of the default.

Policy Selection Inputs

Data Holder Processing

• Verify the ticket signature against this system's own issuing keys — the issuer is the Data Holder.
• Confirm the redeeming client acts for the requester — by presenter binding when present, or by the client's registration or trust-framework relationship to the named payer.
• Resolve the subject; recipient_record resolves directly, since the issuer assigned it.
• Enforce claim_linkage against the records you associate with the linked encounters; apply restriction flags before release.

Example

{
  "alg": "ES256",
  "kid": "nvOGRCsTz2QIQLsbl0ZQ_ux0tfyh5iave-jvNsANWv8"
}

{
  "iss": "https://fhir.provider.example.org",
  "aud": "https://fhir.provider.example.org",
  "aud_type": "data_holder_url",
  "exp": 1787513950,
  "iat": 1782329950,
  "jti": "uc5-2f9a7c11-5d28-4e6b-9b54-3c1f8a02d977",
  "ticket_type": "https://smarthealthit.org/permission-ticket-type/payer-claims-adjudication-v1",
  "presenter_binding": {
    "method": "trust_framework_client",
    "trust_framework": "https://directory.example-network.org",
    "framework_type": "udap",
    "entity_uri": "https://payer.example.com/organizations/claims-review"
  },
  "subject": {
    "patient": {
      "resourceType": "Patient",
      "identifier": [
        {
          "system": "http://fhir.provider.example.org/mrn",
          "value": "B77421"
        }
      ],
      "birthDate": "1962-03-09",
      "name": [
        {
          "family": "Okafor",
          "given": [
            "Daniel"
          ]
        }
      ]
    },
    "recipient_record": {
      "reference": "https://fhir.provider.example.org/Patient/B77421",
      "type": "Patient"
    }
  },
  "requester": {
    "resourceType": "Organization",
    "identifier": [
      {
        "system": "http://hl7.org/fhir/sid/us-npi",
        "value": "1093817465"
      }
    ],
    "name": "Example Health Plan"
  },
  "access": {
    "claim_linkage": {
      "encounter": [
        {
          "reference": "https://fhir.provider.example.org/Encounter/enc-2026-0117"
        }
      ]
    }
  }
}

eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL2ZoaXIucHJvdmlkZXIuZXhhbXBsZS5vcmciLCJhdWQiOiJodHRwczovL2ZoaXIucHJvdmlkZXIuZXhhbXBsZS5vcmciLCJhdWRfdHlwZSI6ImRhdGFfaG9sZGVyX3VybCIsImV4cCI6MTc4NzUxMzk1MCwiaWF0IjoxNzgyMzI5OTUwLCJqdGkiOiJ1YzUtMmY5YTdjMTEtNWQyOC00ZTZiLTliNTQtM2MxZjhhMDJkOTc3IiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcGF5ZXItY2xhaW1zLWFkanVkaWNhdGlvbi12MSIsInByZXNlbnRlcl9iaW5kaW5nIjp7Im1ldGhvZCI6InRydXN0X2ZyYW1ld29ya19jbGllbnQiLCJ0cnVzdF9mcmFtZXdvcmsiOiJodHRwczovL2RpcmVjdG9yeS5leGFtcGxlLW5ldHdvcmsub3JnIiwiZnJhbWV3b3JrX3R5cGUiOiJ1ZGFwIiwiZW50aXR5X3VyaSI6Imh0dHBzOi8vcGF5ZXIuZXhhbXBsZS5jb20vb3JnYW5pemF0aW9ucy9jbGFpbXMtcmV2aWV3In0sInN1YmplY3QiOnsicGF0aWVudCI6eyJyZXNvdXJjZVR5cGUiOiJQYXRpZW50IiwiaWRlbnRpZmllciI6W3sic3lzdGVtIjoiaHR0cDovL2ZoaXIucHJvdmlkZXIuZXhhbXBsZS5vcmcvbXJuIiwidmFsdWUiOiJCNzc0MjEifV0sImJpcnRoRGF0ZSI6IjE5NjItMDMtMDkiLCJuYW1lIjpbeyJmYW1pbHkiOiJPa2Fmb3IiLCJnaXZlbiI6WyJEYW5pZWwiXX1dfSwicmVjaXBpZW50X3JlY29yZCI6eyJyZWZlcmVuY2UiOiJodHRwczovL2ZoaXIucHJvdmlkZXIuZXhhbXBsZS5vcmcvUGF0aWVudC9CNzc0MjEiLCJ0eXBlIjoiUGF0aWVudCJ9fSwicmVxdWVzdGVyIjp7InJlc291cmNlVHlwZSI6Ik9yZ2FuaXphdGlvbiIsImlkZW50aWZpZXIiOlt7InN5c3RlbSI6Imh0dHA6Ly9obDcub3JnL2ZoaXIvc2lkL3VzLW5waSIsInZhbHVlIjoiMTA5MzgxNzQ2NSJ9XSwibmFtZSI6IkV4YW1wbGUgSGVhbHRoIFBsYW4ifSwiYWNjZXNzIjp7ImNsYWltX2xpbmthZ2UiOnsiZW5jb3VudGVyIjpbeyJyZWZlcmVuY2UiOiJodHRwczovL2ZoaXIucHJvdmlkZXIuZXhhbXBsZS5vcmcvRW5jb3VudGVyL2VuYy0yMDI2LTAxMTcifV19fX0.TH8BAEw0H1BBuF8cVwv2xFwVS8nuqM_egrTgvJo-aGNRY5ldRhVQhSw6aoOhzQUECd8tkbg0nqZisnZu6UpO1Q