MS Thesis Defense: Ruoyu Wu
Graduate Supervisory Committee:
Dr. Gail-Joon Ahn, Chair
Dr. Sik-Sang Yau
Dr. Dijiang Huang
Secure Sharing of Electronic
Medical Records in Cloud
Outline
Introduction
Problem Summary
Secure EHRs Sharing Framework in
Clouds
–
Selective EHRs sharing
–
HIPAA-compliant EHRs sharing
System Design
Implementation and Evaluation
Related Work
Internet-centric World
Ecosystem
IaaS
PaaS
SaaS
Cloud-driven World
Healthcare Evolution
Paper-based records transform to EHRs
EHRs are shifting to Clouds
Paper-based
Transform
EMRs
Sharing
Efficiency
Ubiquitous Access
Cost efficiency
Dynamically scalable
Shift
Cloud Platform
Security and Privacy
Identity Management
Authentication
Trust Management
Policy Management
Access Control
Compliance Management
–
H. Takabi, J. Joshi, and G. Ahn. Security and privacy challenges in cloud computing
Access Control Issue
Cross-domain EHRs integration
Compliance Management Issue
Manual and labor-intensive process
Additional overheads to health information transactions.
HIPAA is complex and in part vague
Updates of HIPAA regulation and upscales of EMRs
–
R. Wu, G.-J. Ahn, and H. Hu. Towards hipaa-compliant healthcare systems. In Proceedings of
the 2nd ACM SIGHIT International Health Informatics Symposium, pages 593–602. ACM,
2012.
HIPAA
Regulations
All System States
EMR
System
System
Policies
Treats
define
to comply
enforce
cause loss
Hypothesis
We propose a framework that ensures secure sharing
of EHRs supporting
–
Selective sharing on composite EHRs
•
Logical EHR model
•
EHR data schema composition
•
Cross-domain EHR instance aggregation
•
Access control policy specification
–
HIPAA-compliant EHRs sharing
•
Extracting policy patterns
•
Formulating policy specification
•
Transformation
Secure EHRs Sharing
Framework Overview
Hypothesis
We propose a framework that ensures secure sharing
of EHRs supporting
–
Selective sharing on composite EHRs
•
Logical EHR model
•
EHR data schema composition
•
Cross-domain EHR instance aggregation
•
Access control policy specification
–
HIPAA-compliant EHRs sharing
•
Extracting policy patterns
•
Formulating policy specification
•
Transformation
Logical EHR Model
An EHR object is represented as a tuple T = (r, V, E)
–
r
is the root of the whole EHR object;
–
V is a set of nodes within the whole EHR object hierarchical
structure
–
E
⊆
V
×
V is a set of links between nodes.
–
J. Jin, G. Ahn, H. Hu, M. Covington, and X. Zhang. Patient-centric authorization framework for sharing
electronic health records. In Proceedings of the 14th ACM symposium on Access control models and
technologies, pages 125–134. ACM, 2009.
Algorithm for Merging
Two EHR Data Schemas
EHR Data Schema
Composition Example
T
s
T
d
Merge to
Call
insertSubSchema(
T
d, r
d, T
s, r
s)
r
s
r
d
r
d= r
s-> m = r
dm
m
m
m
Otology Classes
Demographic, Demo
Gender, Sex
EHR Data Schema
Cross-domain EHR
Instance Aggregation
Policy Specification
An access control policy is a tuple acp= (sub, obj
v
,
pur, effect), where
–
A subject
sub
is defined as a tuple sub = <
u, so
> or sub = <
r,
so
>;
–
An object
obj
v
is a set of nodes in a sub-schema of
T
rooted
at node
v;
–
pur
is a set of business practices in healthcare domains;
–
effect
∈
{permit,deny} is the authorization effect of the
policy.
Examples:
–
P1:
(<GP, h1>, obj
Encounters
, {treatment}, permit)
–
P2
:
(<SP, h2>, obj
Medications
, {treatment,research}, permit)
–
P3:
(<Dr.Nic, h2>, obj
Labs
, research, deny)
Hypothesis
We propose a framework that ensures secure sharing
of EHRs supporting
–
Selective sharing on composite EHRs
•
Logical EHR model
•
EHR data schema composition
•
Cross-domain EHR instance aggregation
•
Access control policy specification
–
HIPAA-compliant EHRs sharing
•
Extracting policy patterns
•
Formulating policy specification
•
Transformation
HIPAA-compliant EHRs Sharing
Extracting Policy Pattern
Goal
–
Define a uniform policy scheme for HIPAA and system policy
transformation
Methodology
–
Identify key words from HIPAA rules or system policies;
–
Categorize identified key words into different class and give
a label;
–
Given a new rule or a policy, map each word to a class;
–
The composition of different labels construct a structured
pattern.
2012年8月12日星期日
Extracting Policy Pattern-Cont’d
Structured Examples
–
164.506(b)(1) A covered entity may obtain consent of the individual
to use or disclose protected health information to carry out
treatment, payment, or health care operations.
Extracted Pattern: <actor> <modality> <action> <object> to <action>
<object> for <purpose>
–
164.506(c)(1) A covered entity may use or disclose protected health
information for its own treatment, payment, or health care
operations.
Extracted Pattern: <actor> <modality> <action> <object> for
<purpose>
–
164.506(c)(2) A covered entity may disclose protected health
information for treatment activities of a health care provider.
Extracted Pattern: <actor> <modality> <action> <object> for
<purpose>
Generic Policy Specification
Our policy specification scheme is built upon the identified
policy patterns as a 8-tuple
p = <actor, modality, action, object,
purpose, condition, id, effect>
, where
–
actor
= < D, R, O >
is a 3-tuple, where
D
,
R
and
O
represent
disseminator, receiver, and owner, respectively;
–
modality
depends on the implication that a policy expresses;
–
action
is a particular action defined by a policy;
–
object
is a protected healthcare resource;
–
purpose
is the reason for an actor to perform an action on an
object;
–
condition
= < C
D
, C
R
, C
O
, C
CON
>
is a 4-tuple, where
C
D
, C
R
, C
O
and
C
CON
indicate conditions on disseminator, receiver, owner and context,
respectively;
–
id
is the citation to the portion of HIPAA regulations to which a
policy refers to;
–
effect
is the authorization effect of a policy including
permit
and
Transformation:
Abstract Representation
Transform both HIPAA regulations and healthcare system
Transformation:
Logic Representation
Transform the abstract representation into a logic
representation.
–
Adopt Answer Set Programming(ASP) as the underlying logic
programming;
–
ASP is a logic programming language
•
It represents the search problem as a logic program whose
stable models, called answer sets correspond to the solutions of
the problem
•
It finds these models using an answer set solver - a system for
computing stable models.
•
The syntax of a ASP rule is as:
<result> :- <precondition1>,
<precondition1>, …, <preconditionN>
.
–
V. Lifschitz. What is answer set programming. In Proc. of the AAAI Conference on
Transformation-Cont'd
–
Based on each element of the generic policy definition, we
define following ASP predicates:
•
decision(ID, EFFECT) where ID is a policy id variable and
EFFECT is a policy authorization decision variable;
•
actor(D, R, O) where D, R and O are variables respectively for
disseminator, receiver, and owner;
•
modality(M);
•
action(A);
•
object(OBJ);
•
purpose(P) and condition(C).
–
ASP representation of generic policy is expressed as follows:
•
decision(ID, EFFECT) :- actor(D, R, O), modality(M), action(A),
object(OBJ), purpose(P), condition(C).
Transformation Example
Step 1
–
Input
(Natural language representation of
HIPAA Policy)
•
164.506(c)(1) A cov
ered entity may use or disclose protected health information
for its own treatment, payment, or health care operations.
–
Output
(Abstract representation)
•
(<CE, CE, CE>, may, use, phi, treatment, N/A, 164.506(c)(1), allow)
•
(<CE, CE, CE>, may, use, phi, payment, N/A, 164.506(c)(1), allow)
•
(<CE, CE, CE>, may, use, phi, healthcare operation, N/A, 164.506(c)(1), allow)
•
(<CE, CE, CE>, may, disclose, phi, treatment, N/A, 164.506(c)(1), allow)
•
(<CE, CE, CE>, may, disclose, phi, payment, N/A, 164.506(c)(1), allow)
•
(<CE, CE, CE>, may, disclose, phi, healthcare operation, N/A, 164.506(c)(1), allow)
Step 2
–
Input
(Abstract representation)
•
(<CE, CE, CE>, may, use, PHI, treatment, N/A, 164.506(c)(1)(1), permit)
–
Output
(Logic representation)
•
decision(164506c11, permit):- actor(ce, ce, ce), modality(may), action(use),
object(phi), purpose(treatment), condition(na).
Analysis
Methodology
–
After two-step transformation, we have both ASP representations
of HIPAA regulations and healthcare system policies
–
Consider the ASP representation of HIPAA regulations as the
privacy/security property program F
–
Consider the ASP representation of system policies as the
program
G
–
Cast the compliance checking problem into the problem of checking
whether the program
G F H
has no answer sets, where
•
H
is the program expressing program
G
and program
F
has conflict decision
results
•
If no answer set is found, that implies the privacy/security property
F
is verified
•
Otherwise, an answer set returned by an ASP solver servers as a counterexample
that indicates why the program
G
does not entail
F
–
G. Ahn, H. Hu, J. Lee, and Y. Meng. Representing and reasoning about web access
System Design
Case Study_1
- Selective EHRs Sharing
Case Study_1
- Selective EHRs Sharing
Case Study_2 - HIPAA-compliant
EHRs sharing
Steps
–
Step1: Choose Healthcare System Policies
–
Step2: Policy Transformation
–
Step3: Terminology Mapping
–
Step4: Compliance Checking
Step 1
Example healthcare provider - OSF
Healthcare
–
It is owned and operated by the Sisters of the Third Order
of St. Francis, Peoria, Illinois.
–
http://www.osfhealthcare.org/
Chosen healthcare local policy examples
–
Example 1. OSF may share your information with your
doctors, hospitals or other health care providers to help
them provide medical care to you.
–
Example 2. OSF may use or share your information for
Step 2
Transformation
–
Generic policy specification based representation of policy
example 1
•
(<OSF, doctor, patient>, may, share, information, treatment, N/A, l11,
permit)
•
(<OSF, hospitals , patient>, may, share, information, treatment, N/A, l12,
permit)
•
(<OSF, health care providers , patient>, may, share, information,
treatment, N/A, l13, permit)
–
Corresponding ASP-based representation
•
decision(l11, permit) :- actor(osf, doctor, patient), modality(may),
action(share), object(information), purpose(treatment), condition(na).
•
decision(l12, permit) :- actor(osf, hospitals, patient), modality(may),
action(share), object(information), purpose(treatment), condition(na).
•
decision(l13, permit) :- actor(osf, hcp, patient), modality(may),
Step 3
Terminology Mapping
–
It entails mapping the natural language phrases in halthcare
systems’ policies onto the terminology used in HIPAA
regulations.
Step 4
Experiment Results
–
1
st
run:
no answer set is found, which
means the local healthcare policy complies
with the HIPAA regulations.
–
2
nd
run:
add following local healthcare
system’s policy with a policy ID of l12:
•
decision local(l12, deny) :- actor(osf,
hospitals , patient), modality(may),
action(share), object(information),
purpose(treatment), condition(na).
•
ASP solver find one answer set:
–
modality(may) action(share) action(use)
object(information) object(phi)
purpose(treatment) condition(na) actor(osf,
hospitals, patient) actor(ce, ce, ce) decision
local(l12, deny) decision hipaa(c11, permit)
•
It indicates a counterexample explaining the
violation of HIPAA regulations
Implementation
Implementation-Cont'd
Implementation-Cont'd
Patient Discovery Page & Composite EHRs
Implementation-Cont'd
Implementation-Cont'd
A transformation tool to support our two-step
transformation is implemented based on
OpenNLP open source project
Evaluation
Analyze
efficiency
and
scalability
Analyze
time
consumption by ASP
2012年8月12日星期日
Related Works
Access Control
–
Presented a patient-centric authorization framework to secure the sharing
of electronic health records[Jin'09].
–
Adopted the Chinese Wall security policy to control information flow in cloud
computing[Wu'10][Wu'12].
–
Presented a security model for healthcare application clouds[Zhang'10]
–
Presented patient-centric and fine-grained access control mechanism for
securing personal health records in cloud computing[Li'10].
Compliance Management
–
Presented a methodology to represent and reason about web access control
policies[Ahn'10].
–
Rigorous extraction of requirements from policies and
regulations[Breaux'06][Lee'06].
–
Presented a methodology to extract access rights and obligations directly
from regulation texts[Breaux'07].
–
Presented a production rule framework that software engineers can use to
specify compliance requirements for software[Maxwell'10].
2012年8月12日星期日
Conclusion & Contributions
We articulate access control and compliance
management issues in healthcare cloud computing
environments.
A novel framework based on access control policy and
logical techniques has been presented, which support
selective EHRs sharing and HIPAA-compliant EHRs
sharing
A prototype cloud-based EHRs sharing system has
been designed, implemented and evaluated to
demonstrate the effectiveness and efficiency of our
proposed approach.
Future Work
We would conduct more comprehensive evaluations on
our system with real-world healthcare datasets.
We would investigate how to address policy
composition issues and how to support fine-grained
delegation mechanism for EHRs in cloud computing
environments.
In addition, we would like to apply our approach to
support EHRs sharing using consumer devices such as
smart phone and tablet to cover border sections of
the whole healthcare ecosystem.
We would also study how cross-referenced policies
can be considered and accommodated to address all
aspects of HIPAA requirements.
2012年8月12日星期日
