Permission — Computed access authorisation
The bridge between a human Consent (will declaration) and a technical Policy Enforcement Point: an ABAC/RBAC rule consumable by a PEP/PDP, with activity, data, purpose and limits.
Purpose of the resource
Permission represents an authorisation rule derived from a Consent, an organisational policy or a legal obligation. Where Consent captures the patient's decision in business language, Permission translates it into evaluable ABAC rules: who can do what on which data for what purpose, over what period.
Emerging IHE PCF, ONC FAST Security and HL7 SMART Health Cards profiles use Permission as an exchange format between the consent engine and the application PEP.
Key fields
| Field | Type | Cardinality | Role |
|---|---|---|---|
status | code | 1..1 | active | entered-in-error | draft | rejected. |
asserter | Reference(Organization | Practitioner | RelatedPerson | Patient) | 0..1 | Entity asserting the rule. |
date | dateTime[] | 0..* | Significant dates (signature, review). |
validity | Period | 0..1 | Period of validity. |
justification | BackboneElement | 0..1 | Reference to Consent / legal DocumentReference. |
combining | code | 0..1 | Combining algorithm: deny-overrides | permit-overrides | ordered-deny-overrides | ordered-permit-overrides | deny-unless-permit | permit-unless-deny. |
rule | BackboneElement[] | 0..* | Atomic rules (type, data, activity, limit). |
JSON example
{
"resourceType": "Permission",
"id": "example",
"status": "active",
"asserter": { "reference": "Organization/example-hospital" },
"date": ["2026-05-15"],
"validity": {
"start": "2026-05-15",
"end": "2031-05-15"
},
"combining": "permit-overrides",
"rule": [{
"type": "permit",
"data": [{
"resource": [{
"meaning": "instance",
"reference": { "reference": "Patient/example" }
}]
}],
"activity": [{
"purpose": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
"code": "TREAT"
}]
}]
}]
}]
}Consent vs Permission
| Aspect | Consent | Permission |
|---|---|---|
| Audience | Human, legal | System, PEP/PDP |
| Granularity | Category, type of use | Fine-grained ABAC action |
| Lifecycle | Signed by the patient, withdrawn or amended | Recomputed from applicable Consents |
| Model | Document | Rule (XACML-like) |
Common pitfalls
- Permission without
combining— default evaluation is ambiguous. - Rule without
activity— equates to "everything"; rarely intended. - Open-ended validity — close it or use
justification+ Consent. - Consent ↔ Permission sync — a revoked Consent must propagate to derived Permissions.
Related resources
- Consent — patient's will declaration.
- Provenance — trail of evaluation.
- AuditEvent — resulting access log.
- FHIR R5 hub.