Permissions Catalog: Recommendations for Reuse

Recommendations to Reuse Permission Catalog Terminology for Privacy Consent Directive

Introduction

The current Permissions Catalog for Role-Based Access Control (RBAC) specifies a set of normative permissions that specify operations that may be applied to a variety of object types. The Security WG (jointly with CBCC) is currently working on a project intended to provide controlled terminology for the operations and objects referenced in the RBAC Permission Catalog (see TSC project list - item 118).

The permission catalog is a normative specification and it is available for download.

• The most recently published permission catalog is 20071112_HL7_RBAC_Healthcare_Permission_Catalog_v3_37.pdf

The Community-based Collaborative Care (CBCC) work group is responsible for maintenance of the Data Consent standard (Release 1 approved in 2007) and it will be enhanced through May 2009 (see Composite Privacy Directive Release 1, Draft for Comment).

The RBAC operations extend the typical database C(reate),R(ead),U(update),D(elete) operations and they refer specifically to the ability of healthcare users to:

• append,
• create,
• read,
• update,
• delete, and
• execute (?)

specific healthcare "objects" identified in the RBAC Permission Catalog. The RBAC "objects" refer to a variety of healthcare information elements (e.g. Progress Notes, Summary Report) and functions (e.g. ADT). A permission specifies an operation and the object on it it is applied :

Permission
Operation	Object	Effect
append	Administrative Ad-hoc Report	A role that has this permission, allows the user that logs in with that role to append information to an existing ad-hoc administrative report.

Sample Permission

Healthcare Operations rather RBAC Operations

In order to reuse the RBAC operations for both RBAC and Composite Privacy Consent Directive, it would be preferable if the RBAC operations could be based on the HL7 trigger events specified in the HL7 RIM reference documentation. The healthcare work flow as specified in HL7, provides for "trigger events" that correspond to healthcare-specific operations. The following table is an example mapping of the HL7 trigger events to RBAC operations. As seen here, the HL7 triggers/operations are more closely related to the healthcare delivery workflow and thus they are more likely to encourage the reuse of HL7 permissions.

HL7 Operations (trigger event)	RBAC Operations
create	create
revise	update,append
activate	NA
complete	execute(?)
suspend	NA
resume	NA
abort	NA
hold	NA
release	NA
cancel	NA
obsolete	NA
nullify	delete(?)
NA (to be added to HL7 along with other triggers for Composite Privacy Consent Directive)	read

The following diagram shows the trigger events and the states that correspond to the healthcare work flow for healthcare object (e.g. Act). For example, an order may be created, activated, then canceled. Similarly an order may be created, activate, revised, and eventually completed.

The following diagram is an extract from HL7 RIM reference documentation and illustrates how HL7 defines "healthcare trigger events" and it illustrates the life cycle of a typical healthcare object (e.g. Act). States of Act (also specified using the ActStatus coding system):

• aborted (sub-state of normal): The Act has been terminated prior to the originally intended completion.
• active (sub-state of normal): The Act can be performed or is being performed.
• cancelled (sub-state of normal): The Act has been abandoned before activation.
• completed (sub-state of normal): An Act that has terminated normally after all of its constituents have been performed.
• held (sub-state of normal): An Act that is still in the preparatory stages has been put aside. No action can occur until the Act is released.
• new (sub-state of normal): An Act that has been activated (actions could or have been performed against it), but has been temporarily disabled. No further action should be taken against it until it is released.
• normal: Encompasses the expected states of a service object, but excludes "nullified" and "obsolete" which represent unusual terminal states for the life-cycle.
• nullified: This Act instance was created in error and has been 'removed' and is treated as though it never existed. A record is retained for audit purposes only.
• obsolete: This Act instance has been replaced by a new instance.
• suspended (sub-state of normal): Active service object is temporarily suspended.

State transitions of Act:

• abort (from active to aborted)
• revise (from active to active)
• complete (from active to completed)
• suspend (from active to suspended)
• reactivate (from completed to active)
• revise (from completed to completed)
• cancel (from held to canceled)
• revise (from held to held)
• release (from held to new)
• activate (from new to active)
• cancel (from new to canceled)
• complete (from new to completed)
• hold (from new to held)
• revise (from new to new)
• nullify (from normal to nullified)
• obsolete (from normal to obsolete)
• activate (from null to active)
• complete (from null to completed)
• create (from null to new)
• jump (from null to normal)
• abort (from suspended to aborted)
• resume (from suspended to active)
• complete (from suspended to completed)
• revise (from suspended to suspended)

Value Sets for "Object"

Currently, the Security work group is attempting to map the "objects" specified in the Permissions Catalog to SNOMED codes. However, several "objects" in the permission catalog are actually document types that have been codified for use with the CDA R2 standard. Additionally, sections of the CDA documents have been standardized by HL7. Since CDA R2 clinical documents are often used to exchange patient records between organizations, the ability to refer to specific types of documents or sections of a document may be useful both for RBAC and consent directive specifications.

HL7 Concept Domains and HL7 Coding Systems

The availability of HL7 concept domains and coding systems allows the reuse of RBAC object terminology by other standards such as Composite Privacy Consent Directive (aka Data Consent ).