A multi-domain privacy aware access control system based on RBAC extended with role roaming and data profiles

1. Multi-domain and Privacy-aware
Role Based Access Control in
eHealth
Lorenzo D. Martino, Qun Ni
Dan Lin, Elisa Bertino
This work has been supported by IBM OCR project “Privacy
and Security Policy Management” and the
NSF grant 0712846 “IPS: Security Services for Healthcare
Applications”.

2. Outline
• Healthcare is a multi-domain
environment
• Privacy in e-Health
• Why RBAC?
• Core P-RBAC
• Multi-domain P-RBAC
• Conclusions and future work

3. Healthcare is a distributed
multi-domain environment
Contracted service:
emergency dept.
phyisicians
Clinicians Nurses
Staff
HRO Contracted service:
anasthesiologists
External Domain
Analysis Lab. External Domain
Hospital
Owning Domain
External Domain
External Domain
Insurance
University

4. Privacy in healthcare
• Privacy is an important issue
– HIPAA – Healthcare Insurance
Portability and Accountability Act
(1996)
• Privacy protection policies
– Privacy notices, policies by NL or P3P
• Enforcing privacy policies is the
key

5. Privacy policy management
Procedures Processes Controls
Application-level
policies
Laws & Internal privacy &
regulations security policies
Reconciliation Can generate
Machine-
processable Data--level
policies policies

6. Why RBAC?
• RBAC advantages
– It is based on the notion of functional roles in an
organization
– It provides a simple and natural approach to modeling
organizational security policies
– It simplifies authorization administration
– It meets a large variety of security requirements and
has received considerable attention by healthcare
organizations: RBAC task force - Department of
Veterans Affairs (VA), Department of Defense (DoD)
• However, RBAC cannot support privacy policies
without some extension

7. Privacy-aware RBAC (P-RBAC)
• P-RBAC extends the RBAC model in
order to support privacy-aware access
control
• Privacy policies are expressed as
permission assignments (PA); these
permissions differ from permissions in
classical RBAC because of the presence
of additional components, representing
privacy-related information

8. Core P-RBAC
• Privacy Sensitive
Data Permission
(a, d, p, c, o)

9. Policies – an example
• For treatment purposes, patients’
medical information can be accessed by
physicians, nurses, technicians, medical
students, or others who are involved in
the patients’ care or by other
departments of the healthcare
organization for the care/therapy
coordination or by contracted physician
services, such as emergency
department physicians, pathologists,
anesthesiologists, radiologists.

10. Permissions in P-RBAC
(physician,
read, patient.EMR.raw, treatment,
subject = patient. duty physician, ;)
• the physician role can read patient EMR
content
• for treatment purpose
• patient.EMR.raw is a data object specified
according to a condition:
– the subject associated to the physician role can
access the data only if the subject is the patient’s on
duty physician - subject = patient.duty_physician -

11. Multi-domain P-RBAC
• It extends P-RBAC with:
– Role precondition: a user can be assigned
to a certain role provided that the user is
associated to one or more specific roles in
his/her home organization
– Data profile: it allows to specify set of data
such as patient’s identification data, therapy
data, prescriptions and so forth

12. Permissions in Ext P-RBAC
( (GP, HP, physician) , read, patient.EMR.raw, treatment,
subject = patient. duty physician, ;)
• Role precondition: the physician role can be assigned to
a subject provided that he/she plays the GP role in the
Healthcare organization HP
• the physician role can read patient EMR content
• for treatment purpose
• patient.EMR.raw is a data object specified according to
a condition:
– the subject associated to the physician role can access the
data only if the subject is the patient’s on duty physician -
subject = patient.duty_physician -

13. Conclusions
• Role preconditions enhance security
• Role precondition provide a further control in
addition to user identification and authentication,
by relying upon organizational control processes
• Underlying assumptions:
– a) there is a trust relationship between the owner
organization and the users’ home organization, and
– b) the users’ home organization itself adopt a controlled
process before declaring that its users play a certain role

14. Future Work
• Investigate different role
provisioning strategies
• Implementation on LBAC database
• Consistency analysis techniques on
privacy permissions w.r.t. data
profile

15. Questions?

16. Thank you!
Lorenzo D. Martino
Computer & Information Technology Dept.
Purdue University
lmartino@purdue.edu