Secure Sharing of Electronic Medical Records in Cloud Computing

Secure Sharing of Electronic Medical Records in Cloud Computing MS Thesis Defense: Ruoyu Wu Graduate Supervisory Committee: Dr. Gail-Joon Ahn, Chair Dr. Sik-Sang Yau Dr. Dijiang Huang The Laboratory of Security Engineering for Future Computing (SEFCOM) URL : sefcom.asu.edu BYENG 486 ASU

Outline Introduction Problem Summary Secure EHRs Sharing Framework in Clouds Selective EHRs sharing HIPAA-compliant EHRs sharing System Design Implementation and Evaluation Related Work Conclusion and Future Work Q & A Slide 2

Internet-centric Cloud-driven World SaaS Ecosystem PaaS IaaS Slide 3

Healthcare Evolution Paper-based records transform to EHRs EHRs are shifting to Clouds Transform Shift Paper-based Sharing Efficiency Ubiquitous Access EMRs Cost efficiency Dynamically scalable Cloud Platform Slide 4

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 environments. Security & Privacy, IEEE, 8(6):24 31, 2010. Slide 5

Access Control Issue Cross-domain EHRs integration Diversity of healthcare practitioners Slide 6

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 System Policies All System States EMR System define enforce to comply HIPAA Regulations Treats cause loss 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. Slide 7

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 Compliance analysis Slide 8

Secure EHRs Sharing Framework Overview Slide 9

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 Compliance analysis Slide 10

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. Slide 11

EHR Data Schema Composition Slide 12

Algorithm for Merging Two EHR Data Schemas Slide 13

EHR Data Schema Composition Example r s T s m r d m T d m Merge to Call insertsubschema(t d, r d, T s, r s ) r d = r s -> m = r d Otology Classes Demographic, Demo Gender, Sex DoB, Birthday, Birth Date Slide 14

EHR Data Schema Composition Example Slide 15

Cross-domain EHR Instance Aggregation Slide 16

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) Slide 17

Policy Specification Cont d Slide 18

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 Compliance analysis Slide 19

HIPAA-compliant EHRs Sharing Process of compliance management Slide 20

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

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

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 deny. The Laboratory of Security Engineering for Future Computing 2012 年 8 月 12 日 星 期 日 Slide 23

Transformation: Abstract Representation Transform both HIPAA regulations and healthcare system policies into abstract representation; The Laboratory of Security Engineering for Future Computing 2012 年 8 月 12 日 星 期 日 Slide 24

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 Artificial Intelligence, pages 1594 1597, 2008. The Laboratory of Security Engineering for Future Computing 2012 年 8 月 12 日 星 期 日 Slide 25

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). The Laboratory of Security Engineering for Future Computing 2012 年 8 月 12 日 星 期 日 Slide 26

Transformation Example Step 1 Input (Natural language representation of HIPAA Policy) 164.506(c)(1) A covered 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). The Laboratory of Security Engineering for Future Computing 2012 年 8 月 12 日 星 期 日 Slide 27

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 control policies. In 2010 34th Annual IEEE Computer Software and Applications Conference, pages 137 146. IEEE, 2010. Slide 28

System Design System Architecture Slide 29

Case Study_1 - Selective EHRs Sharing Scenario illustration Slide 30

Case Study_1 - Selective EHRs Sharing System workflow Slide 31

Case Study_2 - HIPAA-compliant EHRs sharing Steps Step1: Choose Healthcare System Policies Step2: Policy Transformation Step3: Terminology Mapping Step4: Compliance Checking Slide 32

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 certain types of public health or disaster relief efforts. Slide 33

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), action(share), object(information), purpose(treatment), condition(na). Slide 34

Step 3 Terminology Mapping It entails mapping the natural language phrases in halthcare systems policies onto the terminology used in HIPAA regulations. Slide 35

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 Slide 36

Implementation Cloud environment illustration Slide 37

Implementation-Cont'd Home Page & Policy Specification Page Slide 38

Implementation-Cont'd Patient Discovery Page & Composite EHRs Access Page Slide 39

Implementation-Cont'd CONNECT implementation details Slide 40

Implementation-Cont'd A transformation tool to support our two-step transformation is implemented based on OpenNLP open source project Slide 41

Evaluation Analyze efficiency and scalability Analyze time consumption by ASP Slide 42

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]. Slide 43

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. Slide 44

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. Slide 45

Publications Towards HIPAA-compliant Healthcare Systems, Ruoyu Wu, Gail-Joon Ahn and Hongxin Hu (ACM IHI 12) Information Flow Control in Cloud Computing, Ruoyu Wu, Gail-Joon Ahn, Hongxin Hu, and Mukesh Singhal (TrustCol 10) Information Flow Control in Clouds, Gail-Joon Ahn, Ruoyu Wu, Hongxin Hu and Mukesh Singhal (IEEE Transactions on SMC, revision) Risk-Aware Mitigation for MANET Routing Attacks, Ziming Zhao, Hongxin Hu, Gail-Joon Ahn and Ruoyu Wu (IEEE TDSC 10) Risk-Aware Response for Mitigating MANET Routing Attacks, Ziming Zhao, Hongxin Hu, Gail-Joon Ahn and Ruoyu Wu (GLOGBECOM 10) Slide 46

Questions Slide 47