Protecting Privacy while Sharing Medical Data between Regional Healthcare Entities

Transcription

1 IBM Almaden Research Center Protecting Privacy while Sharing Medical Data between Regional Healthcare Entities Tyrone Grandison, Srivatsava Ranjit Ganta, Uri Braun, James Kaufman Session S113: Sharing Data Brisbane Convention Center Australia. August 23rd, 2007

2 Agenda Motivation Problem Goal Related Work Overview Concerns System Description Overview Technology Details Performance Evaluation Conclusion 2

3 Motivation The move to electronic healthcare systems promises a lot of benefits: better delivery of care, reduction in medical errors, improved quality of life. Existing business alliances must preserves. Thus, the formation of Regional Health Information Organizations (RHIOs) along these lines. A natural extension to the idea of a RHIO is to connect the RHIOs together into a National Healthcare Network Privacy concerns involved in inter- and intra- RHIO collaboration becoming increasing important in the public eye. 3

4 Problem Each RHIO has independent policies regarding the privacy of health records stored within the RHIO. Ensuring the privacy of health information when used inside the RHIO can be addressed by contemporary data disclosure technology. When two RHIOs need to share (clinical) documents, enabling the protection of patient privacy is still an open issue, because: There can be no assumption of a central authority, Policy enforcement may involve multiple privacy policies based on source, destination and the documents involved in the transfer, Data can be forwarded to an entity with additional rights, such as remote update rights. 4

5 Goal Enable inter-rhio collaboration while adhering to data disclosure constraints, i.e. privacy and security concerns. The technology is called Sticky Policy Enforcement and provides a way to ensure that policy constraints are enforced wherever patient data travels. This is a first step towards the broader mission of enabling Privacy Compliance After Extraction. 5

6 Related Work The Sticky Policy Paradigm was mentioned in IBM s work on Enterprise Privacy Authorization Language (EPAL) Sticky Policies recognized as a concept that is important for privacy preservation in distributed computer systems. The underlying notion is that the policy applicable to a piece of data travels with it and is enforceable at each point it is used. Though identified as a critical problem, application-independent solutions that were technically feasible and scaleable were not realized. Rivest and Lampson s work on SDSI (Simple Distributed Security Infrastructure) Focused on the establishment of trust for a single disclosure object with a single policy. A data recipient is either granted access to the entire document, or must request authorization from the source. Trusted Computing Group (TCG) consortium s work on Trusted Computing Platform An approach to establishing the trust in single object, single policy environments. 6

7 Concerns with Related Work In healthcare environments, granting access to the entire document and/or requesting authorization from the source is not sufficient. Sticky policy functionality should handle data disclosure to a party with welldefined constraints that allow data release to less privileged parties without requiring the originator s involvement. This avoids the potential pitfall of having to contact a (potentially) large number of third parties before making a decision to disclose a specific piece of information. Requiring targeted application development that are not application and data agnostic is not suitable for healthcare. RHIOs tend to follow a model where there is a complex web of pre-existing infrastructure that are likely to be from differing vendors and running different, even proprietary, systems. An ideal approach to Sticky Policy Enforcement should account for the fact that data changes occur frequently. It is not clear how the related work would handle this without incurring a severe performance penalty. 7

8 System Description Our solution to this problem involves identifying the applicable privacy policy constraints for a document(s) to be shared and sticking them together, forming a single entity of transfer a sticky policy package. In taking the approach of packaging policy with data, we maintain centralized decision making in a distributed enforcement. As only policy constraints that apply to the disclosed data are transferred, the communication impact is relatively small and the system does not require prior agreement among all medical organizations, states and patients. We leverage Hippocratic Database Active Enforcement for local data disclosure policy enforcement. Provides cell-level, policy-based disclosure management functionality, such that databases only return data that is compliant with company policies, applicable legislation, and customer preferences. 8

9 Sticky Policy Package Requestor: The requesting entity Recipient: The final consumer of the data. Purpose: The purpose for which the document(s) is being requested. Retention: Time period until which access to the data is allowed. Copy-Forward: The condition specifying whether the recipient is entitled to forward the requested document(s) to a third party after copying. Append-Modify: The Boolean condition specifying whether the recipient can append/modify the document. Results Tuples Policy Purpose Role Recipient Retention Copy forward Append-Modify Audit From To Timestamp Verifiable signature <XML> <Results> <Row>Robert Mueller</Row> <Row>Michael Hayden</Row> </Results> <Policy> <Purpose= Therapy /> <Role= Consultant /> <Recipient= same /> <Retention= 6 months /> <Copy forward= Yes /> <Append-Modify= No /> </Policy> <Audit> <From= CaliRHIO /> <To= PyschArizRHIO /> <Timestamp= 8/8/06 3:30pm /> <Signature>X</Signature> </Audit> </XML> 9

10 Sticky Policy Creation Request Sticky Policy HDB Active Enforcement Module Policy-compliant query Sticky Policy package HDB Sticky Policy Module Database 10

11 Sticky Policy Consumption Policy ID Purpose Role Recipient Schema Table Col Cond Copy fwd Retention 1 Therapy Consultant PsychAriz PAR Patients * Y 6 months Employee XML Signed Result First name Robert Michael Last name Mueller Hayden Archive XML-SR 1 CLOB <Result../> Scope Table Patients Policy 1 Condition XML SR=1 11

12 Performance Evaluation Cost of Sticky Policy Generation Overhead of Sticky Policy Consumption Overhead Cost for StickyPolicy Generation Overhead Cost for StickyPolicy Consumption Time(milli secs) HDB query w ithout sticky policies HDB query w ith stickypolicy generation Time(milli secs) XML Processing, Create and Insert Updating Metadata tables Updating archive Number of Documents Number of Documents The overall cost introduced by sticky policy generation is acceptable considering that the generation is done using XML. The time elapsed in updating the metadata tables and the archive is less than 30% of the overall policy consumption cost. 12 Our experimental platform used a synthetically generated dataset based on the Clinical Document Architecture. All experiments were run using IBM DB2 UDB 8.2. The operating system was Microsoft Windows XP with Service Pack 2. The hardware consisted of a PC with Pentium-4 2.4GHz processor and a 60GB disk. The buffer pool was set to 1 MB.

13 Conclusion The construction of RHIOs and the sharing of information between them is an important prerequisite for the successful creation and deployment of a National Healthcare Information Network. Very little attention has been placed on technology to enable this RHIO to RHIO collaboration in a privacy preserving manner, till now. We present a first step towards this goal: Sticky Policy Enforcement technology 13

14 The End