The HL7 RBAC Permissions Catalog

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

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

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

4. In Order to Move Forward… • Select a starting Vocabulary • Use the Role-Engineering Process as a guideline • Create a draft catalog

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

6. Role Engineering Process Basics (Lightweight Process) 1. Identify and Model Usage Scenarios 2. Permission Derivation from Scenarios 3. Identification of Permission Constraints 4. Scenario Model Refinement 5. Definition of Tasks and Work Profiles 6. Derivation of a Preliminary Role-hierarchy 7. RBAC Model Definition

7. 1. Identify and Model Usage Scenarios 2. Permission Derivation from Scenarios 3. Identification of Permission Constraints

8. Privacy and Consent Scenario Example Pre-conditions Note: 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 Scenario A 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).

9. 1. Identify and Model Usage Scenarios 2. Permission Derivation from Scenarios 3. Identification of Permission Constraints

10. 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 Scenario A 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”}

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

13. 1. Identify and Model Usage Scenarios 2. Permission Derivation from Scenarios [Purpose of Use Identified] 3. Identification of Permission Constraints

14. 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 Scenario A 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

15. Consent and Privacy Vocabulary Confidentiality Related To Health InformationAccess 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 confidentialityrules (according to good health care practice) apply, that is, only authorized individuals with a legitimate medical or business need may access this item.

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

17. Confidentiality Modifier • Celebrity (C) • Taboo (T) • Sensitive (S)

18. 1. Identify and Model Usage Scenarios 2. Permission Derivation from Scenarios [Purpose of Use Identified] 3. Identification of Permission Constraints

20. Policy Decision Point (PDP) Given the conditions: Do we grant [Permission] access?

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

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