An Ontological Implementation of a Role-Based Access Control Policy for Health Care Information

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

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

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

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

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

6. Implementation • BFO Ontological RBAC

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

8. Implementation • Core ACO mechanisms reside under the Clearance-Level0Role and PermissionLevel0Role: Ontological RBAC

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

10. Implementation • All ClearanceLevelyRole roles have also clearance level x for xy, but not vice-versa • E.g., all information that is accessible to a community nurse (say) is also accessible to a clinical oncologist (a ClearanceLevel0Role role) Ontological RBAC

11. Implementation • Relations required to tie clearance and permission level roles with database fields and system actions respectively • hasWriteAccessTo and hasReadAccessTo • writeAccessibleBy and readAccessibleBy • invokableBy (for actions) • hasRole/roleOf • hasClearanceLevel/clearanceLevelOf • permissionLevelOf Ontological RBAC

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

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

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

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

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

17. Workflow interaction • Query examples (ALCHO DL): • not (accessibleBy some (roleOf value Individual1)); this reveals all the form fields that are not accessible to Individual1 • invokableBy some (roleOf value Individual2) returns all system actions that Individual2 has permission to launch Ontological RBAC

18. 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 Ontological RBAC

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

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

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

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

23. References • Bittner, T. and Smith, B. (2004) Normalizing Medical Ontologies using Basic Formal Ontology, in KooperativeVersorgung, VernetzteForschung, 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 MacCaull, 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