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

A unique identifier assigned to this permisssion.

Allows permission to be distinguished and referenced.

Status.

The person or entity that asserts the permission.

The date that permission was asserted.

The period in which the permission is active.

The asserted justification for using the data.

This would be a codeableconcept, or a coding, which can be constrained to , for example, the 6 grounds for processing in GDPR.

Justifing rational.

While any resource may be used, DocumentReference, Consent, PlanDefinition, and Contract would be most frequent

Defines a procedure for arriving at an access decision given the set of rules.

see XACML Combining Rules

A set of rules.

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

deny | permit.

A description or definition of which activities are allowed to be done on the data.

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 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.

Explicit FHIR Resource references.

How the resource reference is interpreted when testing consent restrictions.

A reference to a specific resource that defines which resources are covered by this consent.

The data in scope are those with the given codes present in that data .meta.security element.

Note the ConfidentialityCode vocabulary indicates the highest value, thus a security label of "R" then it applies to all resources that are labeled "R" or lower. E.g. for Confidentiality, it's a high water mark. For other kinds of security labels, subsumption logic applies. When the purpose of use tag is on the data, access request purpose of use shall not conflict.

Clinical or Operational Relevant period of time that bounds the data controlled by this rule.

This has a different sense to the .validity.

Used when other data selection elements are insufficient.

A description or definition of which activities are allowed to be done on the data.

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 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.

The actor(s) authorized for the defined activity.

Actions controlled by this Rule.

Note that this is the direct action (not the grounds for the action covered in the purpose element). At present, the only action in the understood and tested scope of this resource is 'read'.

The purpose for which the permission is given.

What limits apply to the use of the data.

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.