An Ontological Implementation of a Role Based Access

An Ontological Implementation of a Role. Based Access Control Policy for Health Care Information Cristian Cocos and Wendy Mac. Caull ({ccocos, wmaccaul}@stfx. ca) Centre for Logic and Information St. Francis Xavier University, Nova Scotia Canada 1

Introduction • Currently developing a workflow management system for community-based palliative and seniors’ care • Scheduled to be deployed at several hospitals in rural Nova Scotia • The aim: streamlining workflow by improving process documentation and communication • Collaborative project involving healthcare entities Ontological RBAC 2

Introduction • Perils: security and privacy • Idea: use ontological structures to represent access control policies • More exactly: use the classes of an ontology to model roles, and role hierarchy • Adopt a suitable upper-level ontology: our choice was BFO • Other concerns: re-use portions of existing ontologies: SNOMED-CT, ICNP etc. Ontological RBAC 3

Access control scenario • Two types of resources in need of access control – Informational items – System actions • E. g. : database fields (patient ID, patient name, primary diagnosis etc. ) and, resp. , actions such as form/report printing, faxing, phoning, appointment scheduling etc. Ontological RBAC 4

Access control policy • Roles are organized hierarchically • Resources are organized hierarchically • Constraints can be provided for each form field and action individually • Allows for disjoint roles • Database fields can be accessed as both read only and write • System users may have multiple roles with regard to the same patient Ontological RBAC 5

Implementation • BFO Ontological RBAC 6

Implementation • BFO: role branch contains the main mechanism • Most of the classes that populate this branch have been imported from SNOMED-CT Ontological RBAC 7

Implementation • Core ACO mechanisms reside under the Clearance-Level 0 Role and Permission. Level 0 Role: Ontological RBAC 8

Implementation • Clearance. Level. Role classes are defined as a union of roles that have a certain security clearance level • Similar story goes for Permission. Level. Role classes Ontological RBAC 9

Implementation • All Clearance. Levely. Role roles have also clearance level x for x y, but not viceversa • E. g. , all information that is accessible to a community nurse (say) is also accessible to a clinical oncologist (a Clearance. Level 0 Role role) Ontological RBAC 10

Implementation • Relations required to tie clearance and permission level roles with database fields and system actions respectively • has. Write. Access. To and has. Read. Access. To • write. Accessible. By and read. Accessible. By • invokable. By (for actions) • has. Role/role. Of • has. Clearance. Level/clearance. Level. Of • permission. Level. Of Ontological RBAC 11

Implementation • Classes that represent controlled information are children of the BFO: generically_dependent_continuant Ontological RBAC 12

Implementation • Classes that represent controlled actions comprise the ACO: System. Procedure class, which is a child of BFO: process Ontological RBAC 13

Implementation • All classes that make the subject of access control have restrictions outlining their clearance/permission level Ontological RBAC 14

Implementation • Finally, the last of the relevant BFO classes is BFO: object, that contains SNOMED’s “Homo sapiens (organism), ” which represents the main ACO rolebearer • ACO expressivity: SROIF Ontological RBAC 15

Workflow interaction • Access control clearance is checked at login time, by querying ACO upon user login • The query returns a list of GASHA form fields and reports whose access is forbidden to the user, and a list of system actions permitted • The workflow system acts accordingly, by blocking access to the requisite actions and information entities Ontological RBAC 16

Workflow interaction • Query examples (ALCHO DL): • not (accessible. By some (role. Of value Individual 1)); this reveals all the form fields that are not accessible to Individual 1 • invokable. By some (role. Of value Individual 2) returns all system actions that Individual 2 has permission to launch Ontological RBAC 17

Workflow interaction • The workflow system also uses a knowledge base for actual palliative and seniors’ care knowledge • Also in ontology format (PCSO) • PCSO will provide logic-based guidance for the workflow at the decision points • Decision points = points in the workflow where it branches, and where palliative and seniors’ care knowledge is involved in the decision 18 Ontological RBAC

Workflow interaction • PCSO interaction scenario: • the workflow reaches a decision point • PCSO is queried with the patient data contained in the EHR, and furnishes information regarding the workflow branch that the process is recommended to follow for that particular patient Ontological RBAC 19

Workflow interaction • PCSO interaction scenario (cont’d): • The information returned by the query is analyzed by the responsible physician • Physician ultimately decides whether the process should follows the path indicated by the ontology query Ontological RBAC 20

Future work for ACO • Add a customization phase • Requires implementing a workflow mechanism that queries the patient/client on specific access control preferences during several predetermined phases of the workflow • Also implement a workflow mechanism that builds new patient-specific access control ontologies that will be combined with the default ACO described above in order to customize the access control policy for each patient Ontological RBAC 21

Future work for ACO • Implement an emergency override scenario (“break the glass” mechanism) • Question: can this be implemented using a DL-based ontology? Ontological RBAC 22

References • • Bittner, T. and Smith, B. (2004) Normalizing Medical Ontologies using Basic Formal Ontology, in Kooperative Versorgung, Vernetzte Forschung, Ubiquitäre Information (Proceedings of GMDS Innsbruck, 26 -30 September 2004), Niebüll: Videel OHG, pp. 199– 201. Bouamrane, M. -M. , Rector A. and Hurrell, M. (2009) A Hybrid Architecture for a Preoperative Decision Support System Using a Rule Engine and a Reasoner on a Clinical Ontology, in Polleres, A. and Swift, T. (Eds. ): RR 2009, LNCS 5837, pp. 242– 253, Springer -Verlag Berlin Heidelberg 2009. Finin, T. et al. (2008), ROWLBAC - Representing Role Based Access Control in OWL, in SACMAT’ 08, June 11– 13, 2008, Estes Park, Colorado, USA. Grenon, P. , Smith, B. and Goldberg, L. (2004) Biodynamic Ontology: Applying BFO in the Biomedical Domain. In D. M. Pisanelli (ed. ), Ontologies in Medicine, Amsterdam: IOS Press, 2004, pp. 20– 38. Miller, K. and Mac. Caull, W. (2009) Toward Web-based Careflow Management Systems, Journal of Emerging Techniologies in Web Intelligence, vol. 1, no. 2, pp. 137 -145. Tsoumas, B. , Dritsas, S. and Gritzalis, D. (2005) An Ontology-Based Approach to Information Systems Security Management in V. Gorodetsky et al. (eds. ): MMM-ACNS 2005, LNCS 3685, Springer-Verlag Berlin Heidelberg, pp. 151 – 164, 2005. Kazakov, Y. (2008) SRIQ and SROIQ are Harder than SHOIQ, in Baader, F. et al. (eds. ), DL 2008. Vol. 353 of CEUR Workshop Proceedings. Ontological RBAC 23