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

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.

Introduced by the Payer Claims Adjudication ticket type, where it is the required bound on release. The linkage is anchored on the encounters the claim covers — always available at submission because the issuer is the Data Holder, minting references into its own records. Enforcement is defined against those records, which confines this constraint to self-issued tickets today.

Shape and validity. encounter (required) is a non-empty array of references to the encounter records the claim covers, using the issuer's own resource URLs. claim (optional) is a single reference that re-associates the ticket with the submission it accompanies; its identifier carries the provider's own submission-time control number — the X12 837 CLM01, echoed back to the provider in the 835 — never a payer-assigned claim number (ICN / DCN / CCN), which does not exist when the ticket is minted.

"claim_linkage": {
  "encounter": [
    { "reference": "https://provider.example.org/Encounter/enc-2026-0117" }
  ],
  "claim": {
    "type": "Claim",
    "identifier": { "system": "https://provider.example.org/claims", "value": "CLM-2026-0042" },
    "display": "Submitted claim CLM-2026-0042"
  }
}

For the authorizing party. The constraint records what the provider organization decided to disclose: records tied to the encounters this claim covers, for this adjudication, and nothing else. This is how the ticket carries HIPAA's minimum-necessary standard.

For the client. The payer learns which encounters the ticket covers and, when present, the handle for re-associating the ticket with its submission: the provider's submission control number, the same value returned in the 835. What to expect from redemption: records the provider associates with those encounters. The response may be lawfully incomplete; absence of a record is not a representation that it does not exist.

For the Data Holder. Release only records you associate with the linked encounters: at minimum the records linked to the named encounter references, plus current problems, medications, and allergies. The association is your own — you minted the ticket against your own records — so enforcement is determinate. A Data Holder with no association knowledge for the linkage cannot enforce this constraint and rejects the ticket. That is the correct outcome, and it confines this ticket type to self-issued tickets today.

The enforcement floor names patient-level categories explicitly because encounter linkage in FHIR data is incomplete: the records adjudication needs most — problem list, medications, allergies — typically link to no encounter at all.