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

Future Use Cases

These use cases are not part of the near-term implementable catalog. Most are sketches: their ticket_type URIs are reserved, their field lists are unsettled, and each has unresolved questions. Public Health Investigation is the exception — fully modeled and deferred, not unfinished. They are kept here so the work is not lost, and to keep the Use Case Catalog focused on what implementers on the project are ready to build.

Public Health Investigation

Status: Modeled — moved here from the active catalog in June 2026 to keep near-term focus on the flows implementers on the project are ready to exercise. The profile below is complete; a worked tuberculosis follow-up example for review with the public health work group is in progress.

Purpose

A Hospital creates a Case Report. The Public Health Agency (PHA) uses a ticket to query for follow-up data.

Public health follow-up is well suited to ticket-based exchange: the requester is an organization, the request is tied to a concrete triggering event (a reportable condition), and the Data Holder can decide from the ticket alone — no user needs to sign in.

In many jurisdictions, law already requires providers to respond to these queries. A ticket does not add a new gate on top of that obligation, and its absence does not create a right to refuse a legally mandated query. The ticket's job is to make compliance cheaper: it gives the responding system a verifiable, well-scoped request it can act on without a phone call.

Typical Flow

A reportable event triggers case reporting → the issuer (which may be the reporting system or network infrastructure) mints a ticket naming the public health agency as requester, with the reportable condition as a profile claim → the agency's system presents the ticket during follow-up → the Data Holder evaluates the request against its public-health disclosure policies.

Required Claims

• Subject: Patient (matched by demographics or identifier).
• Requester: Organization (public health agency), identified well enough for directory matching (name, identifiers).
• Profile claims: reportable_condition (coded condition), a top-level claim — says which investigation the request belongs to.
• Access: smart_scopes required; data_period and data_holder_filter optional.
• Presenter binding: Optional (B2B; aud + client authentication provide the trust boundary).

Policy Selection Inputs

Data Holder Processing

• Verify issuer trust for this ticket type — trusting an issuer for patient self-access does not imply trusting it for public health tickets.
• Match the requesting organization against directory or trust-framework information.
• Apply local public-health disclosure policy; narrow or reject requests that go beyond the named condition. The legal basis for disclosure lives in applicable law, the trust framework, and local policy — the ticket carries the request, not the mandate.

Example

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

{
  "iss": "https://issuer.state.example.gov",
  "aud": "https://network.org",
  "aud_type": "trust_framework",
  "exp": 1782333550,
  "iat": 1782329950,
  "jti": "uc3-16ff62cf-2d2d-4b30-8c86-6a13d7ab7d16",
  "ticket_type": "https://smarthealthit.org/permission-ticket-type/public-health-investigation-v1",
  "presenter_binding": {
    "method": "trust_framework_client",
    "trust_framework": "https://state.example.gov/trust-framework/public-health",
    "framework_type": "udap",
    "entity_uri": "https://state.example.gov/organizations/epi-unit"
  },
  "subject": {
    "patient": {
      "resourceType": "Patient",
      "identifier": [
        {
          "system": "http://hospital.example.org/mrn",
          "value": "M445566"
        }
      ],
      "birthDate": "1978-02-21",
      "name": [
        {
          "family": "Carter",
          "given": [
            "Monica"
          ]
        }
      ]
    }
  },
  "requester": {
    "resourceType": "Organization",
    "identifier": [
      {
        "system": "urn:ietf:rfc:3986",
        "value": "https://state.example.gov/organizations/epi-unit"
      }
    ],
    "name": "State Epidemiology Unit"
  },
  "access": {
    "smart_scopes": [
      "patient/Condition.rs",
      "patient/Observation.rs",
      "patient/DiagnosticReport.rs"
    ],
    "data_period": {
      "start": "2025-12-01",
      "end": "2026-06-01"
    },
    "data_holder_filter": [
      {
        "kind": "jurisdiction",
        "address": {
          "country": "US",
          "state": "TX"
        }
      }
    ]
  },
  "reportable_condition": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "840539006",
        "display": "Disease caused by severe acute respiratory syndrome coronavirus 2 (disorder)"
      }
    ]
  }
}

eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL2lzc3Vlci5zdGF0ZS5leGFtcGxlLmdvdiIsImF1ZCI6Imh0dHBzOi8vbmV0d29yay5vcmciLCJhdWRfdHlwZSI6InRydXN0X2ZyYW1ld29yayIsImV4cCI6MTc4MjMzMzU1MCwiaWF0IjoxNzgyMzI5OTUwLCJqdGkiOiJ1YzMtMTZmZjYyY2YtMmQyZC00YjMwLThjODYtNmExM2Q3YWI3ZDE2IiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcHVibGljLWhlYWx0aC1pbnZlc3RpZ2F0aW9uLXYxIiwicHJlc2VudGVyX2JpbmRpbmciOnsibWV0aG9kIjoidHJ1c3RfZnJhbWV3b3JrX2NsaWVudCIsInRydXN0X2ZyYW1ld29yayI6Imh0dHBzOi8vc3RhdGUuZXhhbXBsZS5nb3YvdHJ1c3QtZnJhbWV3b3JrL3B1YmxpYy1oZWFsdGgiLCJmcmFtZXdvcmtfdHlwZSI6InVkYXAiLCJlbnRpdHlfdXJpIjoiaHR0cHM6Ly9zdGF0ZS5leGFtcGxlLmdvdi9vcmdhbml6YXRpb25zL2VwaS11bml0In0sInN1YmplY3QiOnsicGF0aWVudCI6eyJyZXNvdXJjZVR5cGUiOiJQYXRpZW50IiwiaWRlbnRpZmllciI6W3sic3lzdGVtIjoiaHR0cDovL2hvc3BpdGFsLmV4YW1wbGUub3JnL21ybiIsInZhbHVlIjoiTTQ0NTU2NiJ9XSwiYmlydGhEYXRlIjoiMTk3OC0wMi0yMSIsIm5hbWUiOlt7ImZhbWlseSI6IkNhcnRlciIsImdpdmVuIjpbIk1vbmljYSJdfV19fSwicmVxdWVzdGVyIjp7InJlc291cmNlVHlwZSI6Ik9yZ2FuaXphdGlvbiIsImlkZW50aWZpZXIiOlt7InN5c3RlbSI6InVybjppZXRmOnJmYzozOTg2IiwidmFsdWUiOiJodHRwczovL3N0YXRlLmV4YW1wbGUuZ292L29yZ2FuaXphdGlvbnMvZXBpLXVuaXQifV0sIm5hbWUiOiJTdGF0ZSBFcGlkZW1pb2xvZ3kgVW5pdCJ9LCJhY2Nlc3MiOnsic21hcnRfc2NvcGVzIjpbInBhdGllbnQvQ29uZGl0aW9uLnJzIiwicGF0aWVudC9PYnNlcnZhdGlvbi5ycyIsInBhdGllbnQvRGlhZ25vc3RpY1JlcG9ydC5ycyJdLCJkYXRhX3BlcmlvZCI6eyJzdGFydCI6IjIwMjUtMTItMDEiLCJlbmQiOiIyMDI2LTA2LTAxIn0sImRhdGFfaG9sZGVyX2ZpbHRlciI6W3sia2luZCI6Imp1cmlzZGljdGlvbiIsImFkZHJlc3MiOnsiY291bnRyeSI6IlVTIiwic3RhdGUiOiJUWCJ9fV19LCJyZXBvcnRhYmxlX2NvbmRpdGlvbiI6eyJjb2RpbmciOlt7InN5c3RlbSI6Imh0dHA6Ly9zbm9tZWQuaW5mby9zY3QiLCJjb2RlIjoiODQwNTM5MDA2IiwiZGlzcGxheSI6IkRpc2Vhc2UgY2F1c2VkIGJ5IHNldmVyZSBhY3V0ZSByZXNwaXJhdG9yeSBzeW5kcm9tZSBjb3JvbmF2aXJ1cyAyIChkaXNvcmRlcikifV19fQ.vYPLsCBodcPjwMpu4wDu4gtvotqOrDrm0BsnTe6kDmw_lKvGt0EA5V2_KgFLVXBdxNa0_AXkylnIg9SQEmpm3A

Social Care (CBO) Referral

A community-based organization accesses referral-related data; a food bank volunteer updates a referral status.

Sketch: requester is an Organization (social care hub or CBO); profile claims carry the coded concern and the referral (ServiceRequest); access could include create/update interactions for referral status — though letting an outside organization write into the record raises governance questions that read-only access does not.

Research Study

A research organization retrieves records for a study participant without the researcher becoming a user at the hospital.

Sketch: requester is an Organization (research institute); a study profile claim identifies the governing ResearchStudy. The ticket would say which study this is and that the issuer verified the study's required workflow — participant consent, an approved waiver, or whatever the study and trust framework require. The base ticket does not try to model research authorization in general; this becomes viable where study governance is concrete and verifiable.

Provider-to-Provider Consult — parked

A specialist requests data from a referring provider.

Parked, not just immature: the natural issuer here is the referring provider's system — the same system the specialist would query — and a system that can mint a ticket for itself can simply grant access directly. Until someone shows where a signed, portable artifact adds value in this flow, this use case is on hold.

Three basics are unsettled. Who is the requester? Referrals usually go to an organization, and nobody knows which specialist will pick up the consult when the ticket would be minted. Who mints the ticket? The obvious issuer is the referring provider's system — but that is the same system the specialist will query. Can EHRs apply the right policy? An outside specialist has no user account at the referring system, and vendors say they treat that case as generic B2B trust today.