Your SlideShare is downloading. ×
HL7_RBAC_Constraint_Catalog_v1.39_POST_reconciliation_JAN_2010.d ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

HL7_RBAC_Constraint_Catalog_v1.39_POST_reconciliation_JAN_2010.d ...

239
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
239
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Role Based Access Control (RBAC) Constraint Catalog Version 1.39 January 2010
  • 2. HL7 RBAC Constraint Catalog v1.39 January 2010 Page ii REVISION HISTORY Date Version Description By 04/28/2008 1.0 Initial Draft (based on VA Constraint Catalog Suzanne Gonzales-Webb 05/01/2008 1.1 QA review / revision Craig Winter 09/30/2008 1.2 Update Suzanne Gonzales-Webb 10/01/2008 1.3 QA review / revision Craig Winter 06/30/2009 1.32 Update in preparation for ballot Suzanne Gonzales-Webb 07/02/2009 1.33 QA review / revision Craig Winter 07/07/2009 1.34 Addition of comments from Security WG Suzanne Gonzales-Webb 07/08/2009 1.35 QA review / revision Craig Winter 07/12/2009 1.36 Addition of comments from Security WG Suzanne Gonzales-Webb 07/13/2009 1.37 QA review / revision Craig Winter 02/18/2010 1.38 QA review / revision Craig Winter 02/23/2010 1.39 January 2010 Approved Ballot Updates Suzanne Gonzales-Webb H E A L T H I N F O R M A T I O N
  • 3. HL7 RBAC Constraint Catalog v1.39 January 2010 Page iii Table of Contents Section Page 1 INTRODUCTION .........................................................................................................................1 2 CONTEXT CONSTRAINTS..........................................................................................................9 2.1 Static and Dynamic Constraints ...............................................................................................9 2.2 Endogenous and Exogenous Constraints ................................................................................10 2.3 Authorization and Assignment Constraints .............................................................................11 3 PURPOSE OF USE (POU)...........................................................................................................12 4 PATIENT PRIVACY AND CONFIDENTIALITY CONSTRAINTS..............................................14 5 CONSTRAINT PROCESS...........................................................................................................16 5.1 Assumptions ........................................................................................................................16 5.2 High-Level View of the Constraint Process............................................................................16 5.2.1 Model Interrelations ......................................................................................................16 5.3 Process Steps [Neumann/Strembeck] .....................................................................................18 5.3.1 Identification of Permission Constraints [Neumann/Strembeck 4.3]..................................18 6 CONSTRAINT TABLE...............................................................................................................20 List of Tables Table Page Table 1: Definitions ...........................................................................................................................4 Table 2: Permission Constraint Catalog Example................................................................................26 List of Figures Figure Page Figure 1: Interrelations of Scenario Model and Documents..................................................................17 Figure 2: RBAC Permission with Context Constraint..........................................................................18 Figure 3: XACML Components.........................................................................................................29 Figure 4: Using SAML 2.0 to transport XACML................................................................................31 List of Appendices Appendix Page Appendix A: Additional Context Constraints......................................................................................21 Appendix B: Constraints Associated with Permissions Example ..........................................................25 Appendix C: Healthcare Information Technology Standards Panel (HITSP).........................................28 Appendix D: References ...................................................................................................................32
  • 4. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 1 1 Introduction Role-Based Access Control or RBAC is a method to control access to resources on an information system. It was developed to overcome the complexities of managing individual user permissions and their assignments.i Access control and authorization services ensure that people, computer systems, and software applications can use only those resources (e.g., files, directories, computers, networks) that they are authorized to use and then only for approved purposes. Access controls protect against unauthorized use, disclosure, modification, and destruction of resources and unauthorized issuing of system commands. [HITSP] The intent of this document is to introduce a process to introduce constraints upon identified healthcare permissions as presented in the HL7 RBAC Permission Catalog, a normative HL7 standard. Future iterations of this constraint document may introduce constraints as applied to structural roles and possibly functional roles. This document presents an overview of constraint types and introduces permission constraint identification using a proposed high level process. The licensed and certified healthcare provider healthcare permissions cited are derived from the HL7 RBAC Healthcare Permission Catalog tables. Future updates may include healthcare permissions that may be assigned to non-licensed healthcare personnel. Constraints are restrictions (conditions or obligations) that are enforced upon access permissions. In RBAC, a constraint may restrict for example, a user to continue to have an action or operation on the data they are accessing. This could include contextual properties such as separation of duties, time-dependency, mutual exclusivity, cardinality, location, etc. More recent documentation also includes in the healthcare realms, the addition of patient consent and confidentiality codes1 directed toward patient specific privacy issues in accessing Electronic Healthcare Record (EHR) and/or Personal Healthcare Record (PHR) information. For the complex healthcare environments, constraints provide the higher flexibility required in RBAC implementation (see [Neumann-Strembeck]). Examples of contextual constraints could include access restriction of:  Lab Technician vs. Lab Technician Supervisor (separation of duties),  Head Nurse on a hospital floor at any given time (cardinality of 1, time- dependency),  Chief of Staff (cardinality of 1),  Provider’s access to a remote hospital that is not his/her primary workplace (location), and 1 Document links, examples can be found on the HL7 Community Based Collaborative Care WiKi main page: http://wiki.hl7.org/index.php?title=Community-Based_Collaborative_Care
  • 5. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 2  A physician working scheduled clinic hours (time-dependency) vs. physician working in a 24 hour Emergency Room (no time-dependency). With respect to access control, one has to ask first which parts of these unmanageable quantities of context information are relevant for a specific authorization decision, and how the corresponding information may be elicited and defined on the modeling level. In this document we suggest a process for the specification of context constraints. This process is based as an extension to the scenario-driven role engineering process for RBAC roles presented in Neumann and Strembeck [2002]. Prior to describing the engineering of context constraints in detail, we give some background information concerning the scenario-driven role engineering process. In Role-Based Access Control, users (i.e., individuals or authorization services, etc.) are given a set of permissions - the ability to have an operation (create, read, write, etc.) on an object (a laboratory order, progress note, etc.). In a healthcare environment arena however, flexibility in RBAC is necessary as the duties and functions of identified structural rolesii such as a physician, nurse or pharmacist2 in relation to accessing an information system can vary on the time of day, their location (i.e., clinic, ward) and assignment of additional temporary duties (i.e., supervisory or administrative). These conditional changes or constraints modify the level of access control an individual user may have. One possibility to deal with this dynamically changing context is to rapidly modify permission assignment relations according to the changes in the [healthcare] environment. This central idea supports constraints on almost all parts of an RBAC model (e.g., permissions, roles, or assignment relations) to achieve a high flexibility.iii Using the Context Constraint examples above, permission constraints could include:  Head Nurse permission functions can be accessed only by one Registered Nurse per 12-hour shift on a hospital floor at any given time (cardinality of 1, time- dependency);  Only one Physician may have access to the Chief of Staff permissions (cardinality of 1);  A laboratory user can co-sign another Lab Technician’s results, but cannot co- sign their own even if logged on as the Lab Technician Supervisor (separation of duties);  A Provider’s access to a remote hospital that is not his/her primary workplace is given limited permission access in order to treat a visiting patient (location);  A physician working scheduled clinic hours (time-dependency) vs. physician working in a 24 hour Emergency Room (no time-dependency); and 2 Structural roles are categories of healthcare personnel warranting differing levels of access control. Structural roles allow a user to ‘connect’ to a resource, but do not grant authorization. Structural roles define what specific healthcare workflow users are allowed to participate in, while functional roles define authorizations granted to an entity to allow access (i.e., to protected health information).
  • 6. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 3  Provider access to only a portion of a patient’s sensitive data (as indicated in a patient’s consent directive). In the scenario-driven role engineering process usage, scenarios of an information system are used to derive permissions and to define tasks. In general, a scenario describes an operation and event sequence (“object”), for example, to register a new patient in a hospital information system. Each scenario consists of several steps, and a subject performing a scenario must possess all permissions that are needed to complete the different steps of the scenario. In turn, a task consists of one or more scenarios, and tasks are combined to form work profiles. A work profile comprises all tasks that a certain role (functional role) is allowed to perform. In a hospital environment different work profiles for physicians, nurses, and clerks are needed, for instance. In the role engineering process, work profiles are then used together with the permission catalog and the constraint catalog to define a concrete RBAC model. The scenario-driven approach described in Neumann and Strembeck [2002] only provides general guidance for the sub-process of defining (exogenous) constraints. This fact and our aim to specify and enforce context constraints in an RBAC environment led us to the definition of the process extension proposed in this section. [Neumann-Strembeck] Constraints are restrictions that are enforced upon access permissions According to Neumann and Strembeck,iv “A context constraint is defined as a dynamic RBAC constraint that checks the actual values of one or more contextual attributes for pre-defined conditions. If these conditions are satisfied, the corresponding access request can be permitted. Accordingly, a conditional permission is an RBAC permission that is constrained by one or more context constraints.” Thus, constraints are restrictions that are enforced upon access permissions. They can include contextual properties such as separation of duties, time- dependency, mutual exclusivity, cardinality, location, etc. Context constraints are used to define conditional permissions. The conditions to be satisfied can be either positive (e.g., “…location is ward”) or negative (e.g., “…the location is not Texas”). In the first instance if the location is “ward,” then access is granted, otherwise access from all other locations is denied. In the second instance, all locations will be granted access except for “Texas.” Table 1 lists definitions of terms used in this document.
  • 7. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 4 Table 1: Definitionsv vi Term Definition Source Authorization Constraint A general constraint that places additional controls on access control decisions. Adapted from [Strembeck- Neumann] Assignment Constraint A constraint that controls the assignment or activation of permissions and roles. Adapted from [Strembeck- Neumann] Cardinality Cardinality occurs when there is a limit to the certain number of roles (users, people, etc.) who may be holding permission at any one time. The number of times a role may be repeated within an individual occurrence of a class; the minimum and maximum number of occurrences of the role. Core HL7 Glossary Conditional Permission An RBAC permission that is constrained by one or more context constraints. Adapted from [Strembeck- Neumann] Consents Consents are permissions that are more likely to apply to recipients of personal health records. “I consent that providers may access and use my records for treatment.” Deemed Consent:In the context of a statutory requirement, means that it does not matter whether the patient/person has actually consented; the law permits organizations to act as if the patient/person has consented; there is no right to withdraw or withhold consent. Expressed Consent:A voluntary agreement with what is being done or proposed that is unequivocal and does not require any inference on the part of the organization seeking consent. Implied Consent:A voluntary agreement with what is being done or proposed that can be reasonably determined through the actions or inactions of the patient/person. Definitions from ISO/IEC WD 29101.2
  • 8. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 5 Term Definition Source Context Constraint A context constraint is a clause containing one or more context conditions. A dynamic RBAC constraint that checks the actual values of one or more contextual attributes for predefined conditions. It is satisfied if (if and only if) all its context conditions hold. Context constraints are used to define conditional permissions. [In an RBAC environment], a context constraint is defined through the terms context attribute, context function, and context condition: —A context attribute represents a certain property of the environment whose actual value might change dynamically (like time, date, or session-data for example) or which varies for different instances of the same abstract entity (e.g., location, ownership, birthday, or nationality). Context attributes are a means to make (exogenous) context information explicit. —A context function is a mechanism to obtain the current value of a specific context attribute (i.e., to explicitly capture context information). For example, a function date () could be defined to return the current date. A context function can of course also receive one or more input parameters. For example, a function age(subject) may take the subject name out of the _subject, operation,object_ triple to acquire the age of the subject, which initiated the current access request (e.g.,the age can be read from some database). —A context condition is a predicate (a Boolean function) that consists of an operator and two or more operands. The first operand always represents a certain context attribute, while the other operands may be either context attributes or constant values. All variables must be ground before evaluation. Therefore,each context attribute is replaced with a constant value by using the corresponding context function prior to the evaluation of the respective condition. Adapted from [Strembeck- Neumann] Dissents Dissents are restriction(s) applied to PHR that apply to recipients of personal health records. “I do not allow administrators and payers to access my restricted information (e.g., substance abuse, mental health) for payment purposes.” NEED SOURCE Directives Directives are commands that more likely apply to sources of information and providers: “A specific provider may not create an official record for me” “Any provider shall add new information to my PHR once the episode of care is completed.” NEED SOURCE Dynamic Constraint A constraint that must be checked at runtime according to the actual values of specific attributes or with respect to characteristics of the current session to determine access control. Adapted from [Strembeck- Neumann]
  • 9. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 6 Term Definition Source Endogenous Constraint A constraint that completely relates to intrinsic properties of an RBAC model and inherently affects the structure and construction of a concrete instance of an RBAC model. Adapted from [Strembeck- Neumann Exogenous Constraint A constraint that either exclusively involves attributes that are not in the core RBAC model or which refer to external attributes of a specific RBAC model element. Adapted from [Strembeck- Neumann Location A constraint on the location for the user holding the permission. Adapted from [Strembeck- Neumann] Mutual Exclusivity A constraint that limits the types of roles a user may have during a certain time period. Two mutual exclusive roles must never be assigned to the same subject simultaneously, as specified in static separation of duty (SSD) constraints. In dynamic separation of duty constraints which define that two mutual exclusive roles must never be activated simultaneously within the same user session, or time constraints which restrict role activation to a specific time interval (e.g., from 8 a.m. to 8 p.m.). Adapted from [Strembeck- Neumann] Object An object is an entity that contains or receives information. The objects can represent information containers (e.g.,files or directories in an operating system, and/or columns, rows,tables, and views within a database management system) or objects can represent exhaustible system resources,such as printers, disk space, and CPU cycles. The set of objects covered by RBAC includes all of the objects listed in the permission catalog that are assigned to roles. [ANSI-RBAC]
  • 10. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 7 Term Definition Source Operation An operation is a capability provided by a currently executing program (i.e., an executable image) which upon invocation executes some function for the user. Within a file system, operations might include read,write, and execute. Within a database management system, operations might include insert, delete, append, and update. Basic Permission Name Operations: A = Append C = Create D = Delete 3 E = Execute R = Read U = Update Please see the HL7 RBAC Permission Catalog for additional operation executables. [ANSI-RBAC] Permission Permission is an approval to perform an operation on one or more RBAC protected objects. [ANSI-RBAC] Purpose of Use Purpose of Use defines the policy set to be used in situations where multiple (potentially conflicting) contextually sensitive policies exist for identical users and identical information objects. Purpose of use (Security). A qualifier used to identify or partition security policy, in particular as a means to identify the applicable security set that applies to the current request. Purpose of use (Privacy). A qualifier used to partition patient preferences and consent directives for patient convenience in defining their policies. Permission is an approval to perform an operation on one or more RBAC protected objects. NEED SOURCE Separation of Duties A constraint which prohibits a user from being assigned two roles simultaneously. Adapted from [Strembeck- Neumann] PersonalHealth Record An electronic record (not a computer system) of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared,and controlled by the individual. NEED SOURCE Static Constraint A constraint that can be evaluated in advance of the role based access request and remains constant over a given time period. Adapted from [Strembeck- Neumann] 3 In some healthcare systems information is not deleted. In cases such as this, the term ‘addend’ can be used.
  • 11. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 8 Term Definition Source Time Dependency A constraint based on an attribute of time. Adapted from [Strembeck- Neumann] Masking Description of the process of restricting an access to or transfer of Patient Identifiable Information (PII). NOTE:Typically, masking is applied at the data source and may be overridden, as permitted by law, by the accessing custodian (e.g., in emergency health situations). ISO/IEC WD 29101.2 No consent In the context of a statutory requirement, means that consent is not required for a particular purpose. ISO/IEC WD 29101.2 Substitute Decision Maker (SDM) In relation to a patient/person, means, unless the context requires otherwise, a person who is authorized under legislation to consent on behalf of the patient/person to the collection, use or disclosure of personally identifiable information about the patient/person. NEED SOURCE
  • 12. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 9 2 Context Constraints A context constraint specifies that certain context attributes must meet certain conditions in order to permit a specific operation. A context constraint is defined (and primarily used) as a dynamic exogenous authorization constraint. From Neumann and Strembeck, “a context constraint is defined through the terms context attribute, context function, and context condition: —A context attribute represents a certain property of the environment whose actual value might change dynamically (like time, date, or session-data for example) or which varies for different instances of the same abstract entity (e.g., location, ownership, birthday, or nationality). Thus, context attributes are a means to make (exogenous) context information explicit. —A context function is a mechanism to obtain the current value of a specific context attribute (i.e., to explicitly capture context information). For example, a function date could be defined to return the current date. Of course a context function can also receive one or more input parameters. For example, a function age(subject) may take the subject name out of the _subject, operation, object_ triple to acquire the age of the subject, which initiated the current access request (e.g., the age can be read from some database). —A context condition is a predicate (a Boolean function) that consists of an operator and two or more operands. The first operand always represents a certain context attribute, while the other operands may be either context attributes or constant values. All variables must be ground before evaluation. Therefore, each context attribute is replaced with a constant value by using the corresponding context function prior to the evaluation of the respective condition. A context constraint is a clause containing one or more context conditions. It is satisfied if (if and only if) all its context conditions hold.” Neumann and Strembeck state that constraints in general have multiple dimensions. As such, constraints can be static or dynamic; exogenous or endogenous; and authorization or assignment. These different dimensions are explained in this section. 2.1 Static and Dynamic Constraints A static constraint refers to constraints that can be evaluated directly at the design time of an RBAC model (i.e., static separation of duties or SSD). Static separation of duty requirements can be enforced in the administration environment. For this reason, assignments that should never occur can thus be prohibited. It has been pointed out that this feature can be very restrictive to business operations, especially in smaller organizations. However, it may still prove useful in cases where business rules that span an entire organization and stay constant over time must be expressed.
  • 13. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 10 Example: Two mutually exclusive roles must never be assigned to the same subject simultaneously (i.e., as above wherein the roles of a Physician and a Pharmacist should not be accessed simultaneously by the same user). A dynamic constraint can only be checked at runtime according to the actual values of specific attributes or with respect to characteristics of the current session (i.e., dynamic separation of duties or time constraints). The objective behind dynamic separation of duty is to allow more flexibility in operations. Consider the case of initiating and authorizing payments. A static policy could require that no individual who can serve as payment initiator could also serve as payment authorizer. Example: A physician can enter a progress note but it will not be seen on the patient’s electronic health record until the author signs the progress note. 2.2 Endogenous and Exogenous Constraints [Neumann-Strembeck] Endogenous constraints inherently affect the structure and construction of a concrete instance of an RBAC model. These constraints influence the definition of the respective role-hierarchy since they further prohibit those two distinct roles to which permissions are assigned can have a common senior role. Otherwise a common senior could acquire both (mutual exclusive) permissions and thereby violate the corresponding static separation of duties constraint.  Cardinality occurs when there is a limit of a certain number of people who may be holding the permission at any one time. Example: At any given time per floor/unit, only one RN (user with permissions as a registered nurse) may hold the permission of charge nurse.  Separation of duties occurs when the same person cannot hold two related permissions at the same time. Example: A user with Staff RN permissions vs. a user with permissions as an RN supervisor. Exogenous constraints are constraints that apply to attributes that do not belong to the core elements of an RBAC model, but are defined as “side conditions” for certain operations or decisions of an access control service. These include time constraints that restrict role activation to a specific time internal, or allow access operations for a particular resource only on a specific weekday.  Time-dependency creates a time of day/time dependence on the person holding the permission. Example: A person with banker permission can only e-sign money vouchers during regular business hours 9-5 (or a physician working in a clinic w/‘set hours’). An example of no time-dependency is a physician working in the ER.
  • 14. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 11 Example: An RN with Pharmacy privileges outside of regular Hospital Pharmacy Hours. At some sites, an RN may assume pharmacist ‘review order’ privileges (i.e., accepting an entered physician order to allow it to dispense) so that a patient may receive the medication - only during after hours (time) when the pharmacy is closed (pharmacist is not available).  Location creates a location requirement for the person holding the permission. Example: Physician or provider access to a remote hospital which is not their primary workplace. Example: An emergency room physician who covers another physician’s shift/duty call during low patient census at multiple locations. A Physician’s Assistant (PA) may be physically present, but the emergency room physician must co-sign or accept the PA order at the remote location in order for the order to process. 2.3 Authorization and Assignment Constraints Beside the categorization as static/dynamic and endogenous/exogenous, constraints can also be subdivided into authorization constraints and assignment constraints: —Authorization constraints are constraints that place additional controls on access control decisions. Thus, even if a subject is in possession of a permission that grants a certain access request, the access can only be allowed if the corresponding authorization constraints are fulfilled at the same time. For example, such constraints can be applied to implement access control policies based on access histories, as in Chinese Wall4 policies for instance. —Assignment constraints are constraints that control the assignment or activation of permissions and roles (e.g., maximum and minimum cardinalities or separation of duty constraints). On the source code level, assignment constraints may be implemented through the same means as applied for authorization constraints (e.g., as an authorization constraint on the “assign role” or “activate role” permission). We think, however, that it is sensible to discriminate assignment and authorization constraints on the design level since both types address distinguishable intentions when engineering an RBAC policy. [Neumann-Strembeck] 4 http://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/brewer_nash_89.pdf
  • 15. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 12 3 Purpose of Use (POU) As a topic, purpose of use has recently reemerged. Originally, purpose of use was envisioned as a means of partitioning (healthcare) policy for the purpose of general rulemaking. Recently the topic has come up again, as a means of partitioning security policy needed for data sharing between organizations within business partner or Data Use and Reciprocal Support (DURSA) agreements. Mechanisms must be available to ensure that access to protected information objects is only granted to properly authorized users under a specific and unambiguous security policy. Increasingly, this problem has become not only one of determining that a user has rights to the information objects, but also that the context in which these rights are asserted is the correct one. For example, the security policy may require that clinical users access data within a clinical context where clinical application security policies apply, rather than under an administrative role which may not have these constraints (allowing enforcement of separation of duties). In general, this problem is referred to as “Purpose of Use.” Purpose of use in relation to permission constraints, provides context to requests for information resources. Each purpose of use should be unique to a specific claim, and will establish the context for other security and privacy attributes. Within a claim, all other claims and assertions must be bound to the purpose of use. Purpose of use allows the service to consult its policies to determine if the user’s claims meet or exceed those needed for access control. For example, a patient’s consent directive under normal conditions will include objects, confidentiality codes and policy attributes which may be much different from those in an emergency. Consent directives specific to a purpose of use allows both the patient and the system enforcing access control to share a common context and vocabulary for requirements, claims and policy enforcement that provides for interoperability of both security and privacy enforcement. The following list of healthcare related purposes of use is specified by this profile.  Healthcare Access  Emergency Access  Programmer Access  Administrator Access  Research Access  Marketing Access
  • 16. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 13 Expanding on the above Purpose of Use for Healthcare Access, a purpose of use value set can be derived:  Treatment, Payment, Health Care Operations  Health care fraud and abuse detection or compliance  Use or disclosure of Psychotherapy Notes  Use or disclosure by the covered entity for its own training programs  Use or disclosure by the covered entity to defend itself in a legal action  Marketing  Use and disclosure for facility directories  Disclose to a family member, other relative, or a close personal friend of the individual  Uses and disclosures with the individual present  Permission cannot practicably be provided because of the individual’s incapacity or an emergency  Use and disclosures for disaster relief purposes  Uses and disclosures for public health activities  Disclosures about victims of abuse, neglect or domestic violence  Uses and disclosures for health oversight activities  Disclosures for judicial and administrative proceedings  Disclosures for law enforcement
  • 17. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 14 4 Patient Privacy and Confidentiality Constraints In addition to the Neumann and Strembeck constraints, additional healthcare attributes are necessary to include consumers5 such as a patient or a patient advocate. Attributes which allow (consent) or deny (dissent) access to a patient’s healthcare record as determined by the consumer may constrain a user’s access to an EHR. A privacy consent directive is a type of information policy about how an individual’s information is to be managed. A healthcare privacy consent directive is a license or prohibition against the collection, access, use, or disclosure of types or instances of health information by types or instances of entities. Typical reasons for consenting to the collection, access, use or disclosure of health information include healthcare treatment, payment, operations, public health, and research. The consenting party (consenter) may specify a reason or purpose for the license or prohibition. The decision from a consumer to allow or deny access to a user (i.e., physician, insurance company or financial institution for example) to their healthcare record is becoming a forefront concern with the relative ease of access to data within an EHR including personal demographics, disease states and the like. In involving confidentiality constraints one must consider the following access or data capture and associations to:  Record or report a consumer’s consent or dissent to authorize the collection, access, use, or disclosure of personally identifiable information;  Convey a provider’s request or intent to override a patient’s recorded consent or dissent;  Report a provider’s actual override of a patient’s recorded consent or dissent for audit purposes;  Convey a type of consent directive associated with a privacy policy; or  To record or report a consumer’s consent directive, which is to be applied to future access, collection, use or disclosure of personally identifiable information.6 The subject of a consumer’s consent directive includes specific instances or categories of information, including orders and results for lab, medications, diagnostic imaging; allergy and intolerance, medical condition, observations, demographics, immunizations, providers, and encounters. Note that categories of information may relate to a particular structuring of information, such as medication lists or summary health record, or it may relate to groupings of 5 Note that a consumer may or may not be a patient and the information to which the consent directive applies may or may not be health information. It must be personally identifiable information. For the purposes of this walk through, “consumer” means both an actual and a potential consumer of services such as healthcare. 6 HL7 Consent Vocabulary Project – Joint Security and Community-Based Collaborative Care Work Group Project Document, Version 4 (2008)
  • 18. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 15 value sets and particular classes and attributes that may be indicative of a category of information or from which a category of information may be inferred. “Inference means that filtered sensitive information can still be assumed given the other information that was not filtered.” For example: The form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known. Very often, diagnoses can be inferred from medication, such as Zidovudin for treatment of HIV infections. The addition of constraints for a consumer to allow or deny access to their EHR or PHR, also introduces the necessity of a provider (i.e., clinicians, etc.) for overriding a privacy policy consent directive. A privacy consent directive may be overridden by authorized parties based on standards of practice, organizational policy or jurisdictional law. Override reasons include professional judgment, emergency treatment, public safety, and the safety of third parties. A table of definitions for override reasons can be found in the Appendix A.
  • 19. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 16 5 Constraint Process 5.1 Assumptions Readers of this Constraint document should familiarize themselves with the HL7 Role Engineering Process. Each step requires the user to have a permission in order to accomplish the step. The compilation of sequential steps creates a scenario. A subject performing a scenario must possess all permissions that are needed to complete the different steps of this scenario. In turn, a task consists of one or more scenarios, and tasks are combined to form work profiles. A work profile comprises all tasks that a certain type of subject is allowed to perform. In a hospital environment different work profiles for physicians, nurses, and clerks are needed, for instance. In the role engineering process, work profiles are then used together with the permission catalog and the constraint catalog to define a concrete RBAC model. However, the scenario-driven approach presented in Neumann and Strembeck [2002] only provides general guidance for the sub process of defining (exogenous) constraints. This fact and our aim to specify and enforce context constraints in an RBAC environment led us to the definition of the proposed process extension. Using Figure 3 as an activity diagram for the engineering (sub) process, the role engineering process as a whole and the engineering of context constraints is in essence a requirement for the engineering process. This process is based on goal-oriented requirements engineering techniques as found in van Lamsweerde Goal-Oriented Requirements Engineering: A Guided Tour [Neumann-Strembeck]. 5.2 High-Level View of the Constraint Process 5.2.1 Model Interrelations Figure 1 illustrates how the Scenario Model and documents are related to the remaining components of the Constraint Catalog. Developing the Usage Scenarios (i.e., the Scenario Model) is the first step in the process.
  • 20. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 17 Figure 1: Interrelations of Scenario Model and Documents (Adapted from [Neumann/Strembeck]) Scenario Model ...... Task_1=Scenario-sequence(S1,S7,S4) Task_2=Scenario S3 Task_n=Scenario-sequence(S21,S14) Task Definitions Derived fromand composed of Perm_1={operation, object} Perm_2={operation, object} Perm_n={operation, object} Permission Catalog Profile_1={Task_2,...Task_7} Profile_2={Task_6, Task_8} Profile_n={Task_x,...Task_y} Work Profile Consists of Derived from Refer to Perm_3 <exclude>Perm_9 Perm_5 <exclude>Perm_12 Max_cardinality (Perm_n)=4 Constraint Catalog Created in accordance with Created in accordance with
  • 21. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 18 5.3 ProcessSteps [Neumann/Strembeck] The following constraints sub-process will be applied to define the following types of constraints:  User-role constraint – user cannot be assigned to two separate roles (e.g., a user cannot be assigned to both the Prescriber role and the Pharmacist role).  Role-role constraints – users may have more than one role, but only one role may be active in a session at any given time (e.g., a user cannot activate the Prescriber role and the Pharmacist role within a session).  Role-permission constraint – wherein a role cannot be assigned certain permission (e.g., the ‘write DNR Order’ permission cannot be assigned to the Resident role).  Permission-permission constraint – wherein permission(s) are in conflict or should not be assigned to the same role (e.g., The ‘Order Medication’ and ‘Dispense Medication’ permissions cannot be assigned to the same role). Figure 2: RBAC Permission with Context Constraint 5.3.1 Identification of Permission Constraints [Neumann/Strembeck 4.3] Preliminary Scenarios and the scenario model serve as the basis for the scenario-driven role engineering process [Neumann and Strembeck 2002]. The first step of the constraint engineering sub-process shown in Figure 3 is thus to fetch the current scenario model.
  • 22. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 19 Process Overview Review the permissions and identify the applicable constraints. For each constraints identified, create a record in the constraint catalog. STEP 1  Review each permission (operation-object pair) and identify the applicable obstacle or constraint(s). STEP 2  For each permission, record the associated constraint(s) if applicable (verify ‘constraint’ vs. ‘business rule’ constraint conditions and brief description; include factors which make it differ from a business rule). STEP 3  Identify Constraint Type (cardinality, separation of duty, time, location) STEP 4  Assign a Constraint ID Table 2 depicts an example of a constraint catalog. Each record in the catalog will consist of a permission ID, basic permission name or {operation, object} pair, and applicable constraint(s). Note: the constraint catalog will be populated after Scenario Model Refinement which is described in a subsequent section.
  • 23. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 20 6 Constraint Table Listed below are the legends for the healthcare permission table that follows. ID (xy-nnn) Legend: x = P (permission) y = C (constraint identifier) nnn = Sequential number starting at 001 Unique Permission ID - refers to the identifier assigned to the abstract permission name Permissions are organized according to the following clinical tasks; [HL7 Healthcare Permission Catalog]  Order Entry (OE),  Review Documentation (RD),  Perform Documentation (PD) and  Scheduling (SC).  Emergency Access (EA) Unique Permission-Constraint ID – refers to the identifier assigned to the permission constraint Constraint Type – refers to the constraint definition as described in Table 1
  • 24. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 21 Appendix A: Additional Context Constraints A.1 Purpose of Use a. Healthcare Access b. Emergency Access c. Programmer Access d. Administrator Access e. Research Access f. Marketing Access Privacy, Consentand Confidentiality Constraints (Recommendation for HL7 RIM Vocabulary) A.2 Relatedto Health Information Access (Confidentiality) - Access restrictions placedona recordof 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.
  • 25. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 22 A.3 By Information Type (Sensitivity) Substance abuse related (ETH) Alcohol/drug-abuse related item. HIV related (HIV) HIV and AIDS related item. Psychiatry related (PSY) Psychiatry related item. Sexual and Domestic Violence Related (SDV) Sexual assault / domestic violence related item. Alternative Lifestyle (A) Information related to a subject’s choice of alternative religious or philosophical beliefs, personal relationship or family structures; or sexual orientation that the patient does not wish to have disclosed. A.4 RestrictedAccessto Data (Access Restriction, ConsentDirectives) Restricted by provider (RD) Access to a record is restricted by the provider because of potential harm to the patient or third parties. Restricted by consent directive (CDA) Access to a record is restricted per the subject’s consent directive. Masked access (MA) Access to a record is restricted to users or roles specified by the subject of the record. Users who are not authorized to access the record will not be notified that the record is masked. Organizational policy or jurisdictional law may specify conditions under which locked restriction on access may be overridden. Flagged Masked access (FMA) Access to a record is restricted to users or roles specified by the subject of the record. However,users who are not authorized to access the record will be notified that the record is masked. Organizational policy or jurisdictional law may specify conditions under which locked restriction on access may be overridden. Locked access (L) Access to a record is restricted to author and subject of the record. Organizational policy or jurisdictional law may specify conditions under which locked restriction on access may be overridden.
  • 26. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 23 Shared secret access (SSA) Access to a record is restricted to users to whom the patient has shared a secret password or token that unlocks the sealed or masked record. Organizational policy or jurisdictional law may specify conditions under which shared secret restriction on access may be overridden. Role-based access (RBA) Access to a record is restricted to users playing specified roles (e.g.,members of a care team,provider with direct care relationship). Care team access (CTA) Access to a record is restricted to a group of providers coordinating a direct care relationship to the patient. Direct care provider access (DCR) Access to a record is restricted to provider with direct care relationship to the patient. User based access (UBA) Access to a record is restricted to identified users. Context based access (CBA) Access to a record is restricted by security relevant properties of the context in which an access request occurs (e.g.,explicit time, location, route of access,and quality of authentication). For example, access restricted to emergencies when the patient is unable to grant consent. Very restricted (V) Very restricted access as declared by the Privacy Officer of the record holder. A.5 Reasonsto Override ConsentDirectives Very restricted (V) Very restricted access as declared by the Privacy Officer of the record holder. Emergency The patient is unable to provide consent, but the provider determines they have an urgent healthcare related reason to access the record. Professional judgment The patient, while able to give consent, has not. The provider however, believes it is in the patient’s interest to access the record without patient consent. Example: A patient with a history of psychiatry related illness. Public Safety The patient, while able to give consent, has not. The provider however, believes that access to masked patient information is justified because of concerns related to public safety. Example: An adult employed at a fast food restaurant with recent exposure to a contagious disease such as chicken pox.
  • 27. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 24 Third Party Safety Definition: The patient, while able to give consent, has not. However,the provider believes that access to masked patient information is justified because of concerns related to the health and safety of one or more third parties. Example: Patient with children who is undergoing routine chemotherapy treatments at home. A physician (not involved with the patient’s chemotherapy) will access the patient’s chemotherapy records to determine the risk of possible radiation exposure to the other family members of the home. A.6 Other Modifiers celebrity (C) Celebrities are people of public interest (VIP) including employees, whose information require special protection. sensitive (S) Information for which the patient seeks heightened confidentiality. Sensitive information is not to be shared with family members. Information reported by the patient about family members is sensitive by default. Flag can be set or cleared on patient’s request. taboo (T) Information not to be disclosed or discussed with patient except through physician assigned to patient in this case. This is usually a temporary constraint only; example use is a new fatal diagnosis or finding, such as malignancy or HIV.
  • 28. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 25 Appendix B: Constraints Associated with Permissions EXAMPLE Table 2 lists the definitions of the objects presented in Section 2: Unique_Permission_Constraint-ID: Unique Constraint identification Permission_Constraint_Description: brief description of constraint application on the listed permission(s) Constraint_Type: definition of the constraint as applied to the corresponding permission Permission_ID, Permission Name: corresponding unique Permission ID and name as described in the HL7 Healthcare Permission Catalog to which the constraint is being applied.
  • 29. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 26 Table 2: Permission Constraint Catalog EXAMPLE PermissionConstraint ID ConstraintScenarioID Operation {seeRBAC PermissionCatalog} Object {seeRBAC PermissionCatalog} PurposeofUse {seePOU Table/Database) Usesanddisclosures for: SecurityorPatient Constraint Confidentiality RelatedToHealth InformationAccess restrictionsplaced onarecordofhealth information {D,I,N} ConfidentialityBy InformationType {ETH,HIV,PSY,SDV, A} RestrictedAccessto Data [RD,CDA,MA,FMA,L,S SA,RBA,CT,DCR,UBA, CBA,V} Confidentiality Modifiers PolicyDecisionPoint (PDP) PC-000 CSI-000 A = Append C = Create R = Read U = Update D = Delete E = Execute, etc. i.e., {Laboratory Order} {Radiology Order} {Outpatient Prescription Order}, etc. {i.e., Health oversight, research,Public health, Law Enforcement, Disaster/Emergency Services,etc.} Patient Clinician (D) Individual (I) Normal (N) Substance Abuse Related (ETH) HIV Related (HIV) Psychiatry Related (PSY) Sexual or Domestic Violence (SDV) Alternative Lifestyle (A) i.e., Restricted by consent directive(CDA) Masked access (MA) Locked access (L) Shared secret access (SSA) Role-based access (RBA) Care team access (CTA) Direct care provider access (DCR) User based access (UBA), etc. celebrity (C) sensitive (S) taboo (T) Grant Permission Access?
  • 30. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 27 PermissionConstraint ID ConstraintScenarioID Operation {seeRBAC PermissionCatalog} Object {seeRBAC PermissionCatalog} PurposeofUse {seePOU Table/Database) Usesanddisclosures for: SecurityorPatient Constraint Confidentiality RelatedToHealth InformationAccess restrictionsplaced onarecordofhealth information {D,I,N} ConfidentialityBy InformationType {ETH,HIV,PSY,SDV, A} RestrictedAccessto Data [RD,CDA,MA,FMA,L,S SA,RBA,CT,DCR,UBA, CBA,V} Confidentiality Modifiers PolicyDecisionPoint (PDP) PC- 001 CSI- 001 Read INPATIENT ORDER Health Oversight Activities. Patient D HIV CDA DCR n/a NO PC- 002 CSI- 001 Read INPATIENT ORDER Health Oversight Activities. Patient N HIV RD CDA n/a NO PC- 003 CSI- 001 Read INPATIENT ORDER Health Oversight Activities. Patient I HIV RD YES
  • 31. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 28 Appendix C: Healthcare Information Technology Standards Panel (HITSP) Security policy management includes the security rules to be enforced by the system, constraints on the rules and obligations of systems and conveying these to the security mechanism used in enforcing the rules. Security policy provisioning management includes granting privileges and attributes to users and making these known to the various components of the security system. Security policy management includes managing and instantiating security policy within the application security mechanisms. ISO 22600-1 and ISO 22600-2 provide the framework and models for security management used in this package. Security policy enforcement or access control, deals with ensuring that users attempting to access system functions and data have the requisite privileges (granted and provisioned in privacy and security management). Access control considers all access control information needed to make and enforce an access control decision. ISO 10181-3 provides the framework and models for access control. It also defines the types of access control used in this package. The following are the requirements derived from the American Health Information Community (AHIC) Use Case for this component: 1. Access Control policies are managed (created, modified, deleted, suspended or restored, and provisioned based on defined rules and attributes) 2. Data access policy is enforced 3. Data access policy bypass permission is established (granted) (Emergency Access/break glass) 4. Data access policy bypass is enforced (Emergency Access/break glass) 5. User data are located by an entity with the ability (privileges) to search across systems 6. Protected data are accessed based on user permission for data access 7. Protected data are modified, updated or corrected by identified users 8. Selective protected data are blocked from users 9. Requests for changes to protected data are made by users to providers/sources of data 10. Obligations can be used to full access permissions and operations
  • 32. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 29 Figure 3: XACML Components XACML (eXtensible Access Control Markup Language) (is a general-purpose language for specifying access control policies [Pro04]. In Extensible Markup Language (XML) terms, it defines a core schema with a namespace that can be used to express access control and authorization policies for XML objects. Since it is based on XML, it is, as its name suggests, easily extensible. XACML provides features that make it possible to support a broad range of policies [OASIS]; it provides the capability to request a specified operation within a system using a standardized syntax, and then receive one of four replies: • Permit – operation (action) allowed • Deny – operation (action) disallowed • Indeterminate – error or incorrect/missing value prevents a decision • Not Applicable – request cannot be processed. XACML’s standardized architecture (Figure 2) for this decision-making uses two primary components: the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). The PEP constructs the request based on the user’s attributes, the resource requested, the operation specified, and other situation-dependent information through PIP. The PDP receives the constructed request, compares it with the applicable policy and system state through the Policy Access Point (PAP), and then returns one of the replies specified above to the PEP. The PEP then allows or denies access to the resource. The PEP and PDP components may be embedded within a single application or may be distributed across a network. To make the PEP and PDP work, XACML provides a policy set, which is a container that holds either a policy or other policy sets, plus (possibly) links to other policies. Each individual policy
  • 33. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 30 is stated using a set of rules. XACML also includes methods for combining these policies and policy sets, allowing some to override others. This is necessary because the policies may overlap or conflict. Transferring XACML Policies Policies may need to be transferred from one entity to another in a Privilege Management Infrastructure. Some of the situations where this is required are: a) A PDP evaluates a policy that references other policies by name. The other policies must be fetched from a Policy Administration Point (PAP) when required for evaluation. b) A PDP may need to obtain its “root” policy from the enterprise Policy Administration Point as part of configuration. c) A resource may be transferred between security domains and the source domain may transfer a policy for protection of the resource that the destination domain is responsible for enforcing. d) Multiple sites may need to use common policies, even though their PDPs are local for performance reasons. These policies need to be transferred from the central Policy Administration Point to each site’s PDP. While XACML defines a policy language, it’s designed to be one component in an overall authorization system. It relies on other components to provide mechanisms for verifying that policy instances were issued by a trusted Policy Administration Point for protecting the integrity and confidentiality of instances of policies, and for protocols used to query for and respond with policy instances. XACML has been integrated with the Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) Version 2.0 as one way of providing these necessary functions. SAML may be used with XACML to protect Access Control Information attributes as well as policies. The following diagram illustrates the integration of SAML and XACML. [HITSP]
  • 34. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 31 Figure 4: Using SAML 2.0 to transport XACML (Used by permission of OASIS)
  • 35. HL7 RBAC Constraint Catalog v1.39 January 2010 Page 32 Appendix D: References A. [ANSI] American National Standard for Information Technology - Role-Based Access Control, ANSI INCITS 359-2004, 2004 B. [ANSI] An Integrated Approach to Engineer and Enforce Context Constraints in RBAC Environments; ACM Transactions on Information and System Security; Neumann and Strembeck C. [ASTM] ASTM E 1986-98: Standard Guide for Information Access Privileges to Health Information D. [HITSP] Healthcare Information Technology Standards Panel HITSP Manage and Control Data Access Transaction Package, V0.2 May 16, 2007 E. ISO 10181-3-00: Security Frameworks for Open Systems: Access Control Framework; also available as ITU-T X.812: 1995 F. ISO TC 215/WG4/N ANSI Health informatics – Privilege management and access control – Part 1: Overview and policy management, 2004-01-08 G. [Neumann-Strembeck] An Integrated Approach to Engineer and Enforce Context Constraints in RBAC Environments; Received November 2003; revised March 2004, April 2004 and May 2004; accepted May 2004 H. OASIS, Extensible Access Control Markup Language (XACML) v2.0, February 2005 I. OASIS, XACML Profile for Role-based Access Control (RBAC): Committee Draft 01 (normative; 13 February 2004) J. VHA/IHS Role-based Access Control Task Force Charter Version 2.0, 17 September 2004 K. Latest versions of the following documentation can be found on: www.HL7.org HL7 Role-based Access Control Task Force Project Management Plan (PMP) HL7 Role-based Access Control (RBAC) Structural Roles HL7 Role-Based Access Control (RBAC), Functional Roles HL7 Role-Based Access Control (RBAC), Permission Catalog i HL7 RBAC Role Engineering Process v1.1, November 2005 ii HL7 Structural Roles v1.0, September 2006 iii M Strembeck and G. Neumann, An Integrated Approach to Engineer and Enforce Context Constraints in RBAC Environments; Received November 2003; revised March 2004, April 2004 and May 2004; accepted May 2004 iv M. Strembeck and G. Neumann, An Integrated Approach to Engineer and Enforce Context Constraints in RBAC Environments; ACM Transactions on Information and System Security, Vol. 7, No. 3, August 2004. v Ibid vi D. Richard Kuhn, MutualExclusion of Roles as a Means of Implementing Separation of Duty in Role-Based Access Control Systems. 1997