Tackling the Information Protection Essentials of Health Information Exchange. Carol Diamond, MD, MPH Managing Director, Markle Foundation

Transcription

1 Tackling the Information Protection Essentials of Health Information Exchange Carol Diamond, MD, MPH Managing Director, Markle Foundation

2 Connecting for Health A Public Private Collaborative Convened and operated by the Markle Foundation since 2002 Works to accelerate the development of a health information-sharing environment to improve the quality and cost effectiveness of health care Brings together private, public, and not-forprofit groups

3 CFH Guiding Principle: Technological design decisions developed in sync with policies and business rules that foster trust and transparency Avoid public clamor for hasty remedies after serious compromises occur Avoid retrofitting complex technologies at great costs

4 Our Journey Connecting for Health Roadmap June 2004: decentralized and open standards-based information network proposed a Common Framework of privacy and technology attributes that accepts and encourages local variation and innovation while achieving interoperability and portability across geographic regions based on a framework of privacy and built on a model of trust In April 2006, CFH Common Framework was fully documented and tested in a prototype implementation in Boston, Indianapolis and Mendocino County, California.

5 The Connecting for Health Common Framework Articulates only what must be common for interoperability and trust across the network Comprised of specific technology standards, health information policies, and model participation agreements (contract). We convened both local stakeholders and the nation s leading experts in privacy, law, health information technology and health care delivery. The Common Framework is in the public domain and has been widely distributed and referenced.

6 Key Attributes of the CFH Common Framework 1. Decentralized and Distributed Architecture 2. Index that Separates Demographic from Clinical Information 3. A Flexible Platform for Innovation 4. Implement Privacy through Technology 5. Nine Foundational Privacy Principles

7

8 What this is A starting point A resource to generate more policy work and discussion An effort establish an initial set of essential policy topics and issues that need to be addressed An attempt at providing a tool and some model language for others to customize based on their individual needs

9 What this is not A turn-key solution A substitute for thoughtful discussion and vetting A complete answer

10 Connecting for Health Policy Subcommittee Looked at HIE in the context of HIPAA and existing state laws Developed a list of significant topics from Members experience with early information exchange networks Members own expertise

11 Connecting for Health Policy Subcommittee About 40 experts in Law Health privacy and ethics Health care delivery Administration Technology Health Information Exchanges Two outside law firms hired for legally technical work It took one year to develop the principles, policies and model contract

12

13 P1: Architecture for Privacy in a Networked Health Information Environment 1. Openness and Transparency Is it easy to understand what policies are in place, how they were determined, and how to make inquiries or comment? Is it clear who has access to what information for what purpose? 2. Purpose Specification and Minimization What is the purpose of data collection data? Are the purposes narrowly and clearly defined? 3. Collection Limitation Are only those data needed for the specified purposes being collected Are subjects fully informed of what is being collected?) 4. Use Limitation Will data only be used for the purposes stated and agreed to by the subjects?

14 P1: Architecture for Privacy in a Networked Health Information Environment 5. Individual Participation and Control Can an individual find out what data has been collected and exercise control over whether and with whom it is shared? 6. Data Integrity and Quality How are data kept current and accurate? 7. Security Safeguards and Controls How are the data secured against breaches, loss or unauthorized access? 8. Accountability and Oversight Who monitors compliance with these policies and how is the public informed about violations? 9. Remedies How will complaints be handled? Will consumers be able to respond to or compensated for mistakes in decisions that are based upon the data?

15 The Privacy Principles are Interdependent! Openness Remedies Purpose Specification Accountability Security Collection Limitation Data Integrity Individual Participation and Control Use Limitation

16

17 P2: Model Privacy Policies and Procedures Establish baseline privacy protections participants can follow more protective practices Based on HIPAA, although some policies offer greater privacy protections Rooted in nine privacy principles Should be customized to reflect participants circumstances and state laws

18 P2: Model Privacy Policies and Procedures SNO Policy 100: Compliance with Law and Policy SNO Policy 200: Notice of Privacy Practices SNO Policy 300: Individual Participation and Control of Information Posted to the RLS SNO Policy 400: Uses and Disclosures of Health Information Integrates HIPAA permissible purpose and minimization premises Uses for TPO are permissible Generally, uses for law enforcement, disaster relief, research, and public health are permissible Marketing not permissible Discrimination not permissible

19 P2: Model Privacy Policies and Procedures SNO Policy 500: Information Subject to Special Protection SNO Policy 600: Minimum Necessary SNO Policy 700: Workforce, Agents, and Contractors SNO Policy 800: Amendment of Data SNO Policy 900: Requests for Restrictions

20

21 P3: Notification and Consent When Using a Record Locator Service Addresses question: what should an institution participating in the RLS be required to do to inform patients and give them the ability to decide not to be listed in the RLS index? Recommendation more protective of privacy than HIPAA

22 P3: Notification and Consent When Using a Record Locator Service Information on patients of participating institutions included in RLS on day one (patient names, demographics, and institution names) Patient must be given notice that institution participates in RLS and provided with opportunity to opt-out of index Revision of HIPAA Notice of Privacy Practices Initial Inquiry Audit Patient access to RLS record

23

24 P4: Correctly Matching Patients with their Records How should we optimize matching probabilities while minimizing incidental disclosures and clinical risk caused by false positive matches within the Record Locator Service? Involves issues of proper use and disclosure of health information and data quality

25 P4: Correctly Matching Patients with their Records A false positive match is an incidental disclosure under HIPAA Utilize a probabilistic matching algorithm with a high probability threshold for matching (a minimal level of certainty of 1 in 100,000 before RLS returns a matching record). In addition: No wild-card queries (ex. all Smiths ) Return no data not contained in query No Break the Glass queries

26

27 P5: Authentication of System Policy questions involved: Identity (Who am I?) Users Identifiers (How do I represent my Identity?) Authentication (How can I prove who I am?) Authorization (What can I do when I ve proved who I am?) Involves issues of security safeguards and controls and accountability

28 P5: Authentication of System Users SNO must have identifiers for all participating entities Users must be authenticated before given access to any SNO-wide resource containing patient data Any request for data from a remote institution must have two pieces of identifying information (institution authenticating user and identifier for user)

29 P5: Authentication of System Users Break the Glass not allowed in RLS itself For patient to access his or her own records, initial access must be provided by participating institution or third-party recognized by SNO

30

31 P6: Patients Access to Their Own Health Information HIPAA Right to See, Copy, and Amend own health information Accounting for Disclosures Covered entities required to follow both Privacy Rule and related state laws Allows stronger privacy safeguards at state level

32 P6: Patients Access to Their Own Health Information Patient access to the information in the RLS Each SNO should have a formal process through which information in the RLS can be requested by a patient or on a patient s behalf Participants and SNOs shall consider and work towards providing patients direct, secure access to the information about them in the RLS

33

34 P7: Auditing Access to and Use of an HIE What audit and logging practices should be practiced? Involves issues of openness and transparency, security safeguards, and accountability HIPAA the baseline Privacy Rule does not specifically mention audits or logging but requires covered entities to have in place appropriate safeguards Security Rule requires audit controls as a standard State laws may also exist

35 P7: Auditing Access to and Use of an HIE RLS should follow strong logging and audit control standards Flow of demographic information will be carefully tracked at RLS level Transfers of clinical records will not take place through RLS; subject to practices of each entity Additional logging and audit control functions recommended at SNO and RLS levels Audit of VIP records, procedures for follow-up on suspicious activity, etc.

36

37 P8: Breaches of Confidential Health Information Must report any breaches and/or security incidents. Participants and SNOs should inform affected people are notified in the event of a breach SNO contract could include provision allowing Participant withdrawal from SNO in case of serious breach of patient data SNO contract could include indemnification provisions pertaining to breach of confidentiality of protected health information

38

39 M1 & M2: Enforcement Mechanism Multilateral agreement among parties sharing information (hub and spokes model) Purpose of Model SNO Terms and Conditions To create a mechanism of enforcement To assist HIEs prepare their own solution Identify issues and alternatives Raise questions

40 M1 & M2: Model Contract Essential Components Incorporates applicable terms of Common Framework Policies and Procedures Provides specific terms that the individual SNO may determine are appropriate for its unique needs Includes mechanism for making and implementing changes Recent AHRQ Webinar: A National Web conference on Model Contract Language for Health Information Exchange

41 Thank You Questions?