Short Description

FHIR Permission development, evaluation, and testing

Long Description

Given that there is an identified need for a FHIR Permission, and discussion from a number of parties that have developed something similar in function; looking to evaluate the existing Permission prototype, identify use-cases, prioritize use-cases, and work on developing examples and narrative.

Goal is to determine how to improve the Permission resource, and to write the Resource Proposal for submission to FMG for approval (The current Permission is a draft that is not approved by FMG). Capturing use-cases, and scope/boundary.

Stretch goal

  • determine how Consent and Permission will or might evolve in the R6 timeframe. 
  • Engagement and impact on the IHE implementation guide on FHIR Consent use, and how that will evolve as Consent and Permission mature.


Test the design of the Permission resource

Related Tracks?

Consent, AuditEvent, Smart-on-FHIR

Call for participants

FHIR Server platform vendors, Reference implementations, and Organizations hosting and consuming FHIR data.

Track Prerequisites


  • Review the current build of Permission
  • Review current confluence of potential use-cases  FHIR Permission Confluence Page
  • Prepared to share current solutions that cover similar use-case need
  • Prepared to present use-cases that you expect are in scope of Permission

Should be familiar with:

  • FHIR Consent resource
  • SMART-on-FHIR operates
  • AuditEvent, specifically the AuditEvent profile for an Access Control decision found in IHE-BALP


Note that IHE is working on an IG covering the use of FHIR Consent to support Patient Consent. This is developing, but will likely be discussed too

Track Lead(s)

John Moehrke

Track Lead Email(s)

Specification Information

Zulip stream

historic discussion:


Track Kick off Call

November 23, 2022

 recording -

Connectathon Breakout sessions

I have reserved a breakout room for Saturday afternoon and Sunday afternoon for detailed discussions:

Saturday: 16:00 = Event Center Breakout Room
Sunday: 15:00 = Event Center Breakout Room

I expect this will be where we get most of our work done. Discussing

  1. Current solutions that you all have created in the absence of a FHIR Permission
  2. Use-Cases that FHIR Permission should look to solve
  3. Experience with using the current FHIR Permission to satisfy use-cases
System Roles

Policy Authors - authors of Policy of all forms. Including overall policy that sets the stage for decision making, as well as setting specific policies such as Consent policy, and the rules that are used to determine the restrictions on context specific policies.

Permission Author - authors Permissions that are expected to be utilized in Access Control Decisions. These Permissions would fit some profile of the environment that would limit the expressiveness of the Permission resource

Access Control Decision Point - makes access control decisions that are based on relevant Permissions, and other contextual information necessary

Access Control Enforcement Point – enforces decisions made by the Access Control Decision Point

Access Control Client – a FHIR client that is otherwise being restricted by the Policies. The Access Control Client is inclusive of User, Role, App, and any other that is necessary to define the request and the context of that request.

Access Control Resource Server  - A FHIR server that holds FHIR resources and responds  to FHIR operations that are protected resources. The protection in this case is not limited to Patient data, or Patient sensitive health data. The resource may be a resource that is protected for business rules. Thus the FHIR Server in this case is, can be, ignorant of the policies as the Access Control Enforcement Point provides appropriate protection.

Note may be same or similar set of actors that are focused on Consent, but the above actors are abstractly focused on Permission for this track sake.

Testing Scenario:

Expressing Policies:


Use-Case 1 - recording a Permission

In this use-case we look to various access control needs and determine how that would be recorded in the existing Permission, and to write up any improvement opportunities for Permission.

This will include testing how Permission instances relate to their foundational policies. Where these foundational policies may be other Permissions, Consents, or externally-authored policies. Where externally authored policies may be just human readable but well identified, or may be based on external standards such as XACML, ODRL, or other (including proprietary).

This may include discussion of a definitional form of Permission, vs Profiling.


Use-Case 2 - use of Permission as residual policy in Bundles

In this use-case we look to how the Permission can be used in a Bundle to carry obligations and refrains that are more expressible than security-labels. The Permission would need to be limited to encoding that the sender is confident the recipient will obey.  

This use-case is similar to Use-Case 1 and 3 except that the residual policy is encoded in Permission carried in the Bundle. Thus the recipient is expected to make residual Access Control Decisions inclusive of this Permission.

How the sender knows what the recipient is willing to obey may be a stretch goal, but is expected to be overriding policy not expressed

Processing and Enforcing Policies:


Use-Case 3 - Access Control Decision that utilizes a Permission

In this use-case we look to how a generalization of an Access Control Decision Point and Access Control Enforcement Point may utilize existing an Permission or a number of Permissions that are deemed applicable to a decision context. Some of the major points of deliberation are as follows:

  1. How to search for all Permission resources applicable to a request context (discovery). This hinges on sufficient search parameters within the Permission resource to enable and facilitate the discovery.
  2. How to process one Permission and evaluate it against a request context and determine the decision according to that Permission instance.
  3. How to combine and reconcile multiple decisions in the case there are more than one applicable Permissions.
  4. The interface/API for the access control query/response.

For the latter question (4), we encourage using OAuth 2.0 between the Access Control Decision Point actor and the Access Control Enforcement Point actor. This may result in extending the specifications, to address questions such as how to further constrain or guide the use of specifications like SMART-on-FHIR.

Audit and Provenance:


Use-Case 4 - AuditEvent recording of Access Control Decisions

The Access Control Decisions might utilize the AuditEvent to record the decision. When this is done, there should be profiles of AuditEvent for this purpose.

see predicate work in IHE BALP Implementation Guide:


Use-Case 5 - Provenance for policy derivation (experimental)

Policy authors might use the Provenance resource to maintain record and trace the link between a Permission instance and the original forms of policy on which it is based. The original policy may be in the form of another Permission, a Consent resource, Document, or externally-authored policies. Where externally authored policies may be just human readable but well identified, or may be based on external standards such as XACML, ODRL, or other (including proprietary).

This paves the way for a profile, or a set of examples, that clarifies how the Provenance resource should look like for these use cases.


Use-Case 6 - Provenance for Access Control Decisions (experimental)

The Access Control Decision Point, in some cases, needs a mechanism to record the policy on which basis a decision was made --a (number of) Permission resource(s). This may be recorded within the AuditEvent resource that records the decision in the form of an extension, or it may be recorded using a Provenance resource. The goal of this use case is to explore the best mechanism to address this need and provide a profile, or a set of examples, that demonstrate how this can be done.