FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

6.5 Resource Permission - Content

Security icon Work GroupMaturity Level: 1 Trial UseSecurity Category: Not Classified Compartments: No defined compartments

Permission resource holds access rules for a given data and access request context.

6.5.1 Scope and Usage

A declarative attribute-based access control policy statement. Permission is used to express who has specific rights to specific data under specific conditions. Permission can express rules including

  • security labels/codes (policies, refrains, and obligations),
  • user identity,
  • application being used,
  • location of the requester,
  • organization requesting access,
  • purposeOfUse of the request and for which the data will be used,
  • data sensitivity, timeframe, authorship, and
  • the current status of privacy Consent.

The Permission can express permit or deny rules; and with permit rules there may be residual refrains, obligations, or filtering. The Permission resource may be used to record the access control constraints under which data can be collected, used, or shared.

6.5.2 Boundaries and Relationships

The Permission resource is intended to be used to encode access control policies in a FHIR interoperable language. Where the access control policies protect access to FHIR defined interactions, resources, and operations; from actions done by organizations, practitioners, patients, and etc.

The Permission resource is intended to be used where Consent resource does not apply or where exposure of the full Consent details are not needed or desired. The Permission resource may be used to express transactional access control rules that may be derived from a Consent.

Examples are:

  • use-cases that are not involving a patient subject.
  • an organizational directory: who can create, update, delete, and read
  • an organization wide access control policy expressing user groups and what they generally have available to them
  • residual policy that must be applied by a recipient of a response Bundle
  • base policy that Consent builds upon (i.e., `Consent.policyBasis.reference`)
  • consent provisions (i.e., `Consent.provision`) encoding in a different rule language (i.e., `Permission.rule`) using `Consent.provisionReference`.

The Permission resource should not be used in a conflicting way with security labels in the .meta.security element icon.

6.5.3 References to this Resource

  • Resource References: Consent and itself

6.5.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Permission TU DomainResource Access Rules

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Business Identifier for permission

... status Σ 1..1 code active | entered-in-error | draft | rejected
Binding: Permission Status (Required)
... asserter Σ 0..1 Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson | HealthcareService) The person or entity that asserts the permission
... validity Σ 0..1 Period The period in which the permission is active
... justification Σ 0..1 BackboneElement The asserted justification for using the data
.... basis Σ 0..* CodeableConcept The regulatory grounds upon which this Permission builds
Binding: Consent PolicyRule Codes (Example)

.... evidence Σ 0..* Reference(Any) Justifing rational

... combining ?!Σ 1..1 code deny-overrides | permit-overrides | ordered-deny-overrides | ordered-permit-overrides | deny-unless-permit | permit-unless-deny
Binding: Permission Rule Combining (Required)
... rule ΣC 0..* BackboneElement Constraints to the Permission
+ Rule: If the import element is populated then the type, data, and activity shall not be populated
This repeating element order: The order of the rules processing is defined in rule combining selected in .combining element.
.... import ΣC 0..1 Reference(Permission) Reference to a Permission
.... type ?!ΣC 0..1 code deny | permit
Binding: Consent Provision Type (Required)
.... data ΣC 0..* BackboneElement The selection criteria to identify data that is within scope of this provision

..... resource Σ 0..* BackboneElement Explicit FHIR Resource references

...... meaning Σ 1..1 code instance | related | dependents | authoredby
Binding: Consent Data Meaning (Required)
...... reference Σ 1..1 Reference(Any) The actual data reference
..... security Σ 0..* Coding Security tag code on .meta.security

..... period Σ 0..1 Period Timeframe encompasing data create/update
..... expression Σ 0..1 Expression Expression identifying the data
.... activity ΣC 0..* BackboneElement A description or definition of which activities are allowed to be done on the data

..... actor 0..* BackboneElement Who|what is controlled by this rule

...... role 0..1 CodeableConcept How the actor is involved
Binding: Participation Role Type (Extensible)
...... reference Σ 0..1 Reference(Device | Group | CareTeam | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole | DeviceDefinition | Group | HealthcareService) Authorized actor(s)
..... action Σ 0..* CodeableConcept Actions controlled by this rule
Binding: Type Restful Interaction (Preferred)

..... purpose Σ 0..* CodeableConcept The purpose for which the permission is given
Binding: PurposeOfUse icon (Preferred)

.... limit 0..* BackboneElement What limits apply to the use of the data

..... control Σ 0..* CodeableConcept What coded limits apply to the use of the data
Binding: SecurityControlObservationValue icon (Preferred)

..... tag Σ 0..* Coding The sensitivity codes that must be removed from the data
Binding: InformationSensitivityPolicy icon (Preferred)

..... element Σ 0..* string What data elements that must be removed from the data


doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

6.5.4.1 Terminology Bindings

Path ValueSet Type Documentation
Permission.status PermissionStatus Required

Codes identifying the lifecycle stage of a product.
Permission.justification.basis ConsentPolicyRuleCodes Example

This value set includes sample Regulatory consent policy types from the US and other regions.
Permission.combining PermissionRuleCombining Required

Codes identifying rule combining algorithm.
Permission.rule.type ConsentProvisionType Required

How a rule statement is applied, such as adding additional consent or removing consent.
Permission.rule.data.resource.meaning ConsentDataMeaning Required

How a resource reference is interpreted when testing consent restrictions.
Permission.rule.activity.actor.role ParticipationRoleType Extensible

This FHIR value set is comprised of Actor participation Type codes, which can be used to value FHIR agents, actors, and other role elements. The codes are intended to express how the agent participated in some activity. Sometimes refered to the agent functional-role relative to the activity.
Permission.rule.activity.action TypeRestfulInteraction Preferred

Operations supported by REST at the type or instance level.
Permission.rule.activity.purpose PurposeOfUse icon Preferred

Supports communication of purpose of use at a general level.
Permission.rule.limit.control SecurityControlObservationValue icon Preferred

Security observation values used to indicate security control metadata. V:SecurityControl is the union of V:SecurityPolicy, V:ObligationPolicy, V:RefrainPolicy, V:PurposeOfUse, and V:GeneralPurpose of Use, V:PrivacyMark, V:SecurityLabelMark, and V:ControlledUnclassifiedInformation used to populate the SecurityControlObservationValue attribute in order to convey one or more nonhierarchical security control metadata dictating handling caveats including, purpose of use, obligation policy, refrain policy, dissemination controls and privacy marks to which a custodian or receiver is required to comply.
Permission.rule.limit.tag InformationSensitivityPolicy icon Preferred

Sensitivity codes are not useful for interoperability outside of a policy domain because sensitivity policies are typically localized and vary drastically across policy domains even for the same information category because of differing organizational business rules, security policies, and jurisdictional requirements. For example, an "employee" sensitivity code would make little sense for use outside of a policy domain. "Taboo" would rarely be useful outside of a policy domain unless there are jurisdictional requirements requiring that a provider disclose sensitive information to a patient directly.

Sensitivity codes may be more appropriate in a legacy system's Master Files in order to notify those who access a patient's orders and observations about the sensitivity policies that apply. Newer systems may have a security engine that uses a sensitivity policy's criteria directly. The specializable Sensitivity Act.code may be useful in some scenarious if used in combination with a sensitivity identifier and/or Act.title.

6.5.4.2 Constraints

UniqueKeyLevelLocationDescriptionExpression
img per-1Rule Permission.ruleIf the import element is populated then the type, data, and activity shall not be populatedimport.exists() implies type.exists().not() and data.exists().not() and activity.exists().not()

6.5.4.3 Composite Permissions

In some cases, there are common components across different Permission rules and repeating those common rules could lead to redundancy which in turn could lead to the risk on inconsistency, if the common components are not formulated precisely in the same manner. Therefore, it is desirable to have a mechanism to define a common set of rules and refer to them in a single Permission resources. The import attribute enables pointing to such common rules by referencing the Permission resource.

If the import attribute is used in rule, the rule element shall not contain any other elements. The result of evluating a rule with an import is defined to be the result of evaluating the referenced Permission resource. The decision from that evaluation will then be combined with the decision from the other rues based on the combining algorithm specified in the combining element.

If the referenced Permission is not active or expired, this should be interpreted as returning a not-applicable decision because the referenced permission is silent about whether access should be permitted or denied in the given context.

A circular reference in processing linked Permissions should be treated as an error, leading to a not-applicable decision bubbling up from the Permission resource in which the circular reference was encountered.

Implementers shoud rely on pragmatic limits on the length of the chain of linked Permission and put in place reasonable guardrails against (maliciously or erroneously) large chains that could lead to draining of resources at the time of processing.

6.5.4.4 Rules Processing Logic

Each .rule is evaulated within the combining rule identified in the .combining element.

Within a .rule any repititions of the .data element are in an OR relationship. That is to say that the data identified by the rule is all the data identified by all repititions of .data. Thus to identify one rule that applies to data tagged with STD and data that is tagged with HIV, one would repeat this at the .data level.

Within a .rule any repititions of the .activity element are in an OR relationship. That is to say that the rule applies to all the repititions of .activity. Thus to identify one rule that applies to both TREAT and HOPERAT, one would have one rule with repititions at the .activity level.

Within a .rule all repititions of the .limit all apply to the rule. That is to say if there are multiple limits, and the rule permits the activity, then all the identified limits are applied to that authorized activity.

Within the .data element, all elements and all repetitions of elements, are in an AND relationship. Thus to select data that has both STD and HIV one puts both into one .rule. To have different rules for STD from HIV, one would need to have two .rule elements. To have a rule that applies to both, those that have just STD and just HIV, this repitition may also be done at the data level as described above.

Within the .activity element, all elements and all repetitions of elements, are in an AND relationship. Thus to control an actity that is covering purpose of both TREAT and HOPERAT, one rule with an .activity .purpose holding both TREAT and HOPERAT can define that rule. However this will not cover activities covering only TREAT, for that repeat at the .activity with just a .purpose of TREAT.

6.5.5 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
identifier token The unique id for a particular permission Permission.identifier
status token active | entered-in-error | draft | rejected Permission.status