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

The unique id for a particular permission

The activity actor mentioned in a permission rule (permit or deny).

The data period mentioned in a permission rule (permit or deny).

The data resource mentioned in a permission rule (permit or deny).

The element limits mentioned in a permission rule (permit or deny).

When the provisions of a Consent are encoded using a Permission, this extension is used to indicate the Permission from the Consent.

MyOrg current security roles

Codes identifying rule combining algorithm.

Codes identifying the lifecycle stage of a product.

The codes for Roles in MyOrg

Could possibly use the defined valueSet practitioner-role

Codes identifying the rule combining. See XACML Combining algorithms http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cos01-en.html

Codes identifying the lifecycle stage of a product.

This Permission has all the rules for the Directory.\n\nPermission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements. \n\nPresumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag\n\nThis Permission encodes:\n\n- combining rule is deny-unless-permit, ANY permit authorizes access, so rules do not need to be exhaustively processed, but if no permit is found then access is denied.\n- rule is #permit for administrative actions on the directory\n - This enables maintenance by those with directory admin authorization\n- rule is #permit for Treatment, Payment, and Operations\n - This enables workers to access all workers\n - BUT includes an .limit.tag to exclude any elements marked with Location Sensitivity (#LOCIS)\n- rule is #permit for Patient requested (#PATRQT)\n - permits access by patients (or authorized patient delegate)\n - BUT only Practitioners that have a PractitionerRole.code=#doctor\n - BUT includes an .limit.tag to exclude any elements marked with Location Sensitivity (#LOCIS)

This Permission has all the rules for the Patient Directory.\n\nPermission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements. \n\nPresumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag\n\nThis Permission encodes:\n\n- combining rule is deny-unless-permit, ANY permit authorizes access, so rules do not need to be exhaustively processed, but if no permit is found then access is denied.\n- rule is #permit for health directory use, patient requested, or family requested\n - This enables access all patients, provided Consent Permit is on file\n - BUT uses .limit.tag to exclude any elements marked with Religious Sensitivity (#REL)\n - Note that the Consent requirement is documented here with a .limit of NOAUTH. Might there be a better way?\n- rule is #permit for administrative actions on the directory\n - This enables maintenance by those with directory admin authorization

This Permission has all the rules for the Patient Directory.\n\nPermission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements. \n\nPresumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag\n\nThis Permission encodes:\n\n- combining rule is deny-unless-permit, ANY permit authorizes access, so rules do not need to be exhaustively processed, but if no permit is found then access is denied.\n- rule is #permit for health directory use, patient requested, or family requested\n - This enables access all patients, provided Consent Permit is on file\n - BUT uses .limit.tag to exclude any elements marked with Religious Sensitivity (#REL)\n - Note that the Consent requirement is documented here with a .limit of NOAUTH. Might there be a better way?\n- rule is #permit for administrative actions on the directory\n - This enables maintenance by those with directory admin authorization

Example of a Base Permission Imported in another Permission

Example of a Composite Permission that Imports Another Permission

Example Bundle with included Permission with residual restrictions

Consent by the patient to Deny access to the Patient Directory following the Patient Directory policy.

• Consent is by the Patient
• Deny
• policy Basis is the Permission describing patient directory rules

Consent by the patient to allow access to the Patient Directory following the Patient Directory policy.

• Consent is by the Patient
• Permit
• policy Basis is the Permission describing patient directory rules

Consent by the Clinician on behalf of the patient to allow access to the Patient Directory following the Patient Directory policy.

• Consent is by the Practitioner
• Permit
• policy Basis is the Permission describing patient directory rules

Where there is a Permission resource that describes the base policy, then a Consent can point at that Permission rather than a URL alone.

Some would prefer to use the Permission rule encoding, and not the Consent.provision; thus the Consent is used to capture the ceremony, and points at a Permission for the rules.

Example of permission

Example of simple directory admin allowing HR and IT

Example of authorizing some data in a directory but excluding sensitive elements

Dummy MeasureReport example for completeness sake. No actual use of this resource other than an example target that is NOT patient specific.

Dummy Organization example for completeness sake. No actual use of this resource other than an example target

Dummy patient example for completeness sake. No actual use of this resource other than an example target

This patient is the same as ex-patient, with the extension for religious affiliation.

Dummy Practitioner example. This Practitioner has has been de-sensitized from ex-practitioner-sensitive. Note that because the data has been redacted then .meta.security will have tag PROCESSINLINELABEL.

Dummy Practitioner example for completeness sake. No actual use of this resource other than an example target

Dummy Practitioner example. This Practitioner has some phone and address information that is tagged as sensitive location information. Note that because of this the Resource is tagged in .meta.security as having inline tags PROCESSINLINELABEL.

Fine Grained Patient Access to Data\nThis Permission allows access to Patient resources marked with a TAG_1, but would remove the .address, .birthDate, and .meta\nThis Permission denies access to Patient resources marked with a VIP\n\nTODO Jira FHIR-51070 for potential better way to identify type of resource

Permission allowing data authored by\n\nThere is a Consent that captures the consent ceremony and setting\n- status is active - so it should be enforced\n- scope is privacy \n- category is LOINC 59284-0 Consent\n- date indicated when the consent is recorded\n- patient is identified\n- performer is the patient\n- organization is identified\n- source indicate a DocumentReference (with included text of the policy)\n- policy url points at this Permission\n\nThis Permission encodes\n- base rule is #permit \n- base rule includes TPO so as to be clear this is a consent about TPO\n- Permits access to data authored by practitioner 1\n- Given that there is only one targeted permit rule, then nothing else is allowed.

Permission allowing data authored by\n\nThere is a Consent that captures the consent ceremony and setting\n- status is active - so it should be enforced\n- scope is privacy \n- category is LOINC 59284-0 Consent\n- date indicated when the consent is recorded\n- patient is identified\n- performer is the patient\n- organization is identified\n- source indicate a DocumentReference (with included text of the policy)\n- policy url points at this Permission\n\nThis Permission encodes\n- base rule is #permit \n- base rule includes TPO so as to be clear this is a consent about TPO\n- Permits access to data authored by practitioner 1\n- Given that there is only one targeted permit rule, then nothing else is allowed.

Permission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements. \n\nPresumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag

Permission allowing requested use, but restricting redisclosure\n\nThis Permission encodes\n\n- base rule is #permit\n- base rule includes TPO so as to be clear this is authorizes TPO\n- includes a residual (limit) using code NODSCLCDS

Permission allowing most sharing of data but NOT data authored by a practitioner\n\nThe Consent that captures the consent ceremony and setting:\n- status is active - so it should be enforced\n- scope is privacy \n- category is LOINC 59284-0 Consent\n- date indicated when the consent is recorded\n- patient is identified\n- performer is the patient\n- organization is identified\n- source indicate a DocumentReference (with included text of the policy)\n- policy url points at this Permission\n\nThis Permission encodes\n- base rule includes TPO so as to be clear this is a consent about TPO\n- second rule denying access to data authored by ex-practitioner\n - practitioner 1\n- nothing else is authorized by this Permission

Permission allowing most use of data but NOT a given practitioner\n\nThis Permission encodes\n- base rule includes TPO so as to be clear this generally authorizes TPO\n- second rule denying access to a given ex-practitioner\n - practitioner 1\n- nothing else is authorized by this Permission

Permission allowing most use of data but expires in a year. Note that this 'year' indication is based on absolute dates of issuing of the Permission, and use of Permission.validity.\n\nThis Permission encodes\n- base rule includes TPO so as to be clear this generally authorizes TPO\n- validity is a period of one year

As an overriding policy, this policy needs to express who can READ, who can CREATE, who can UPDATE, who can DELETE.

As an overriding policy, this policy needs to express who can READ, who can CREATE, who can UPDATE, who can DELETE.

As an overriding policy, this policy needs to express who can READ, who can CREATE, who can UPDATE, who can DELETE.

Admin

Dietician

Doctors

Janitor

Registration

Example of permission for SANER

Example of permission for VhDir