EMR Project

1. EMR Project Vanderbilt (Sztipanovits, Karsai, Ledeczi, Xue) Stanford (Mitchell, Datta, Barth, Sundaram) Berkeley (Bajcsy, Sastry, McCormick) Cornell (Wicker, Gerkhe, Machanavajjhala)

2. Project Summary • EMR is an integrative project with two main goals: • Contribute to solving privacy and security challenges of EMR systems applications • Use EMR application testbeds for the integration, testing and evaluation of new technologies on the following core TRUST research areas: • Model-based design for security and privacy • Formal modeling, verifying and enforcing privacy and security policies • Security and privacy technologies for sensor networks • Public policy to technology interactions • Research areas: • Patient Portals • In-home Patient Monitoring • Collaborations: • Inside TRUST: Vanderbilt, Berkeley, Cornell, Stanford • Outside TRUST: Vanderbilt University Medical School, University of Innsbruck

3. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

4. The National Challenge • GAO Report (05-628) on Health Information Technology • EMR-based Information Exchange and Interoperability saving estimateis $78B (2005 data) • Computerized order entry $44B • GAO Testimony (07-400T) • HHS not yet defined an overall approach to key privacy principles • Adequate security measures forprotecting health information remains a key challenge • Remote Patient Monitoring • Avoiding implosion of US health care: • Increased use of IT and pushing care delivery “closer to home”

5. Policy and Technical Challenges • Health Insurance Portability and Accountability Act of 1996 (HIPAA) • HIPAA Privacy Rule (2003): gives US citizens • Right to access their medical records • Right to request amendments, accounting of disclosures, etc. • HIPAA Security Rule (2005): requires healthcare organizations to • Protect for person-identifiable health data that is in electronic format • Complexity of privacy • Variable levels of sensitivity; “sensitive” in the eye of multiple beholders • No bright line between person-identifiable and “anonymous” data • Complexity of access rights and policies • Simple role-based access control is insufficient • Governing principles: “need-to-know” and “minimum disclosure” • Complexity of Clinical Information Systems (CIS) architectures, business processes and environments • Dynamic, data dependent information flows • Very large volume of system interactions

6. EMR Project Research Platforms • MyHealthAtVanderbilt (MHAV) Patient Portal • appointment management • secure messaging • access to lab data and • billing • over 25,000 patients • Berkeley ITALH testbed • multi-modal sensors • protocols for integratingwith MHAV • security and privacystudies ITALH/EMR Development Use Berkeley Motes, Fall sensors with accelerometers ITALH/EMR Development Target implementation Development and testing

7. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

8. 1. Patient Portal Research Area • Goal: systems design satisfying high-level requirements stated for • privacy, confidentiality, • integrity, • non-repudiation and • access control • Last year focus • formal architecture modeling of Patient Portals • formal modeling of privacy policies • integration of architecture models and privacy models into Patient Portal design models Doctor Nurse Electronic Health Record Patient Portal HIPAA Compliance Surrogate Patient

9. 1.1 Architecture Modeling • Patient Portals access to services of heterogeneous systems connected by un-trusted networks. • Architecture challenges: • Interoperability across systems and organizations • Security guarantees for stakeholders in a dynamic, open environment • Privacy guarantees without loosing utility • The focus is system and organization level security and privacy • Leveraging hardware, network, OS and code-level security approaches

10. We Model Patient Portals as SOA Domain specific modeling abstractions expressed informally defined DSML-s.TRUST research focus External Policy Enforcement Point PolicyDecision Pt. BPEL Process Manager Policy Repos. Configuration Engine SOA-based, standard, business process modeling platform BPEL4WS PolicyDecision Pt. Internal Policy Enforcement Point S1 S2 Sn SOA-based, standard, execution platform (simulation/fast proto.tng)

11. Toward a Modeling, Verification and Simulation Environment • Org. Models • Org. Structure • Roles • Workflow Models • Activities • Coordination • Service Models • Interface • Data • Policy Models • Privacy • Security Modeling and Integration Tools GME-based Modeling Tools Model Transformation Model Transformation Model Transformation Model Transformation GReAT-based Model Translators BPEL4WS WSDL XML-Conf XACML + XSD BPEL Modeling Platform Network • Analysis Tools • Policy Validation • Privacy Verification External Policy Enforcement Point PolicyDecision Pt. BPEL Process Manager Policy Repos. Config. Engine Configuration Tools Internal Policy Enforcement Point PolicyDecision Pt. S1 S2 Sn BPEL Execution Platform

12. Research Activities • Domain analysis • VU Medical School, TRUST research groups: Vanderbilt, Stanford, Berkeley • Regular meetings with physicians, software eng. staff, privacy and Security Officer • Use cases and incident case studies • System Analysis • Risks and Threats Analysis • Policy Analysis • Modeling • TRUST research groups: Vanderbilt, Stanford, Berkeley; VU Medical School • Formal specification of modeling languages • Building modeling and analysis tools • Domain Specific Modeling Languages • Domain Specific Policy Languages • Privacy preservation • Fast prototyping - simulation • BPEL4WS tools • TRUST research groups: Vanderbilt, Stanford • International collaboration (University of Innsbruck) • Mapping to target architecture

13. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

14. Research Spotlight Patient Portal Modeling Sean Duncave ISIS-VU Jan Werner ISIS-VU TRUST researchers and graduate students Vanderbilt Medical School researchers and staff Janos Mathe ISIS-VU Brad Malin VU Medical School Akos Ledeczi ISIS-VU Janos SztipanovitsISIS-VU

15. Modeling Languages • Modeling Tool Suite: GME • Specification • A domain specific modeling language (DSML) is a domain (a set of well formed models) along with a family of interpretations: • A metamodeling language is a DSML with an interpretation that maps models to domains. Interpretations are defined by model transformations. • A term algebraic semantics unifying models, model transformations and metamodels has been developed.(Jackson, Sztipanovits, 2006) • Four modeling views with abstractions matching domain characteristics • Well formedness rules enforced by modeling tool • May – August ’06 • team investigates SOA languages • team experiments with MHAV • November ’06 • first version of modeling languages and environment released • December ’06 – January ‘07 • work focuses on evolving modelingabstractions • February ‘07 - March ‘07 • policy modeling methods are tested Developing Abstractions Meta Models Critique Metamodel revision MHAV Case Studies Model evaluation Tm Test Models Modeling Tool

16. Architecture Challenges • Privacy/security in open, dynamic architectures • Structure of information flows are dynamic, data dependent and complex. • Policies are added and modified in the system. How can we guarantee and maintain privacy/security properties? Example: A new service added to the PP to provide lab information for patients. Are there privacy leaks? Research approach (Brad Malin): Data mining of audit files for discovering leaks and not-modeled information flows.

17. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

18. 1.2 Privacy Policy (Stanford) • Background: Distributed Access Control • Role-based Trust management (RT) • Recent work: Privacy, “Contextual Integrity” (CI) • Formal language for privacy policies • Information organized by type • Policies describe permitted communication • Considers past and future communications • Expresses much privacy legislation • Evaluated HIPAA, COPPA, and GLBA • Algorithmic results on policy analysis • Consistency and comparison in PSPACE • Weak compliance in polynomial time

20. Privacy Model: “Contextual Integrity” Charlie’s SSN is 078-05-1120 Alice Bob • Model disclosure, use of personal information • Messages has sender, receiver, subjects • Privacy depends on context, sequence of actions • Past and future relevant • Agents reason about attributes • Deduction based on combining information

21. CI Norms and Policies • Policy consists of positive, negative norms (+) inrole(p1, r1)  inrole(p2, r2)  inrole(q, r)  tt’     () inrole(p1, r1)  inrole(p2, r2)  inrole(q, r)  tt’     •  is an agent constraint •  is a temporal condition • Norms assembled into policy formula • p1,p2,q:P.m:M.t:T.incontext(p1, c)  send(p1, p2, m)  contains(m, q, t)   { + | +  norms+(c) }  permitted by pos norm  {  |   norms(c) } not prevented by neg norm Expressible in Linear Temporal Logic (LTL)

22. Gramm-Leach-Bliley Example Sender role Attribute Subject role Transmission principle Recipient role Financial institutions must notify consumers if they share their non-public personal information with non-affiliated companies, but the notification may occur either before or after the information sharing occurs If send(p1, p2, m) and inrole(p1, institution) and inrole(p2, non-affiliated) and contains(m, q, npi) and inrole(q, consumer), then eventually send(p1, q, notification) or previously send(p1, q, notification)

23. Results on “Contextual Integrity” • Expressiveness • Evaluated on privacy laws: HIPAA, GLBA, COPPA • Captured most privacy provisions • Missed de-identified health info in HIPAA • Laws used most features • Roughly as expressive as required • Policy refinement and combination • P1 refines P2 if P1 P2 • Requires careful handling of attribute inheritance • Combination is logical conjunction • Strong compliance: decidable in PSPACE • Weak compliance: decidable in Poly time

24. Related Languages • Legend:  unsupported o partially supported  full supported • CI fully supports attributes and combination

25. What problem does CI solve? What next? • Can formulate set of allowed uses and transmissions of information • Can check whether sequence of actions satisfies policy • How does an organization structure its business processes to satisfy policy? • Some actions done by people, not computers • What about audit, other problems? Questions came directly from discussion with VU Hospital

26. Research Spotlight Adam Barth Stanford Privacy and Utility in the MyHealth Patient Portal Anupam Datta Stanford/CMU TRUST researchers and graduate students Vanderbilt Medical School researchers and staff Sharada SundaramTCS John MitchellStanford

27. MyHealth@Vanderbilt Workflow Humans + Electronic system Health Answer Yes! except broccoli Appointment Request Secretary Health Question Health Question Now that I have cancer, Should I eat more vegetables? Doctor Patient Health Question Health Answer Utility: Schedule appointments, obtain health answers Nurse Privacy: HIPAA compliance+

28. Graph-based Workflow • Graph (R, R x R), where R is the set of roles • Edge-labeling function permit: R x R  2T, where T is the set of attributes • Responsibility of workflow engine Allow msg from role r1 to role r2 iff tags(msg)  permit(r1, r2) • Responsibility of human agents in roles Tagging responsibilities • Ensure messages are correctly tagged Progress responsibilities • Ensure messages proceed through workflow Also: general workflows characterized by ATL formulas

29. MyHealth Responsibilities • Tagging Nurses should tag health questions Gp, q, s, m. inrole(p, nurse)  send(p, q, m)  contains(m, s, health-q)  tagged(m, s, health-q) • Progress • Doctors should answer health questions Gp, q, s, m. inrole(p, doctor)  send(q, p, m)  contains(m, s, health-question)  F m’. send(p, s, m’)  contains(m’, s, health-answer) • Responsibility of workflow engine • LTL formula  • Feasible if  is asafety formula without contains() predicate • Responsibility of each role r • LTL formula r • Feasible if agents have a strategy to discharge their responsibilities  p.   inrole(p, r)  <<p>> r

30. Privacy Modeling Languages Specifying Privacy Logic of Privacy and Utility Specifying Utility Sample Results • If agents act responsibly, workflow achieves • Privacy in PSPACE: LTL model checking (SPIN) • Utility decidable: ATL* model checking (Mocha) • Auditing • Find agents accountable for locally-compliant policy violation in graph-based workflows • Find agents who act irresponsibly using audit log • Algorithms use oracle: O(msg) = contents(msg) • Minimize number of oracle calls Improved Workflow

31. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

32. 1.3 Integration of Architecture and Privacy Models • Privacy policies refer to: • Workflows, agents, roles, messages and message attributes, permitted communication using LTL expressions • Considers past and future communications • SOA models and policies describe • Workflows, services, organizations, roles, messages, message attributes, software architectures, deployment, access control and security policies. • Integration challenge • These models semantically overlap, the languages and models need to be integrated • Static and dynamic analysis tools need to be based on shared semantic domain

33. Ongoing Work • Gp, q, s, m. inrole(p, nurse)  send(p, q, m)  contains(m, s, health-question) •  tagged(m, s, health-question) • Gp, q, s, m. inrole(p, doctor)  send(q, p, m)  contains(m, s, health-question) •  F m’. send(p, s, m’)  contains(m’, s, health-answer) Common Semantic Domain • Semantic domain for policies can be very different: • structural constraints on models -> structural semantics (these policies can be expressed in the context of models using OCL (Object Constraint Language) • temporal constraints on the evolution of well formed model structures -> LTL + structural semantics (these policies require temporal logic extension of OCL) • constraints on system behavior -> behavioral semantics + computable reachability properties • temporal constraints on system behavior -> behavioral semantics + LTL

34. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

35. 2. In-Home Patient Monitoring Research Area • Motivation • Empower individuals and patients to better manage their health by providing them with information regarding their fitness and health through personal medical devices and services. • Allow loved ones and professional care givers to more accurately monitor and coach chronic disease patients and elderly individuals living independently. • Enable health care providers to offer better quality care through personalized health solutions assembled from a rich marketplace of interoperable health care devices and services. • Eliminate unnecessary costs from the healthcare system clinic-centered healthcare  patient-centered healthcare

36. End-to-End Information Flow • Real-time monitoring of elder people and/or patients • Heterogeneous sensor network for monitoring • Stationary sensors: Motion detectors, camera systems, etc. • Wearable sensor: Accelerometers, ECG monitors, etc. • Berkeley ITALH Testbed: seniors in Sonoma • Stationary sensors: Motion detectors, Camera systems • Wearable sensor: Fall sensors, Heart rate or pulse monitors

37. Design Challenges (Bajcsy) Goal: separate normal activities from abnormal activities or inactivities using wearable sensors. • Addressed design challenges: • Develop models for good and bad traffic. • Define criticality levels • Provide a metric, consider different prospective (patient, provider, insurance company,...) • Define relevance of observations. • Infer if and when to take actions based on traffic patterns and criticality level.

38. Fundamental Research • Low powerApproach: Taking advantage of high redundancy of wearable sensors. Method: distributed set-cover problem. • Limited Communication BandwithApproach: utilize nature of the applications. Method: application-aware data compression • Calibration and validationApproach: exploiting multi-modal sensing. Method: correlating vision data with motion sensor outputs.

39. Experimental Results • Experiments were conducted with four young subjects and seven elderly subjects performing the following tasks: • Walking on a straight line over a span of twenty feet • Sit down and stand up three times on three different seats • Lying down and getting up three time • Future Plans • The next step will be to take these platforms and try them at the Vanderbilt hospital for further testing for their reliability and robustness. Stand-Lie Sit-Stand Lie-Stand Stand-Sit Movement classification with constant inclination feature Complex movements Simple movements Movement classification with SVD feature

40. Outline Project Motivation • Research Platforms • Patient Portal Research Area 1.1 Architecture Modeling Research Spotlight on Patient Portal Modeling 1.2 Privacy Policy and Compliance Research Spotlight on Privacy and Utility Modeling 1.3 Integration of Architecture and Privacy Models • In-Home Patient Monitoring Research Area Research Spotlight on Data protection in Video Network Systems

41. Research Spotlight Data Protection In Video Network Systems TRUST researchers and graduate students Vanderbilt Medical School researchers and staff

42. Experimental System Architecture • A Service-Oriented Architecture Access Policy Gateway License Management request Database server key Video sensor network Encryption request Web server Watermarking Content server Decryption User “Digital right management for video sensor networks”, Proc. of ISM 2006

43. Experiment Results Access permitted Access denied Original scene Watermarked images from two cameras Encrypted images Images accessed by user Time (ms) Current work: Selective encryption based on object recognition Watermark size/image size overhead in watermarking

44. Future Plans • Integration of medical-sensor data and video sensor data • Data fusion and decision making (diagnosis) • System Deployment and Experiment in • Vanderbilt Home Care Services, Inc. (http://www.mc.vanderbilt.edu/homecare/) • Mckendree Village (http://www.mckendree.com/)