HL7 FHIR Implementation Guide: Data Access Policies, published by HL7 International / Security. This guide is not an authorized publication; it is the continuous build for version 1.0.0-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/data-access-policies/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
These define the properties by which a RESTful server can be searched. They can also be used for sorting and including related resources.
| PermissionIdentifierSearchParam |
The unique id for a particular permission |
||||
| PermissionRule-activity-actorSearchParam |
The activity actor mentioned in a permission rule (permit or deny). |
||||
| PermissionRule-data-periodSearchParam |
The data period mentioned in a permission rule (permit or deny). |
||||
| PermissionRule-data-resourceSearchParam |
The data resource mentioned in a permission rule (permit or deny). |
||||
| PermissionRule-limit-elementSearchParam |
The element limits mentioned in a permission rule (permit or deny). |
||||
| PermissionStatusSearchParam |
|
'Additional' resources that are not yet published in the FHIR core specification.
| Permission |
Permission resource holds access rules for a given data and access request context. |
These define sets of codes used by systems conforming to this implementation guide.
| Current Roles in MyOrg |
MyOrg current security roles |
| ValueSet for Permission Rule Combining |
Codes identifying rule combining algorithm. |
| ValueSet of Permission Status |
Codes identifying the lifecycle stage of a product. |
These define new code systems used by systems conforming to this implementation guide.
| MyOrg defined Roles CodeSystem |
The codes for Roles in MyOrg Could possibly use the defined valueSet practitioner-role |
| Permission Rule Combining |
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 |
| Permission Status |
Codes identifying the lifecycle stage of a product. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| Permission/ex-finegrained-patient-access | |
| Permission/ex-overriding-abac-by-tag | |
| Permission/ex-overriding-rbac-by-resource | |
| Permission/ex-overriding-rbac-by-role | |
| Permission/ex-permission-directory-admin | |
| Permission/ex-permission-directory-all | |
| Permission/ex-permission-directory-doctors-only | |
| Permission/ex-permission-directory-exclude-location | |
| Permission/ex-permission-intermediate-authoredby | |
| Permission/ex-permission-intermediate-not-authoredby | |
| Permission/ex-permission-not-bob | |
| Permission/ex-permission-patient-authoredby | |
| Permission/ex-permission-patient-directory-all | |
| Permission/ex-permission-redisclose-forbidden-without-consent | |
| Permission/ex-permission-timeout | |
| Permission/example | |
| Permission/example-base | |
| Permission/example-composite | |
| Permission/example-exclude | |
| Permission/example-saner | |
| Permission/example-vhdir | |
| Consent Deny for Patient Directory |
Consent by the patient to Deny access to the Patient Directory following the Patient Directory policy.
|
| Consent for Patient Directory |
Consent by the patient to allow access to the Patient Directory following the Patient Directory policy.
|
| Consent for Patient Directory by Clinican |
Consent by the Clinician on behalf of the patient to allow access to the Patient Directory following the Patient Directory policy.
|
| Consent that uses Overriding Permission for base 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. |
| Consent that uses Permission for rules |
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 |
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 |
Dummy Organization example for completeness sake. No actual use of this resource other than an example target |
| Dummy Patient example |
Dummy patient example for completeness sake. No actual use of this resource other than an example target |
| Dummy Patient example with Religion |
This patient is the same as ex-patient, with the extension for religious affiliation. |
| Dummy Practitioner de-sensitive example |
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 |
| Dummy Practitioner example |
Dummy Practitioner example for completeness sake. No actual use of this resource other than an example target |
| Dummy Practitioner sensitive example |
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 |
| PractitionerRole defining those that are Admin |
Admin |
| PractitionerRole defining those that are Dietician |
Dietician |
| PractitionerRole defining those that are Doctors |
Doctors |
| PractitionerRole defining those that are Janitor |
Janitor |
| PractitionerRole defining those that are Registration |
Registration |
These are resources that are used within this implementation guide that do not fit into one of the other categories.
| Permission-examples |
| Permission-operations |
| null (Bundle) |