Secure Sharing of Electronic Medical Records in Cloud Computing

Transcription

1 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

2 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

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

4 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

5 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, Slide 5

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

7 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 ACM, Slide 7

8 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

9 Secure EHRs Sharing Framework Overview Slide 9

10 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

11 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 ACM, Slide 11

12 EHR Data Schema Composition Slide 12

13 Algorithm for Merging Two EHR Data Schemas Slide 13

14 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

15 EHR Data Schema Composition Example Slide 15

16 Cross-domain EHR Instance Aggregation Slide 16

17 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

18 Policy Specification Cont d Slide 18

19 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

20 HIPAA-compliant EHRs Sharing Process of compliance management Slide 20

21 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

22 Extracting Policy Pattern-Cont d Structured Examples (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> (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> (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

23 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

24 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

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

26 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

27 Transformation Example Step 1 Input (Natural language representation of HIPAA Policy) (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, (c)(1), allow) (<CE, CE, CE>, may, use, phi, payment, N/A, (c)(1), allow) (<CE, CE, CE>, may, use, phi, healthcare operation, N/A, (c)(1), allow) (<CE, CE, CE>, may, disclose, phi, treatment, N/A, (c)(1), allow) (<CE, CE, CE>, may, disclose, phi, payment, N/A, (c)(1), allow) (<CE, CE, CE>, may, disclose, phi, healthcare operation, N/A, (c)(1), allow) Step 2 Input (Abstract representation) (<CE, CE, CE>, may, use, PHI, treatment, N/A, (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

28 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 th Annual IEEE Computer Software and Applications Conference, pages IEEE, Slide 28

29 System Design System Architecture Slide 29

30 Case Study_1 - Selective EHRs Sharing Scenario illustration Slide 30

31 Case Study_1 - Selective EHRs Sharing System workflow Slide 31

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

33 Step 1 Example healthcare provider - OSF Healthcare It is owned and operated by the Sisters of the Third Order of St. Francis, Peoria, Illinois. 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

34 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

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

36 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

37 Implementation Cloud environment illustration Slide 37

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

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

40 Implementation-Cont'd CONNECT implementation details Slide 40

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

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

43 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

44 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

45 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

46 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

47 Questions Slide 47