an ontological implementation of a role-based access control policy for health care information
DESCRIPTION
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. Introduction. - PowerPoint PPT PresentationTRANSCRIPT
1
An Ontological Implementation of a Role-Based Access Control Policy for Health
Care InformationCristian Cocos and Wendy MacCaull
({ccocos,wmaccaul}@stfx.ca)Centre for Logic and Information
St. Francis Xavier University, Nova ScotiaCanada
• 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
2Ontological RBAC
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.3
Ontological RBAC
Introduction
• 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.
4Ontological RBAC
Access control scenario
• 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 patient5
Ontological RBAC
Access control policy
• BFO
6Ontological RBAC
Implementation
• BFO:role branch contains the main mechanism
• Most of the classes that populate this branch have been imported from SNOMED-CT
7Ontological RBAC
Implementation
• Core ACO mechanisms reside under the Clearance-Level0Role and PermissionLevel0Role:
8Ontological RBAC
Implementation
• ClearanceLevelRole classes are defined as a union of roles that have a certain security clearance level
• Similar story goes for PermissionLevelRole classes
9Ontological RBAC
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)
10Ontological RBAC
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
11Ontological RBAC
Implementation
• Classes that represent controlled information are children of the BFO:generically_dependent_continuant
12Ontological RBAC
Implementation
• Classes that represent controlled actions comprise the ACO:SystemProcedure class, which is a child of BFO:process
13Ontological RBAC
Implementation
• All classes that make the subject of access control have restrictions outlining their clearance/permission level
14Ontological RBAC
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
15Ontological RBAC
Implementation
• 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
16Ontological RBAC
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
17Ontological RBAC
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
18Ontological 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
19Ontological RBAC
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
20Ontological RBAC
Workflow interaction
• 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
21Ontological RBAC
Future work for ACO
• Implement an emergency override scenario (“break the glass” mechanism)
• Question: can this be implemented using a DL-based ontology?
22Ontological RBAC
Future work for ACO
• 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 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.
23Ontological RBAC
References