SMART Permission Tickets
0.1.0 - ci-build

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; this page defines what each ticket type requires and how a Data Holder processes it.

This specification currently defines three ticket types:

Use Caseticket_type URI
Use Case 1: Patient Self Accesshttps://smarthealthit.org/permission-ticket-type/patient-self-access-v1
Use Case 2: Patient-Delegated Accesshttps://smarthealthit.org/permission-ticket-type/patient-delegated-access-v1
Use Case 3: Public Health Investigationhttps://smarthealthit.org/permission-ticket-type/public-health-investigation-v1

Additional candidates are tracked on Future Use Cases. They are not part of the implementable specification.

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.
Use Case Status
UC1: Patient Self Access Ready
UC2: Patient-Delegated Access Modeled
UC3: Public Health Investigation Modeled

Per-Profile Constraints

The table below summarizes required and optional fields for each ticket type. All ticket types may use any access dimension (permissions, data_period, data_holder_filter); the table notes typical usage.

Use Case presenter_binding Requester Identity Evidence Context Fields Access
UC1: Patient Self Access Required — subject_identity_evidence SHOULD (none) permissions required; data_period optional
UC2: Patient-Delegated Access Required RelatedPerson (required) subject_identity_evidence SHOULD; requester_identity_evidence SHOULD (none) permissions required
UC3: Public Health Optional Organization (required) — (requester is an organization) reportable_condition permissions required; data_period, data_holder_filter typical

Identity evidence principle. Identity evidence SHOULD accompany each individual natural person whose verified identity is the basis of the grant. For UC1 that is the patient (subject_identity_evidence; the patient is also the requester, so it is recorded once). For UC2 that is both parties: the issuer verifies the delegate's identity and the patient's identity and wishes, so both evidence slots SHOULD be populated. B2B ticket types name an organization as requester; organizational trust is institutional and the evidence slots do not apply. Trust frameworks may strengthen SHOULD to SHALL.

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

Use Case 1: Patient Self Access

Status: Ready

Purpose

A patient uses a high-assurance Digital ID wallet to authorize an app to fetch their data from multiple hospitals.

The patient authorizes once, with the issuer, and the ticket carries that authorization to many Data Holders — including Data Holders where the patient has never created a portal account. This is the simplest ticket type: no third-party requester and no context fields.

Typical Flow

Patient completes identity verification and authorization with the issuer → issuer mints a presenter-bound ticket → the patient's app presents the ticket at each Data Holder via token exchange → each Data Holder resolves the patient locally and issues a scoped access token.

Required Claims

  • Subject: Patient (matched by demographics: name, DOB, identifiers), with subject_identity_evidence SHOULD — an embedded identity token the Data Holder can verify itself.
  • Requester: None (self-access). The absence of requester is what marks the ticket as self-access. The patient is the requester, so identity is recorded once, on the subject side.
  • Context: (none; context may be omitted or empty)
  • Access: permissions with specific resource types and interactions; data_period optional.
  • Presenter binding: Required. Individual-access tickets must be bound to the presenting client.

Identity Evidence

The patient's verified identity is the basis of this grant, so the ticket SHOULD carry subject_identity_evidence: the high-assurance identity token (for example, an IAL2 ID token) from the issuer's verification step, embedded so the Data Holder can check the identity claims itself instead of taking the issuer's word for them. How to verify the embedded token is defined in the base specification; this profile expects IAL2-grade assurance and enough demographics to match the patient. Trust frameworks MAY require the embedded token; subject.patient is present either way.

Policy Selection Inputs

One policy applies here: the Data Holder's patient self-access policy — the patient sees what they would see through the Data Holder's own patient-facing access. The only question the ticket fields answer is whether the Data Holder can confidently match the patient (subject.patient, strengthened by subject_identity_evidence when present).

Data Holder Processing

  • Resolve the subject to a local patient record; reject with invalid_grant on zero or ambiguous matches. Deployments that support an interactive fallback for subject disambiguation may use Proposal 001.
  • A valid ticket does not override local rules such as result-release holds or portal access restrictions.
  • Grant access scoped by the intersection rules of the base specification.

What This Ticket Does Not Prove

  • That the patient has (or ever had) an account or care relationship at the Data Holder.
  • That every requested data category is releasable under the Data Holder's local policy and applicable law.

Example

Permission Ticket Artifact

Header
{
  "alg": "ES256",
  "kid": "nvOGRCsTz2QIQLsbl0ZQ_ux0tfyh5iave-jvNsANWv8"
}
Payload (Claims)
{
  "iss": "https://trusted-issuer.org",
  "aud": "https://network.org",
  "aud_type": "trust_framework",
  "exp": 1781065466,
  "iat": 1781061866,
  "jti": "uc1-4b33cc1d-0f6b-44bf-bd33-80f6d7140f3e",
  "ticket_type": "https://smarthealthit.org/permission-ticket-type/patient-self-access-v1",
  "presenter_binding": {
    "method": "jkt",
    "jkt": "JuI6ibZHcMPQICaIZ55PbXpnsudQmKt00D0BiEXNrMc"
  },
  "subject": {
    "patient": {
      "resourceType": "Patient",
      "identifier": [
        {
          "system": "http://hospital.example.org/mrn",
          "value": "A12345"
        }
      ],
      "birthDate": "1989-09-14",
      "name": [
        {
          "family": "Reyes",
          "given": [
            "Elena"
          ]
        }
      ]
    }
  },
  "access": {
    "permissions": [
      {
        "kind": "data",
        "resource_type": "AllergyIntolerance",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "Condition",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "Observation",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "MedicationRequest",
        "interactions": [
          "read",
          "search"
        ]
      }
    ],
    "data_period": {
      "start": "2021-01-01",
      "end": "2026-01-01"
    }
  }
}
Raw Signed JWT 
eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL3RydXN0ZWQtaXNzdWVyLm9yZyIsImF1ZCI6Imh0dHBzOi8vbmV0d29yay5vcmciLCJhdWRfdHlwZSI6InRydXN0X2ZyYW1ld29yayIsImV4cCI6MTc4MTA2NTQ2NiwiaWF0IjoxNzgxMDYxODY2LCJqdGkiOiJ1YzEtNGIzM2NjMWQtMGY2Yi00NGJmLWJkMzMtODBmNmQ3MTQwZjNlIiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcGF0aWVudC1zZWxmLWFjY2Vzcy12MSIsInByZXNlbnRlcl9iaW5kaW5nIjp7Im1ldGhvZCI6ImprdCIsImprdCI6Ikp1STZpYlpIY01QUUlDYUlaNTVQYlhwbnN1ZFFtS3QwMEQwQmlFWE5yTWMifSwic3ViamVjdCI6eyJwYXRpZW50Ijp7InJlc291cmNlVHlwZSI6IlBhdGllbnQiLCJpZGVudGlmaWVyIjpbeyJzeXN0ZW0iOiJodHRwOi8vaG9zcGl0YWwuZXhhbXBsZS5vcmcvbXJuIiwidmFsdWUiOiJBMTIzNDUifV0sImJpcnRoRGF0ZSI6IjE5ODktMDktMTQiLCJuYW1lIjpbeyJmYW1pbHkiOiJSZXllcyIsImdpdmVuIjpbIkVsZW5hIl19XX19LCJhY2Nlc3MiOnsicGVybWlzc2lvbnMiOlt7ImtpbmQiOiJkYXRhIiwicmVzb3VyY2VfdHlwZSI6IkFsbGVyZ3lJbnRvbGVyYW5jZSIsImludGVyYWN0aW9ucyI6WyJyZWFkIiwic2VhcmNoIl19LHsia2luZCI6ImRhdGEiLCJyZXNvdXJjZV90eXBlIjoiQ29uZGl0aW9uIiwiaW50ZXJhY3Rpb25zIjpbInJlYWQiLCJzZWFyY2giXX0seyJraW5kIjoiZGF0YSIsInJlc291cmNlX3R5cGUiOiJPYnNlcnZhdGlvbiIsImludGVyYWN0aW9ucyI6WyJyZWFkIiwic2VhcmNoIl19LHsia2luZCI6ImRhdGEiLCJyZXNvdXJjZV90eXBlIjoiTWVkaWNhdGlvblJlcXVlc3QiLCJpbnRlcmFjdGlvbnMiOlsicmVhZCIsInNlYXJjaCJdfV0sImRhdGFfcGVyaW9kIjp7InN0YXJ0IjoiMjAyMS0wMS0wMSIsImVuZCI6IjIwMjYtMDEtMDEifX19.Acc-5IkzHnn_DX830sIYBjfYLM67YxtnsYMC4B9Om2Dxm8BW9uwwhN0DmErhtudS8QeNwAZbjBmiWKw2e_872g
Variant: with identity evidence

The same ticket carrying subject_identity_evidence. The embedded ID token's demographics match subject.patient, and its aud names the ticket issuer's client at the evidence issuer:

Permission Ticket Artifact

Header
{
  "alg": "ES256",
  "kid": "nvOGRCsTz2QIQLsbl0ZQ_ux0tfyh5iave-jvNsANWv8"
}
Payload (Claims)
{
  "iss": "https://trusted-issuer.org",
  "aud": "https://network.org",
  "aud_type": "trust_framework",
  "exp": 1781065466,
  "iat": 1781061866,
  "jti": "uc1-ev-9f1c2b6a-3a77-4d09-9c4e-5a0d2f81c3b7",
  "ticket_type": "https://smarthealthit.org/permission-ticket-type/patient-self-access-v1",
  "presenter_binding": {
    "method": "jkt",
    "jkt": "JuI6ibZHcMPQICaIZ55PbXpnsudQmKt00D0BiEXNrMc"
  },
  "subject": {
    "patient": {
      "resourceType": "Patient",
      "identifier": [
        {
          "system": "http://hospital.example.org/mrn",
          "value": "A12345"
        }
      ],
      "birthDate": "1989-09-14",
      "name": [
        {
          "family": "Reyes",
          "given": [
            "Elena"
          ]
        }
      ]
    }
  },
  "access": {
    "permissions": [
      {
        "kind": "data",
        "resource_type": "AllergyIntolerance",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "Condition",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "Observation",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "MedicationRequest",
        "interactions": [
          "read",
          "search"
        ]
      }
    ],
    "data_period": {
      "start": "2021-01-01",
      "end": "2026-01-01"
    }
  },
  "subject_identity_evidence": {
    "source": "embedded",
    "token_type": "id_token",
    "jwt": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImYtU1NKamJDV1BJMnJtU2hXSjUwNHpLQy1Mb01tWGlyVnV0SWtrcmxuZmcifQ.eyJpc3MiOiJodHRwczovL2lkLmV4YW1wbGUtY3NwLm9yZyIsImF1ZCI6InRydXN0ZWQtaXNzdWVyLWFwcCIsInN1YiI6ImNzcC11c2VyLTdkMmYwYTQ0IiwiZ2l2ZW5fbmFtZSI6IkVsZW5hIiwiZmFtaWx5X25hbWUiOiJSZXllcyIsImJpcnRoZGF0ZSI6IjE5ODktMDktMTQiLCJhY3IiOiJodHRwczovL2lkLmV4YW1wbGUtY3NwLm9yZy9hc3N1cmFuY2UvaWFsMiIsImlhdCI6MTc4MTA2MTg2NiwiZXhwIjoxNzgxMDYyMTY2fQ.GMS9z4CTlQPO6Mv0ecMgbErcxUT3bcsYmys6AiNWRH2UuuUDPPLOBzU_L1t28Xr6Wtiqdi5W7Pba02t7HDk9zw"
  }
}
Raw Signed JWT 
eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL3RydXN0ZWQtaXNzdWVyLm9yZyIsImF1ZCI6Imh0dHBzOi8vbmV0d29yay5vcmciLCJhdWRfdHlwZSI6InRydXN0X2ZyYW1ld29yayIsImV4cCI6MTc4MTA2NTQ2NiwiaWF0IjoxNzgxMDYxODY2LCJqdGkiOiJ1YzEtZXYtOWYxYzJiNmEtM2E3Ny00ZDA5LTljNGUtNWEwZDJmODFjM2I3IiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcGF0aWVudC1zZWxmLWFjY2Vzcy12MSIsInByZXNlbnRlcl9iaW5kaW5nIjp7Im1ldGhvZCI6ImprdCIsImprdCI6Ikp1STZpYlpIY01QUUlDYUlaNTVQYlhwbnN1ZFFtS3QwMEQwQmlFWE5yTWMifSwic3ViamVjdCI6eyJwYXRpZW50Ijp7InJlc291cmNlVHlwZSI6IlBhdGllbnQiLCJpZGVudGlmaWVyIjpbeyJzeXN0ZW0iOiJodHRwOi8vaG9zcGl0YWwuZXhhbXBsZS5vcmcvbXJuIiwidmFsdWUiOiJBMTIzNDUifV0sImJpcnRoRGF0ZSI6IjE5ODktMDktMTQiLCJuYW1lIjpbeyJmYW1pbHkiOiJSZXllcyIsImdpdmVuIjpbIkVsZW5hIl19XX19LCJhY2Nlc3MiOnsicGVybWlzc2lvbnMiOlt7ImtpbmQiOiJkYXRhIiwicmVzb3VyY2VfdHlwZSI6IkFsbGVyZ3lJbnRvbGVyYW5jZSIsImludGVyYWN0aW9ucyI6WyJyZWFkIiwic2VhcmNoIl19LHsia2luZCI6ImRhdGEiLCJyZXNvdXJjZV90eXBlIjoiQ29uZGl0aW9uIiwiaW50ZXJhY3Rpb25zIjpbInJlYWQiLCJzZWFyY2giXX0seyJraW5kIjoiZGF0YSIsInJlc291cmNlX3R5cGUiOiJPYnNlcnZhdGlvbiIsImludGVyYWN0aW9ucyI6WyJyZWFkIiwic2VhcmNoIl19LHsia2luZCI6ImRhdGEiLCJyZXNvdXJjZV90eXBlIjoiTWVkaWNhdGlvblJlcXVlc3QiLCJpbnRlcmFjdGlvbnMiOlsicmVhZCIsInNlYXJjaCJdfV0sImRhdGFfcGVyaW9kIjp7InN0YXJ0IjoiMjAyMS0wMS0wMSIsImVuZCI6IjIwMjYtMDEtMDEifX0sInN1YmplY3RfaWRlbnRpdHlfZXZpZGVuY2UiOnsic291cmNlIjoiZW1iZWRkZWQiLCJ0b2tlbl90eXBlIjoiaWRfdG9rZW4iLCJqd3QiOiJleUpoYkdjaU9pSkZVekkxTmlJc0ltdHBaQ0k2SW1ZdFUxTkthbUpEVjFCSk1uSnRVMmhYU2pVd05IcExReTFNYjAxdFdHbHlWblYwU1d0cmNteHVabWNpZlEuZXlKcGMzTWlPaUpvZEhSd2N6b3ZMMmxrTG1WNFlXMXdiR1V0WTNOd0xtOXlaeUlzSW1GMVpDSTZJblJ5ZFhOMFpXUXRhWE56ZFdWeUxXRndjQ0lzSW5OMVlpSTZJbU56Y0MxMWMyVnlMVGRrTW1Zd1lUUTBJaXdpWjJsMlpXNWZibUZ0WlNJNklrVnNaVzVoSWl3aVptRnRhV3g1WDI1aGJXVWlPaUpTWlhsbGN5SXNJbUpwY25Sb1pHRjBaU0k2SWpFNU9Ea3RNRGt0TVRRaUxDSmhZM0lpT2lKb2RIUndjem92TDJsa0xtVjRZVzF3YkdVdFkzTndMbTl5Wnk5aGMzTjFjbUZ1WTJVdmFXRnNNaUlzSW1saGRDSTZNVGM0TVRBMk1UZzJOaXdpWlhod0lqb3hOemd4TURZeU1UWTJmUS5HTVM5ejRDVGxRUE82TXYwZWNNZ2JFcmN4VVQzYmNzWW15czZBaU5XUkgyVXV1VURQUExPQnpVX0wxdDI4WHI2V3RpcWRpNVc3UGJhMDJ0N0hEazl6dyJ9fQ.VSFIibkf_gWth3O4KmdnChpw3ZyVQpsHPNAdnOLknd6PMg2mUUVgvdpYmfRZaRJkfgB0GMA9w5YB3vc-sFd2Xw

The embedded ID token decodes to:

Embedded ID Token (identity evidence)

Header
{
  "alg": "ES256",
  "kid": "f-SSJjbCWPI2rmShWJ504zKC-LoMmXirVutIkkrlnfg"
}
Payload (Claims)
{
  "iss": "https://id.example-csp.org",
  "aud": "trusted-issuer-app",
  "sub": "csp-user-7d2f0a44",
  "given_name": "Elena",
  "family_name": "Reyes",
  "birthdate": "1989-09-14",
  "acr": "https://id.example-csp.org/assurance/ial2",
  "iat": 1781061866,
  "exp": 1781062166
}
Raw Signed JWT 
eyJhbGciOiJFUzI1NiIsImtpZCI6ImYtU1NKamJDV1BJMnJtU2hXSjUwNHpLQy1Mb01tWGlyVnV0SWtrcmxuZmcifQ.eyJpc3MiOiJodHRwczovL2lkLmV4YW1wbGUtY3NwLm9yZyIsImF1ZCI6InRydXN0ZWQtaXNzdWVyLWFwcCIsInN1YiI6ImNzcC11c2VyLTdkMmYwYTQ0IiwiZ2l2ZW5fbmFtZSI6IkVsZW5hIiwiZmFtaWx5X25hbWUiOiJSZXllcyIsImJpcnRoZGF0ZSI6IjE5ODktMDktMTQiLCJhY3IiOiJodHRwczovL2lkLmV4YW1wbGUtY3NwLm9yZy9hc3N1cmFuY2UvaWFsMiIsImlhdCI6MTc4MTA2MTg2NiwiZXhwIjoxNzgxMDYyMTY2fQ.GMS9z4CTlQPO6Mv0ecMgbErcxUT3bcsYmys6AiNWRH2UuuUDPPLOBzU_L1t28Xr6Wtiqdi5W7Pba02t7HDk9zw

Use Case 2: Patient-Delegated Access

Status: Modeled

Purpose

An adult daughter accesses her elderly mother's records. The relationship is verified by a Trusted Issuer, not the Hospital.

Health systems maintain many distinct proxy policies: adult-to-adult delegation, parents of minors, parents of adolescents, guardians, agents under healthcare power of attorney, and more. The ticket's job is to carry enough verified facts for the Data Holder to pick the right one — even for a requester it has never seen.

Typical Flow

Requester completes identity verification with the issuer → issuer verifies the requester's authority for access → issuer mints a presenter-bound ticket naming both subject and requester → the requester's app presents the ticket → the Data Holder resolves the patient, evaluates the requester facts against its local proxy-access policies, and issues a scoped token.

Required Claims

  • Subject: Patient (matched by demographics or identifier), with subject_identity_evidence SHOULD.
  • Requester: RelatedPerson (required) with exactly one relationship coding: the requester's authority. requester_identity_evidence SHOULD.
  • Context: (none — delegation is expressed by the presence and type of requester)
  • Access: permissions with specific resource types and interactions.
  • Presenter binding: Required.

Both evidence slots apply here because a proper issuer verifies both people: the delegate's identity (they are who they claim) and the patient's identity and wishes (they actually granted this access). Embedding both tokens lets the Data Holder check each independently.

Requester and Authority

requester.relationship SHALL contain exactly one coding: the requester's authority — why they are permitted to ask. Family relationship (daughter, spouse) is deliberately left out: proxy policies turn on the authority type and the patient's age, not kinship, and the requester's name covers display.

The authority coding comes from a closed value set of existing v3-RoleCode concepts, covering the mutually exclusive sources of authority:

Source of authority Code(s) Meaning
Patient-granted, informal DELEGATEE The patient (delegator) granted this person access through the issuer's verified workflow
Patient-granted, formal instrument HPOWATT, DPOWATT, POWATT, SPOWATT The patient executed a power-of-attorney-class instrument
Law- or court-conferred GUARD Natural (parental), appointed, or court-ordered guardianship or custody

The ticket SHALL expire (exp) no later than the requester's verified authority ends. If the authority ends early, the issuer revokes the ticket. RelatedPerson.period MAY record the authority's validity dates for audit; Data Holders do not need to check it separately.

Issuer Verification Obligations

Before asserting an authority coding, the issuer SHALL have completed the corresponding verification:

Authority coding The issuer verified that…
DELEGATEE The patient was authenticated and competent at grant time and designated this requester through the issuer's delegation workflow
HPOWATT / DPOWATT / POWATT / SPOWATT A power-of-attorney-class instrument of the corresponding type was examined and covers the requested access
GUARD Guardianship, parental authority, or court-ordered custody/access was verified — including, for parental assertions over a minor, that no known order restricts the requester's access

The issuer keeps the source documents (POA instruments, delegation records, court orders). If a dispute arises later, the ticket's jti lets auditors pull the issuer's records for that grant. Trust frameworks may audit issuer compliance with these obligations.

Policy Selection Inputs

Input Ticket field Selects among
Subject age and demographics subject.patient Policies for minors vs. adolescents vs. adults
Authority requester.relationship Policies for delegates vs. guardians vs. POA agents

Data Holder Processing

  • Resolve the subject as in UC1.
  • Evaluate requester facts against local proxy-access policies. The Data Holder relies on the issuer's verification of identity and authority per its configured trust policy; it applies its own rules for what each requester class may see.
  • Local sensitivity and adolescent-privacy rules continue to apply below the ticket.

What This Ticket Does Not Prove

  • That the requester may see every category of the patient's data; local policy decides what each kind of proxy can see.
  • That the authority remains valid indefinitely; the ticket's validity window and revocation status bound reliance.

Open Questions

Open Question: Per-Ticket Verification Class. Should each ticket also say how the issuer verified the authority (portal delegation record, examined instrument, court order)? Or is it enough that each code carries defined issuer obligations, audited through the trust framework? The working group plans to review this with health-system authorization and release-of-information experts.

Example

Permission Ticket Artifact

Header
{
  "alg": "ES256",
  "kid": "nvOGRCsTz2QIQLsbl0ZQ_ux0tfyh5iave-jvNsANWv8"
}
Payload (Claims)
{
  "iss": "https://trusted-issuer.org",
  "aud": "https://network.org",
  "aud_type": "trust_framework",
  "exp": 1781065466,
  "iat": 1781061866,
  "jti": "uc2-8c6f4ec2-4fb6-4c42-9530-6bbd11c77e49",
  "ticket_type": "https://smarthealthit.org/permission-ticket-type/patient-delegated-access-v1",
  "presenter_binding": {
    "method": "jkt",
    "jkt": "JuI6ibZHcMPQICaIZ55PbXpnsudQmKt00D0BiEXNrMc"
  },
  "subject": {
    "patient": {
      "resourceType": "Patient",
      "identifier": [
        {
          "system": "https://national-mpi.net",
          "value": "pt-555"
        }
      ],
      "birthDate": "1948-06-15",
      "name": [
        {
          "family": "Reyes",
          "given": [
            "Maria"
          ]
        }
      ]
    }
  },
  "requester": {
    "resourceType": "RelatedPerson",
    "relationship": [
      {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
            "code": "DELEGATEE",
            "display": "delegatee"
          }
        ]
      }
    ],
    "period": {
      "end": "2026-12-31"
    },
    "name": [
      {
        "family": "Reyes",
        "given": [
          "Elena"
        ]
      }
    ]
  },
  "access": {
    "permissions": [
      {
        "kind": "data",
        "resource_type": "Condition",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "Immunization",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "MedicationRequest",
        "interactions": [
          "read",
          "search"
        ]
      }
    ]
  }
}
Raw Signed JWT 
eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL3RydXN0ZWQtaXNzdWVyLm9yZyIsImF1ZCI6Imh0dHBzOi8vbmV0d29yay5vcmciLCJhdWRfdHlwZSI6InRydXN0X2ZyYW1ld29yayIsImV4cCI6MTc4MTA2NTQ2NiwiaWF0IjoxNzgxMDYxODY2LCJqdGkiOiJ1YzItOGM2ZjRlYzItNGZiNi00YzQyLTk1MzAtNmJiZDExYzc3ZTQ5IiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcGF0aWVudC1kZWxlZ2F0ZWQtYWNjZXNzLXYxIiwicHJlc2VudGVyX2JpbmRpbmciOnsibWV0aG9kIjoiamt0Iiwiamt0IjoiSnVJNmliWkhjTVBRSUNhSVo1NVBiWHBuc3VkUW1LdDAwRDBCaUVYTnJNYyJ9LCJzdWJqZWN0Ijp7InBhdGllbnQiOnsicmVzb3VyY2VUeXBlIjoiUGF0aWVudCIsImlkZW50aWZpZXIiOlt7InN5c3RlbSI6Imh0dHBzOi8vbmF0aW9uYWwtbXBpLm5ldCIsInZhbHVlIjoicHQtNTU1In1dLCJiaXJ0aERhdGUiOiIxOTQ4LTA2LTE1IiwibmFtZSI6W3siZmFtaWx5IjoiUmV5ZXMiLCJnaXZlbiI6WyJNYXJpYSJdfV19fSwicmVxdWVzdGVyIjp7InJlc291cmNlVHlwZSI6IlJlbGF0ZWRQZXJzb24iLCJyZWxhdGlvbnNoaXAiOlt7ImNvZGluZyI6W3sic3lzdGVtIjoiaHR0cDovL3Rlcm1pbm9sb2d5LmhsNy5vcmcvQ29kZVN5c3RlbS92My1Sb2xlQ29kZSIsImNvZGUiOiJERUxFR0FURUUiLCJkaXNwbGF5IjoiZGVsZWdhdGVlIn1dfV0sInBlcmlvZCI6eyJlbmQiOiIyMDI2LTEyLTMxIn0sIm5hbWUiOlt7ImZhbWlseSI6IlJleWVzIiwiZ2l2ZW4iOlsiRWxlbmEiXX1dfSwiYWNjZXNzIjp7InBlcm1pc3Npb25zIjpbeyJraW5kIjoiZGF0YSIsInJlc291cmNlX3R5cGUiOiJDb25kaXRpb24iLCJpbnRlcmFjdGlvbnMiOlsicmVhZCIsInNlYXJjaCJdfSx7ImtpbmQiOiJkYXRhIiwicmVzb3VyY2VfdHlwZSI6IkltbXVuaXphdGlvbiIsImludGVyYWN0aW9ucyI6WyJyZWFkIiwic2VhcmNoIl19LHsia2luZCI6ImRhdGEiLCJyZXNvdXJjZV90eXBlIjoiTWVkaWNhdGlvblJlcXVlc3QiLCJpbnRlcmFjdGlvbnMiOlsicmVhZCIsInNlYXJjaCJdfV19fQ.jbBAuhjMr8hlvaomkSQ4YJ4_FFtlqJyTxL94RLoOGwhwi-iuI1RAQ2WMm1QSU0GQbgLSkkOGBny9_XOmukE8mA

Use Case 3: Public Health Investigation

Status: Modeled

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 an automated yes 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 context → 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).
  • Context: reportable_condition (coded condition) — says which investigation the request belongs to and bounds it.
  • Access: permissions; optional data_period and data_holder_filter.
  • Presenter binding: Optional (B2B; aud + client authentication generally suffice).

Policy Selection Inputs

Input Ticket field Selects among
Requesting agency requester (Organization identifiers) Whether the agency is known (directory match); any per-agency arrangements
Reportable condition context.reportable_condition What the investigation covers; which kinds of data to release

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.

What This Ticket Does Not Prove

  • The detailed legal mandate behind the investigation. This specification is jurisdiction-neutral; the legal basis for public-health disclosure lives in applicable law, the trust framework, and the Data Holder's policy — not in the base ticket.
  • That every data class is responsive to the named condition; the Data Holder may narrow.

Example

Permission Ticket Artifact

Header
{
  "alg": "ES256",
  "kid": "nvOGRCsTz2QIQLsbl0ZQ_ux0tfyh5iave-jvNsANWv8"
}
Payload (Claims)
{
  "iss": "https://issuer.state.example.gov",
  "aud": "https://network.org",
  "aud_type": "trust_framework",
  "exp": 1781065466,
  "iat": 1781061866,
  "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": {
    "permissions": [
      {
        "kind": "data",
        "resource_type": "Condition",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "Observation",
        "interactions": [
          "read",
          "search"
        ]
      },
      {
        "kind": "data",
        "resource_type": "DiagnosticReport",
        "interactions": [
          "read",
          "search"
        ]
      }
    ],
    "data_period": {
      "start": "2025-12-01",
      "end": "2026-06-01"
    },
    "data_holder_filter": [
      {
        "kind": "jurisdiction",
        "address": {
          "country": "US",
          "state": "TX"
        }
      }
    ]
  },
  "context": {
    "reportable_condition": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "840539006",
          "display": "Disease caused by severe acute respiratory syndrome coronavirus 2 (disorder)"
        }
      ]
    }
  }
}
Raw Signed JWT 
eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL2lzc3Vlci5zdGF0ZS5leGFtcGxlLmdvdiIsImF1ZCI6Imh0dHBzOi8vbmV0d29yay5vcmciLCJhdWRfdHlwZSI6InRydXN0X2ZyYW1ld29yayIsImV4cCI6MTc4MTA2NTQ2NiwiaWF0IjoxNzgxMDYxODY2LCJqdGkiOiJ1YzMtMTZmZjYyY2YtMmQyZC00YjMwLThjODYtNmExM2Q3YWI3ZDE2IiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcHVibGljLWhlYWx0aC1pbnZlc3RpZ2F0aW9uLXYxIiwicHJlc2VudGVyX2JpbmRpbmciOnsibWV0aG9kIjoidHJ1c3RfZnJhbWV3b3JrX2NsaWVudCIsInRydXN0X2ZyYW1ld29yayI6Imh0dHBzOi8vc3RhdGUuZXhhbXBsZS5nb3YvdHJ1c3QtZnJhbWV3b3JrL3B1YmxpYy1oZWFsdGgiLCJmcmFtZXdvcmtfdHlwZSI6InVkYXAiLCJlbnRpdHlfdXJpIjoiaHR0cHM6Ly9zdGF0ZS5leGFtcGxlLmdvdi9vcmdhbml6YXRpb25zL2VwaS11bml0In0sInN1YmplY3QiOnsicGF0aWVudCI6eyJyZXNvdXJjZVR5cGUiOiJQYXRpZW50IiwiaWRlbnRpZmllciI6W3sic3lzdGVtIjoiaHR0cDovL2hvc3BpdGFsLmV4YW1wbGUub3JnL21ybiIsInZhbHVlIjoiTTQ0NTU2NiJ9XSwiYmlydGhEYXRlIjoiMTk3OC0wMi0yMSIsIm5hbWUiOlt7ImZhbWlseSI6IkNhcnRlciIsImdpdmVuIjpbIk1vbmljYSJdfV19fSwicmVxdWVzdGVyIjp7InJlc291cmNlVHlwZSI6Ik9yZ2FuaXphdGlvbiIsImlkZW50aWZpZXIiOlt7InN5c3RlbSI6InVybjppZXRmOnJmYzozOTg2IiwidmFsdWUiOiJodHRwczovL3N0YXRlLmV4YW1wbGUuZ292L29yZ2FuaXphdGlvbnMvZXBpLXVuaXQifV0sIm5hbWUiOiJTdGF0ZSBFcGlkZW1pb2xvZ3kgVW5pdCJ9LCJhY2Nlc3MiOnsicGVybWlzc2lvbnMiOlt7ImtpbmQiOiJkYXRhIiwicmVzb3VyY2VfdHlwZSI6IkNvbmRpdGlvbiIsImludGVyYWN0aW9ucyI6WyJyZWFkIiwic2VhcmNoIl19LHsia2luZCI6ImRhdGEiLCJyZXNvdXJjZV90eXBlIjoiT2JzZXJ2YXRpb24iLCJpbnRlcmFjdGlvbnMiOlsicmVhZCIsInNlYXJjaCJdfSx7ImtpbmQiOiJkYXRhIiwicmVzb3VyY2VfdHlwZSI6IkRpYWdub3N0aWNSZXBvcnQiLCJpbnRlcmFjdGlvbnMiOlsicmVhZCIsInNlYXJjaCJdfV0sImRhdGFfcGVyaW9kIjp7InN0YXJ0IjoiMjAyNS0xMi0wMSIsImVuZCI6IjIwMjYtMDYtMDEifSwiZGF0YV9ob2xkZXJfZmlsdGVyIjpbeyJraW5kIjoianVyaXNkaWN0aW9uIiwiYWRkcmVzcyI6eyJjb3VudHJ5IjoiVVMiLCJzdGF0ZSI6IlRYIn19XX0sImNvbnRleHQiOnsicmVwb3J0YWJsZV9jb25kaXRpb24iOnsiY29kaW5nIjpbeyJzeXN0ZW0iOiJodHRwOi8vc25vbWVkLmluZm8vc2N0IiwiY29kZSI6Ijg0MDUzOTAwNiIsImRpc3BsYXkiOiJEaXNlYXNlIGNhdXNlZCBieSBzZXZlcmUgYWN1dGUgcmVzcGlyYXRvcnkgc3luZHJvbWUgY29yb25hdmlydXMgMiAoZGlzb3JkZXIpIn1dfX19.V0nopt9RmslGwhHOXN1ehVpNVNMKvqFaLIO1g2TdX5_RTwQbyJgwXGY5FLZvj9O20WRY_QxhvT3hT7TrOVox6w