The HL7 RBAC Permissions Catalog

The current HL7 RBAC Permission Catalogue provides a minimal interoperability vocabulary of standard attributes allowing authorization decisions for clinician access to healthcare workflow.

Because of this focus on clinical workflow, and the lack of an attached Constraint Catalog as required by the role-engineering process, implementation of the current HL7 RBAC Permission Catalogue vocabulary suffers from the following shortcomings.

Shortcomings of the HL7 RBAC Permissions Catalog

• a) Financial. The permission vocabulary does not contain financial attributes (actions and objects) needed to control access to financial information

• b) Security Constraint Catalog. The vocabulary does not contain a security-oriented constraint catalog required by the role-engineering process. In particular, there is no mechanism to express time, location, cardinality and other separation-of-duty policy constraints typical of a healthcare environment.

• c) Privacy and Consent Catalog. The vocabulary does not contain a patient privacy and consent-oriented constraint vocabulary capable of enforcing patient consent directives or personal preferences.

• d) Definitions. The vocabulary definitions of terms could be improved by more closely linking them to standard HL7 definitions where they exist.

• e) Security and Privacy Framework. Since the vocabulary was conceived as a minimal vocabulary for clinician interoperability, it lacks a framework for including additional terms (actions and objects) in areas such as medical symptoms (diseases), messaging, structural roles that may also be subject to a healthcare security policy.

Privacy and Consent Catalog

The current RBAC Permission Catalog vocabulary does not contain a patient privacy and consent-oriented constraint vocabulary capable of enforcing patient consent directives or personal preferences.

In Order to Move Forward…

• Select a starting Vocabulary• Use the Role-Engineering Process as a

guideline• Create a draft catalog

Vocabulary

• The desire is to use an [HL7] accepted, standardized vocabulary (rather than create a new one)

• Vocabularies introduced include:– SNOMED CT– ICD-9, ICD-10– LOINC– RadLex, etc

Role Engineering Process Basics

(Lightweight Process)1. Identify and Model Usage Scenarios2. Permission Derivation from Scenarios3. Identification of Permission Constraints4. Scenario Model Refinement5. Definition of Tasks and Work Profiles6. Derivation of a Preliminary Role-hierarchy7. RBAC Model Definition

1. Identify and Model Usage Scenarios2. Permission Derivation from Scenarios3. Identification of Permission Constraints

Privacy and Consent Scenario Example

Pre-conditionsNote: Depending on whether the information is structured or unstructured, masking personal health

records may be applied at document level, or on document sections. Structured information and coded information may be masked or filtered at the data element level. Unstructured information can only be filtered or masked at the document or document section level.

• A patient through the consent directive may be able to exclude or include specific types of users of personal health records based on various criteria (e.g. exclude a physician who happens to have a personal relationship a certain role within the provider organization).

Basic ScenarioA provider requests a patient's health record in order to provide care to the patient. The information may

provided in the form of structured or unstructured clinical documents.

Note: A provider's role is based on their relationship to the patient and their role within the organization. For example, a member of the immediate care team may be a physician, nurse practitioner, etc.. These users may be allowed to see and update the personal health records while other clinicians (e.g. laboratory medical technicians, consulting physicians, etc.) will be allowed access only to the information intended for their use (e.g. laboratory order or consult request).

1. Identify and Model Usage Scenarios2. Permission Derivation from Scenarios3. Identification of Permission Constraints

Permission Derivation from Scenarios

A patient through the consent directive may be able to exclude or include specific types of users of personal health records based on various criteria (e.g. exclude a physician who happens to have a personal relationship a certain role within the provider organization).

Basic ScenarioA provider requests a patient's health record in order to provide care to the patient. The

information may provided in the form of structured or unstructured clinical documents.

Note: A provider's role is based on their relationship to the patient and their role within the organization. For example, a member of the immediate care team may be a physician, nurse practitioner, etc.. These users may be allowed to see and update the personal health records while other clinicians (e.g. laboratory medical technicians, consulting physicians, etc.) will be allowed access only to the information intended for their use (e.g. laboratory order or consult request).

{action, object} = {Read, Create, Update…, patient health record “Inpatient Order”}

Purpose of Use (examples)

• Use or disclosure of Psychotherapy Notes.• Uses and disclosures about decedents.• Uses and disclosures for cadaveric organ, eye or

tissue donation purposes.• Uses and disclosures for health oversight activities.• Uses and disclosures for public health activities.• Uses and disclosures for research purposes. • Etc…

1. Identify and Model Usage Scenarios2. Permission Derivation from Scenarios

[Purpose of Use Identified]3. Identification of Permission Constraints

Identification of Permission Constraints

A patient through the consent directive may be able to exclude or include specific types of users of personal health records based on various criteria (e.g. exclude a physician who happens to have a personal relationship a certain role within the provider organization).

Basic ScenarioA provider requests a patient's health record in order to provide care to the patient. The

information may provided in the form of structured or unstructured clinical documents.

Note: A provider's role is based on their relationship to the patient and their role within the organization. For example, a member of the immediate care team may be a physician, nurse practitioner, etc.. These users may be allowed to see and update the personal health records while other clinicians (e.g. laboratory medical technicians, consulting physicians, etc.) will be allowed access only to the information intended for their use (e.g. laboratory order or consult request).

Constraint to {create, read, update, etc ; “Inpatient Order”} include: Heath Information Access restrictions due to/for: Patient Consent Directive, Direct Care

Provider, Sensitive Data

Consent and Privacy VocabularyConfidentiality Related To Health Information Access restrictions

placed on a record of health information

• Clinician (D) - Only clinicians may see this item, billing and administration persons cannot access this item without special permission.

• Individual (I) - Access only to individual persons who are mentioned explicitly as actors of this service and whose actor type warrants that access (cf. to actor type code).

• Normal (N) Normal confidentiality rules (according to good health care practice) apply, that is, only authorized individuals with a legitimate medical or business need may access this item.

Consent and Privacy Vocabulary (cont.)

– R restricted Restricted access to a record. • RD Restricted by provider • CDA Restricted by consent directive• MA Masked access • FMA Flagged Masked access • L Locked access • SSA Shared secret access • RBA Role-based access • CT Care team access • DCR Direct care provider access• UBA User based access • CBA Context based access • V very restricted

Confidentiality Modifier

• Celebrity (C)• Taboo (T)• Sensitive (S)

1. Identify and Model Usage Scenarios2. Permission Derivation from Scenarios

[Purpose of Use Identified]3. Identification of Permission Constraints

Policy Decision Point (PDP)

Given the conditions:

Do we grant [Permission] access?

Collect and Document

Identification of Permission Constraints

As Scenarios are developed, collect and document Privacy and Consent constraints

(Assign each Constraint a unique identifier)

Maintain collection in a spreadsheet / database = PERMISSION CONSTRAINT CATALOG for Privacy

and Consent

Constraint Catalog Example

Click on link above to view Constraint Catalog Example (you may need to expand the spreadsheet to see all the cells of the catalog)

Constraint Catalog Example