Bundle includes an imposed Permission

Permission with the extension for K-Anonymity

Adds the PermissionResourceType extension to Permission.rule.data

When a limit needs to impose a specific K-Anonymity value.

When a Bundle carries a Permissiont that must be enforced

When defining a Permission.rule where the data is a type of resource. Note that this might be possible with Expression, but I don't know how.

When a Permission permits data, some of the elements of that data may need to be excluded. For example when exposing Practitioner resources to a Patient, the patient should not be given access to the Practitioner Home address and Phone. These elements would be tagged with a given security sensitivity tag, and this extension would indicate to exclude that given tagged data.

MyOrg current security roles

The codes for Roles in MyOrg

Could possibly use the defined valueSet practitioner-role

This Permission has enables administrative changes to the Directory

• rule is #permit for administrative actions on the directory
  • This enables maintenance by those with directory admin authorization

This Permission has all the rules for the Directory.

Permission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements.

Presumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag

This Permission encodes:

• 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.
• rule is #permit for administrative actions on the directory
  • This enables maintenance by those with directory admin authorization
• rule is #permit for Treatment, Payment, and Operations
  • This enables workers to access all workers
  • BUT includes an exclusion extension for any elements marked with Location Sensitivity (#LOCIS)
• rule is #permit for Patient requested (#PATRQT)
  • permits access by patients (or authorized patient delegate)
  • BUT only Practitioners that have a PractitionerRole.code=#doctor
  • BUT includes an exclusion extension for any elements marked with Location Sensitivity (#LOCIS)

This Permission has all the rules for the Patient Directory.

Permission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements.

Presumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag

This Permission encodes:

• 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.
• rule is #permit for health directory use, patient requested, or family requested
  • This enables access all patients, provided Consent Permit is on file
  • BUT includes an exclusion extension for any elements marked with Religious Sensitivity (#REL)
  • Note that the Consent requirement is documented here with a .limit of NOAUTH. Might there be a better way?
• rule is #permit for administrative actions on the directory
  • This enables maintenance by those with directory admin authorization

Permission allowing patient requested access to Practitioners, but protects the Practitioner sensitive location elements.

Presumes Practitioner resources are tagged at the element level following DS4P Inline Security Labels that indicate the sensitive location elements using the LOCIS tag

This alternative uses two rules, and leverages the combining algorithm

1. Allow Patient requested access
2. Disallow access to any data tagged with LOCIS

Using combining alrithm, the second rule applies to any otherwise permitted access. So it does need to be carefully combined with other permits such as permitting doctors full access to doctors.

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

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.

Permission in a SearchSet Bundle

Permission allowing data authored by

There is a Consent that captures the consent ceremony and setting

• status is active - so it should be enforced
• scope is privacy
• category is LOINC 59284-0 Consent
• date indicated when the consent is recorded
• patient is identified
• performer is the patient
• organization is identified
• source indicate a DocumentReference (with included text of the policy)
• policy url points at this Permission

This Permission encodes

• base rule is #permit
• base rule includes TPO so as to be clear this is a consent about TPO
• Permits access to data authored by practitioner 1
• Given that there is only one targeted permit rule, then nothing else is allowed.

Permission allowing data authored by

There is a Consent that captures the consent ceremony and setting

• status is active - so it should be enforced
• scope is privacy
• category is LOINC 59284-0 Consent
• date indicated when the consent is recorded
• patient is identified
• performer is the patient
• organization is identified
• source indicate a DocumentReference (with included text of the policy)
• policy url points at this Permission

This Permission encodes

• base rule is #permit
• base rule includes TPO so as to be clear this is a consent about TPO
• Permits access to data authored by practitioner 1
• 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.

Presumes 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

This Permission encodes

• base rule is #permit
• base rule includes TPO so as to be clear this is authorizes TPO
• includes a residual (limit) using code NODSCLCDS

Permission allowing most sharing of data but NOT data authored by a practitioner

The Consent that captures the consent ceremony and setting:

• status is active - so it should be enforced
• scope is privacy
• category is LOINC 59284-0 Consent
• date indicated when the consent is recorded
• patient is identified
• performer is the patient
• organization is identified
• source indicate a DocumentReference (with included text of the policy)
• policy url points at this Permission

This Permission encodes

• base rule includes TPO so as to be clear this is a consent about TPO
• second rule denying access to data authored by ex-practitioner
  • practitioner 1
• nothing else is authorized by this Permission

Permission allowing most use of data but NOT a given practitioner

This Permission encodes

• base rule includes TPO so as to be clear this generally authorizes TPO
• second rule denying access to a given ex-practitioner
  • practitioner 1
• 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.

This Permission encodes

• base rule includes TPO so as to be clear this generally authorizes TPO
• 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.

Permission allowing use of data but requires exposure meet a given k-anonymity value.

This Permission encodes

• base rule includes Research so as to be clear this generally authorizes Research
• validity is a period of one year

Permission allowing patient requested access to Practitioners, BUT only Practitioners that have a PractitionerRole.code=#doctor

Admin

Dietician

Doctors

Janitor

Registration

Read-Only access to SANER report is authorized for PurposeOfUse of Public-Health compliance, from the Organizations. Access requests authorized shall be recorded.