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

Patient-Delegated Access

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

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.
• Presenter binding: Required.

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

Constraints

Draws from the constraint catalog. The authorizing party is the patient — or the instrument that confers authority — not the delegate who presents the ticket, so the issuer presents each definition's authorizing-party language during the delegation ceremony. The Data Holder's proxy policy narrows below the ticket: a granted scope never overrides what local policy lets this class of requester see.

• smart_scopes (required) — the ceiling the patient set when granting the delegation.
• data_period (optional) — a time bound set at the same ceremony.
• data_holder_filter (optional) — the organizations or regions the patient selected when delegating.

The two individual-access types draw the same constraints; only the ceremony that sets the values differs.

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 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:

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:

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

Data Holder Processing

• Resolve the subject as in patient self access.
• 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.

Open Questions

Open Question (OQ-UC2-VERIFY): 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

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

{
  "iss": "https://trusted-issuer.org",
  "aud": "https://network.org",
  "aud_type": "trust_framework",
  "exp": 1782333550,
  "iat": 1782329950,
  "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": {
    "smart_scopes": [
      "patient/Condition.rs",
      "patient/Immunization.rs",
      "patient/MedicationRequest.rs"
    ]
  }
}

eyJhbGciOiJFUzI1NiIsImtpZCI6Im52T0dSQ3NUejJRSVFMc2JsMFpRX3V4MHRmeWg1aWF2ZS1qdk5zQU5XdjgifQ.eyJpc3MiOiJodHRwczovL3RydXN0ZWQtaXNzdWVyLm9yZyIsImF1ZCI6Imh0dHBzOi8vbmV0d29yay5vcmciLCJhdWRfdHlwZSI6InRydXN0X2ZyYW1ld29yayIsImV4cCI6MTc4MjMzMzU1MCwiaWF0IjoxNzgyMzI5OTUwLCJqdGkiOiJ1YzItOGM2ZjRlYzItNGZiNi00YzQyLTk1MzAtNmJiZDExYzc3ZTQ5IiwidGlja2V0X3R5cGUiOiJodHRwczovL3NtYXJ0aGVhbHRoaXQub3JnL3Blcm1pc3Npb24tdGlja2V0LXR5cGUvcGF0aWVudC1kZWxlZ2F0ZWQtYWNjZXNzLXYxIiwicHJlc2VudGVyX2JpbmRpbmciOnsibWV0aG9kIjoiamt0Iiwiamt0IjoiSnVJNmliWkhjTVBRSUNhSVo1NVBiWHBuc3VkUW1LdDAwRDBCaUVYTnJNYyJ9LCJzdWJqZWN0Ijp7InBhdGllbnQiOnsicmVzb3VyY2VUeXBlIjoiUGF0aWVudCIsImlkZW50aWZpZXIiOlt7InN5c3RlbSI6Imh0dHBzOi8vbmF0aW9uYWwtbXBpLm5ldCIsInZhbHVlIjoicHQtNTU1In1dLCJiaXJ0aERhdGUiOiIxOTQ4LTA2LTE1IiwibmFtZSI6W3siZmFtaWx5IjoiUmV5ZXMiLCJnaXZlbiI6WyJNYXJpYSJdfV19fSwicmVxdWVzdGVyIjp7InJlc291cmNlVHlwZSI6IlJlbGF0ZWRQZXJzb24iLCJyZWxhdGlvbnNoaXAiOlt7ImNvZGluZyI6W3sic3lzdGVtIjoiaHR0cDovL3Rlcm1pbm9sb2d5LmhsNy5vcmcvQ29kZVN5c3RlbS92My1Sb2xlQ29kZSIsImNvZGUiOiJERUxFR0FURUUiLCJkaXNwbGF5IjoiZGVsZWdhdGVlIn1dfV0sInBlcmlvZCI6eyJlbmQiOiIyMDI2LTEyLTMxIn0sIm5hbWUiOlt7ImZhbWlseSI6IlJleWVzIiwiZ2l2ZW4iOlsiRWxlbmEiXX1dfSwiYWNjZXNzIjp7InNtYXJ0X3Njb3BlcyI6WyJwYXRpZW50L0NvbmRpdGlvbi5ycyIsInBhdGllbnQvSW1tdW5pemF0aW9uLnJzIiwicGF0aWVudC9NZWRpY2F0aW9uUmVxdWVzdC5ycyJdfX0.XTE6E-tbusMrlvXnZaCOeBjtcQEWsDLJumc4l-8i3WTrMxfF21iuaA205IxrJvmUFHWXT5lvsrrgt7Nttcmj4Q