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

Constraint: data_holder_filter

This page defines one access constraint. The constraint model, template, and algebra are on Access Constraints; the ticket types that draw this constraint are in the Use Case Catalog.

Shape and validity. Optional. An array of entries, each either { kind: "jurisdiction", address } or { kind: "organization", organization }, where an organization entry's organization is itself an array of references. The issuer derives entries from the authorizing party's selections or the network the ticket is scoped to.

For the authorizing party. The filter decides which Data Holders may answer, not which records an answering Data Holder returns. A Data Holder that matches the filter typically returns the combined record it holds; see the implementation note below for what a site selection does and does not limit.

For the client. The filter tells the client which Data Holders are worth trying. A rejection for filter mismatch means this Data Holder is outside the ticket's scope, not that the ticket is invalid elsewhere.

For the Data Holder. Answer the question "do I match any listed entry?" once, when the ticket is presented. Matching is one-hop against the responding Data Holder, not a provenance chain, and gates the Data Holder as a whole, not individual clinical resources — the filter is not a promise that returned data can be split by facility, department, custodian, endpoint, or provenance. aud identifies the coarse intended audience; data_holder_filter narrows within it. Matching rules per entry kind follow.

Implementation Note: Picking a clinic does not always limit data to that clinic.

One Data Holder often serves many clinics, hospitals, and even legally separate organizations through a single shared system. Inside that system, allergies, problems, and medications live in one combined patient chart that cannot reliably be split apart by facility.

The organization filter decides whether the Data Holder as a whole may answer. A Data Holder that accepts the ticket will typically return the combined record it holds, subject to the ticket's other constraints. A site or clinic selection on an authorization screen does not guarantee the response is limited to that site's data.

Issuers SHOULD use directory or network information (published endpoint networks, trust-framework directories, SMART Brands data) to detect when a selected facility is served through a broader shared system, and tell the authorizing person so. When the issuer cannot tell, it should warn generically that more data may flow than the site label suggests. Future versions may define finer disclosure-boundary hints; this one does not.

Jurisdiction Filters

  • Jurisdiction filters are modeled with country/state-style values only.
  • A Data Holder checks whether its own jurisdiction matches the listed address.
  • A Data Holder operating in multiple jurisdictions SHOULD answer if any of its jurisdictions match the filter, and MAY apply narrower internal filtering if its architecture supports that attribution.

Organization Filters

  • An organization filter's organization is an array of references to the organizations whose Data Holders may answer. All allowed organization identifiers are flattened into one array; a Data Holder may answer if it matches any entry.
  • Each reference carries an organizational identifier — for example an NPI or TIN — and MAY carry a display. Matching is by identifier; the display is for logs and screens. An organization known by several identifiers (a TIN plus one or more NPIs, say) contributes one entry per identifier.
  • A Data Holder may answer if it matches a listed organization or is authorized to answer on that organization's behalf.
  • This filter is endpoint-agnostic. If a Data Holder operates multiple technical endpoints, a single organization filter authorizes access through any endpoint by which that organization is authorized to answer and that supports the Permission Ticket grant type.
  • Data Holders that manage integrated records across multiple facilities evaluate this filter at the Data Holder level, not as a resource-by-resource clinical data filter.
  • A Data Holder answering on behalf of a named organization that is served through a broader shared system MAY narrow its response to that organization's records, if its architecture supports the attribution. Narrowing is permitted, not promised: the filter still gates who may answer, and acceptance still typically returns the combined record.