Health Information Exchanges (HIEs): The Impact of HIPAA and the HITECH Act December 4, 2009

1. Health Information Exchanges (HIEs): The Impact of HIPAA and the HITECH Act December 4, 2009 Linda M. Kinney, MHA Care Share Health Alliance Alicia Gilleskie, Esq. Smith, Anderson, Blount, Dorsett, Mitchell & Jernigan, L.L.P. David Kirby, KirbyIMC.com Dial: 1-866-740-1260 Passcode: 8618356

2. Webinar Logistics • If you have problems accessing the audio or visual portion of this webinar call: 919-861-8355 • All lines will be muted during the presentation • To ask a question during the Questions & Answers section: • Unmute press: *7 • Mute press: *6 • Please provide us with feedback about the webinar by completing the post-webinar survey

3. Webinar Overview • Introduction to Care Share Health Alliance: Linda Kinney • Presentation: Alicia Gilleskie and Dave Kirby • Background on Health Information Exchanges, HIPAA and the HITECH Act • The Impact of HITECH on Health Information Exchanges • Risk management issues to consider • Question & Answer Session – moderated by Linda Kinney

4. Introduction • Linda Kinney

5. What is Care Share Health Alliance? • Care Share is an independent, statewide resource that brings people together to improve the health of low-income, uninsured persons. • We do this by supporting the development of Collaborative Networks, building collaboration between providers and strengthening the safety net. • We provide technical assistance around building collaboration, program development, capacity building, evaluation, business process assessment, and community-wide planning. • For more information visit: www.CareShareHealth.org

6. Collaborative Networks and Data Sharing • The goals of Collaborative Networks and collaboration between providers is to: • Improve access and the delivery of services • Reduce duplication • Facilitate effective and efficient utilization of services • Maintain quality of care • To do this effectively collaborative partners must share information with each other. Including electronic health information.

7. Presentation • Alicia Gilleskie and Dave Kirby

8. Health Information Exchanges (HIEs): The Impact of HIPAA and the HITECH Act • Presentation • Background on Health Information Exchanges, HIPAA and the HITECH Act • The Impact of HITECH on Health Information Exchanges • Risk management issues to consider

9. Health Information Exchanges (HIEs) • What is a Health Information Exchange? • Improved Collaboration • Allows transparency for treatment, care coordination, quality assessment and improvement activities, such as case management, outcome evaluations, development of clinical guidelines • Emerging HIEs in NC • NC is a pioneer state in HIE implementation

10. Health Information Technology for Economic and Clinical Health Act (“HITECH”) • What is HITECH? • Enacted as part of the American Recovery and Reinvestment Act of 2009 • Expansive changes to HIPAA aimed at encouraging the sharing of electronic health information • Provides funding assistance and incentives to encourage implementation of electronic health records (EHRs)

11. Key Traditional HIPAA Privacy/Security Elements Related to HIEs D

12. The HIPAA Privacy Rule- key HIE elements • Permission and requirements to disclose PHI • Uses and disclosures via an HIE are still covered under the Privacy Rule’s set of permitted and required uses and disclosures. HITECH has new requirements to disclose electronically to patients • Mitigation of Harm • Mitigating harm from an impermissible use/disclosure is still a requirement that is in effect and covers non-permitted disclosures/uses via HIE. HIEs introduce more risk that if not neutralized will lead to more harm to be mitigated. New Notice of Breach provisions in HITECH more specifically address one form of harm. D

13. The HIPAA Privacy Rule- key HIE elements • Accounting of disclosures • Providing an accounting of a limited list of disclosures (e.g. public health case reporting) to the patient upon request is still a requirement. A new HITECH element requires accounting of e-disclosures for treatment, payment and operations. Most HIE disclosures are likely to require an accounting. Some forms of HIE’s do this automatically or avoid the need for accounting by being the patient’s agent. • Provision of designated record set to patients. • This requirement is still in effect and is extended with a specific HITECH requirement to transmit ePHI to patients (likely via an HIE) • Required public good disclosures (e.g. public health reportable conditions) • These disclosure requirements are still in effect and some forms are required to be done electronically (likely via an HIE) under HITECH. D

14. HIPAA Security Rule – key HIE elements • Use of encryption on open networks • Most HIEs are designed to operate on open networks. This requirement in the Security Rule compels the use of encryption. New HITECH requirements make use of encryption attractive for all PHI data flows and data stores – especially in HIEs. • Audit log collection and use • This requirement is still present and EHR interactions with HIEs will likely mean that more use and review will be needed to be done to manage the increased risks to confidentiality. D

15. HIPAA Security Rule – key HIE elements • Security incident management • This requirement to report and respond to security incidents will be especially important in an HIE environment to reducing harm and maintaining public confidence in HIE. There will likely be more occasions when many organizations will be involved in responding to one incident. • Data integrity • This requires that there be protections against loss/corruption of PHI. This becomes more challenging in an HIE environment where new data arrives routinely from a variety external sources. • Data access management • This requirement to limit access is more challenging to meet in an HIE environment where there are more people with changing access rights over shorter periods of time. Person-oriented HIE models let patients define the rules for sharing across organizations. D

16. HIPAA Security Rule – key HIE elements • Contingency management • Availability of data in an HIE is critical – and especially difficult for federated model HIEs (where the data is retained in the originating organizations). So, contingency management at provider sites (where the data will be until requested) will be harder and more important. D

17. Other HIE-related laws • NC State Law: Notice of breach (NC ITPA 2005) • This law would apply to breaches as part of the typical HIE’s operations. One would expect more breaches in an active HIE. This applies to any business or government agency in NC including ASP EHR operations, web-based PHR operators, HIE operators. • Other: Special regulations covering drug and alcohol treatment records, and mental health records (42 CFR Part 2), Red Flags, FERPA • These laws apply to an HIE environment when the contributing entities are covered. Observing each law in an entity-oriented HIE environment will require more work. Somewhat less work in a person-oriented HIE (where the patient agent is controlling the data.) D

18. A Sampling of HITECH provisions and their Potential Effects on HIEs

19. HITECH Act • Changes to HIPAA • Expanded Responsibilities and Liability for Business Associates • Breach Notification • Enforcement • Penalties • Restrictions • Accounting of Disclosures • Sale of PHI • Meaningful use of EHR • Will HITECH encourage or hinder the sharing of electronic health information?

20. Business Associates • Definition of Business Associate (“BA”) • A person who, on behalf of a Covered Entity (“CE”) performs a function or activity involving the use or disclosure of PHI (excluding members of the CE’s workforce). • Business Associate Agreement (“BAA”) • Written contract with CE governing the use and disclosure of PHI and protection of privacy rights • Include certain specific provisions required under HIPAA Privacy and Security Rules

21. Business Associates • Contractors or other non-workforce members doing work for CE where work involves use/disclosure of Protected Health Information (“PHI”) • A CE can be a business associate of another CE • HITECH clarifies that organizations such as HIEs, Regional Health Information Organizations (RHIO) and eRx gateways that provide data transmission of PHI, that require routine access to PHI are BAs and must enter into BAAs with the CE

22. Expanded Role and Liability for Business Associates • Explanation: Business Associate compliance with BAAs become a direct requirement of HIPAA. Expanded oversight role by Business Associates. • Effective date: 2/17/2010 • Key Effects on HIEs: Non-compliance may constitute direct violation of HIPAA and BAA, posing risk of “double” liability

23. HIPAA Security Rule Compliance • Explanation: Today, BAs are contractually responsible for compliance with the “mini” HIPAA Security Rule. BAs become responsible for complying with the full HIPAA Security Rule. • Effective date: 2/17/2010 • Key Effects on HIEs: All parties to HIE (covered entities and business associates) may be bound by the HIPAA Security Rule Standards (required or addressable): • Administrative Safeguards • Physical Safeguards • Technical Safeguards • HIPAA Security Rule organizational requirements, policies, procedures and documentation requirements

24. Breach Notification • Explanation: Breach notification provisions apply to CEs and BAs. CE obligation to notify each individual whose unsecured PHI has been, or is reasonably believed to have been, accessed, acquired, used or disclosed as a result of the breach. BAs required to notify CEs following BAs discovery of a breach of unsecured PHI. • Key issues: what constitutes a “breach” and “unsecured PHI” • Effective date (already past): 9/23/2009 • Key Effects on HIEs: Increased time spent by all parties analyzing whether breach notice obligation triggered and how to notify. • Upside for patient privacy • Downside for compliance coordination among parties

25. Breach Notification • CE Notice Requirements • Recipients • Notify affected individuals whose PHI has been or is reasonably believed to have been breached • Timing • Without unreasonable delay, but in no event later than 60 days following discovery (unless it would impede a criminal investigation) • Content • What happened • Types of unsecured PHI • What CE is doing to investigate the breach, mitigate harm, protect against further breaches • Contact procedures for affected individuals, including toll-free number, email address, website or postal address

26. Breach Notification under HITECH • BA Notice Requirements • Recipients • Notify CE “to which the breached information relates” • Timing • Without unreasonable delay but no later than 60 days following the BAs discovery of the breach • Content • Identify affected individuals to the extent possible and other information available to BA

27. Enforcement • February 17, 2009: State attorneys general authorized to bring civil actions to enforce HIPAA violations • Attorneys general bringing civil actions under HIPAA must give DHHS opportunity to intervene • February 17, 2010: HIPAA criminal enforcement provisions apply to individuals • Criminal fines and jail time for intentional violations • U.S. Department of Justice investigates and prosecutes criminal violations • February 17, 2011: DHHS must formally investigate complaints where preliminary investigation indicates potential violation of HIPAA due to willful neglect • Key Effects on HIEs: Potential deterrent effect on individual misconduct may lessen oversight burden of entities participating in HIEs. On the other hand, enforcement will increase, making attention to compliance a priority.

28. Greater Penalties • Civil Penalties • Previously, civil monetary penalties (CMPs) limited to $100 per violation, not to exceed $25,000 for identical violations during a calendar year • Key Effects on HIEs: Money talks. These will hit home for covered entities and business associates participating in HIEs.

29. Self-pay episode disclosure restrictions -Section 13405(a). • Explanation: People who have health insurance sometimes pay for care out of pocket in order to protect their privacy. Some providers have had a history of nonetheless reporting these self-pay episodes to payers- thwarting that privacy need. This new restriction requires covered entities not to disclose data (electronic or paper) from such self-pay episodes if a patient requests this. • Effective date: 2/17/2010; no regulations • Likely key effects on providers: • Most providers won’t change disclosure policy, but will likely want to revisit how they document and implement requests to restrict disclosures (as required in the Privacy Rule) • For providers who allow access to records by payer-based case managers (e.g. hospitals), efforts will have to be made to segregate self-pay data. • In EHRs, as data is reused in various functions, segregation of self-pay data may be challenging. (e.g. allergy data collected in a self-pay episode) • Definition of “episode of care” will need attention. D

30. Accounting of Treatment, Payment, Operations (TPO) Electronic Disclosures- Section 13405(c ) • Explanation: The HIPAA Privacy Rule has long required that a list of non-TPO disclosures be reported to the patient upon request (i.e. provided date, recipient, content description, purpose). The new requirement adds that all electronicdisclosures by EHR-using CEs and BAs made for TPO purposes going back 3 years also be reported to the patient upon request. Covered Entities can either report for BAs or direct patients to BAs for supplemental reports. • Effective Date: For those who have an EHR on 1/1/09, accounting starts 1/1/2014; For those who acquire EHR after 1/1/09, accounting starts 1/1/11 or when EHR is acquired, whichever is later. HHS can delay a couple of years if desired. Expect regulations 7/2010. • Likely key effects on providers: • e-TPO disclosures are common (e.g. to payers, referrals) and will become much more common as people approach “meaningful use” objectives. • Collecting the data may not be much of an additional burden – most CEs would want the log of accounting data for their own use. • HHS will make regs on which data goes into the accounting. (about 7/10) • BA Agreement and process adjustments. (Will you do the accounting for BA work or will the BA?) D

31. Selling PHI - Section 13405(d ) • Explanation: CEs and BAs who receive direct or indirect remuneration for providing PHI to third parties must have patient authorization (HIPAA style). The issue being addressed with this requirement is that the prior restrictions in HIPAA on PHI sale were thought to still allow too much sale of PHI outside of patient expectations. CE/BA can receive remuneration disclosures for: public health (limited), research (limited), treatment, CE sale to CE, payment of BA, patient. Some HHS leeway to define other exceptions.) • Effective Date: No later than 2/17/2011 – HHS regs by 8/17/2010, • Likely key effects on providers: • Most providers not affected • Revisit of practices related to BAs, research, public health. D

32. Patient right of electronic access to ePHI- Section 13405(e) • Explanation: HIPAA Privacy Rule established a federal right to patient access to PHI (the designated record set) under virtually all circumstances. This ARRA provision adds a right for the patient to obtain an e-PHI copy from EHR-using CE or direct that the CE transmit e-PHI copy directly to patient-chosen entity or person. (e.g. “Send my ePHI to my PHR”). CE charges limited to labor costs. Note that this right is separate from the meaningful use of EHR objectives that require engaging patients and families with HIT. • Effective Date: No regs explicitly called for; No explicit date found; likely 2/17/10 • Likely key effects on providers: • “transmit” may mean transmit- not hand a CD or thumb drive copy. • Support extent for interfaces to recipients (e.g. HealthVault, Google Health, iHealthRecord, Keas – and lots of others) not clear. • This requirement is a key incentive to use patients as pivots for sharing data generally. • Potential for abuse – e.g. marketers becoming valid recipients without informed consent of patient. • Identifying patients (e.g. keeping PHR identifier) D

33. Meaningful use (MU) of EHR- Sec Medicare: 4101(ambulatory), 4102 (hospitals), 4013,4104, Medicaid: 4201 • Explanation: A large scale ($17B, ~$600M in NC) incentive program to encourage EHR/PHR usage. Typical provider (e.g. physician, NP, PA) gets $45K-$60K in form of Medicaid/Medicare bonus reimbursement for: 1)meaningful use of certified EHR, 2) HIE, reporting on MU. 70 recommended objectives spread over 5 years in these areas: Engaging patients and families (PHRs etc), improving care coordination, ensuring adequate privacy and security, improving population and public health, improving quality, safety, efficiency and reducing health disparities. • Effective Date: Incentive payments are per year with a lot of front loading starting in 2011 (to 2015). Some chance of penalties for non-MUser Medicare providers after 2015. ; Draft regs 12/09. • Likely key effects on providers: • Serious money; serious challenge; Much more electronic communication with patients. • Can’t do it alone (especially the HIE part) • Private payers will likely follow suit (i.e. condition payment on EHR/PHR usage) • Very complicated; careful planning required. • Other programs (Regional Extension, State HIE Collaborative, EHR loan) support. D

34. Risks of HIEs and Related HITECH Considerations

35. HIE Challenges and Risks • Maintaining “Purity” of Database Contents • Integrity, right to use and disclose, confidentiality • Multiple data sources • Multiple party access • Need to conduct data flow compliance analysis • Ensuring appropriate BAAs are in place • User education

36. HIE Challenges and Risks • HITECH • Potential “double jeopardy” for BAs • Increased operational duties and liability exposure under a new, complex operational scheme • Risk of “poisoning the well” and using data provided by third parties without proper authorization

37. Distribution of Security Risks • The issue: • The typical provider focuses primarily on security for its internal operations and considers risk to itself. (e.g. risk of inappropriate use/disclosure of PHI, uptime of the system, local data integrity issues) • In an HIE security risks are distributed across the HIE users. • The risk sharing model must satisfy each party (e.g. hospital, physicians, payers, patients, public health, researchers) or they won’t participate fully (or at least resist participating). • Making security cost-benefit tradeoffs that satisfy everyone in the sharing system is harder than making tradeoffs that only have to satisfy you. • Likely key impacts on providers: • Concerns about PHI confidentiality, integrity, and availability will need to be revisited with this new sharing model in which disclosures are frequent and automatic. • Need for auditable standards in the HIE and at the connected parties’ systems. D

38. Size and dynamism of the routine data sharing community • The issue: • Typical HIE will have a large and dynamic community of information providers and recipients. – (e.g. hospitals, physicians, patients, payers, researchers, public health). • Consider the challenge of managing registration, authentication, access audits, and authorizations among the members of this large and dynamic group. • How will access changes be made when practitioners are no longer eligible for access (retired, quit, fired). How will changes in the legal competence of individuals affect access? • Just to make things interesting – you can’t depend on having a compulsory universal health identifier. • Likely key impacts on providers: • There will be new external ids (of patients, other providers) for each provider to keep and use. • Providers will likely have to register/de-register staff for access to external data. D

39. Use of comprehensive longitudinal patient record (CLR) • The issue: • Having all of the relevant historical data about a person accessible for care, research, personal use is the core attraction for an HIE. • But, having this CLR also raises the risk of inappropriate disclosure. • Data shared via an HIE may be used over longer times and for purposes not expected by the data originator. The limits on time and usage today help manage the risk of data being used for purposes for which it is not suitable/permitted. • Having the data in one “place” means that availability depends on that place being up and on being connected to the inquiring party. Having data spread (as in a federated model) requires that a lot of places be up at the same time to satisfy some inquiries. • What happens when an HIE/storage facility goes out of business? • Likely key impacts on providers: • Need to focus business process on dependence of CLR availability • Need to determine medical/legal acceptability of data. D

40. Changes in amount and effects of erroneous data being shared. • The issue: Well functioning HIEs spread data quickly – whether it is true or not. Errors come from two main sources: • - Accident • usually human error; • right data – wrong patient mismatch is a typical error (Factoid: About .1% to 1% of patient record selection operations that precede data entry select the wrong patient) • Small environments (typical medical practice) with a lot of context and personal knowledge of patients help to keep this problem down. • -Fraud, Medical ID Theft • To obtain services without paying • To hide conditions • To obtain money for services not rendered • HINs will likely exacerbate the level of erroneous data – due to the relative “distance” (in time, space, context) of the provider from the user of the data. • Likely key impacts on providers • Need to consider which data will be taken to be actionable and which requires corroboration. • Need to consider how to inform the community when previously shared data is found to be incorrect. D

41. Changing (HITECH and beyond) environment of laws, standards, and regulations • The issue: • . There is a large and growing set of public policies (i.e. laws and regulations) related to health information security and privacy. Notably, enforcement of privacy and security measures was strengthened in HITECH. • Generally they are meant: • to protect the person who is the subject of the information from misuse of their information by others (third party disclosure laws), • to help make amends if the information is misused, and • to assure that the person has reasonable access to the data. • There are also growing set of laws, regulations, standards, and other incentives that incite providers to engage in more routine electronic information sharing. • Likely key impacts on providers: • They will more frequently have to actively manage these risks and anticipate and respond to public policy changes. • Providers may choose to “bet” that more consumer protections/rights will emerge. D

42. Risks of failing to engage in routine information exchange • The issue: • “Let’s wait until the dust settles” is a less attractive option than it has been historically. Waiting risks loss of incentive payments, penalty impositions, various forms of non-compliance actions or business disadvantages. • Likely key impacts on providers: • Providers will be less able to respond to privacy and security issues in data sharing by not sharing the data because of general concerns about risk. • Waiting to pursue adopting the various privacy and security elements in ARRA/HITECH has significant risks. D

43. Approaches to Managing Risks in HIE

44. Managing Risks of HIE Participation • Fair Allocation of Risk under Data Access Agreements • Cyber Insurance • Different policy types • Privacy liability coverage may cover damages and claims related to privacy breaches, breaches of specific privacy laws and regulations, such as HIPAA. • Security liability coverage may cover damages and claims arising out of computer attacks caused by failures of security including theft of client information, identify theft, negligent transmission of computer viruses and denial of service liability.

45. Managing Risks of HIE Participation • Relatively new type of insurance with potentially high premiums; application process for policies may be long and detailed • Obtaining a policy when participating in HIE: • May be contractual requirement under HIE participation agreement • May be a good business decision – dependent on type of system and risks of misuse or unauthorized access • Potential Coverage Under Existing Policies: • Standalone cyber-insurance policy may not be necessary. • Cyber-liability endorsement to a CGL or E&O policy may work

46. Adjust existing security measures • In anticipation of this new environment: • Review and update your HIPAA-required risk analysis. • Likely key typical provider changes and tasks: • Review and update staff training on security, sanction policy • Review and update your contingency plan • Consider the reliability/capacity of your broadband connection. • Assure unique accounts, robust passwords and no account sharing • Note that affordable and useful insurance is likely to require that you have a robust security program. These requirements may affect your security program. • Setup to capture, retain, and review access logs; start periodic reviews. D

47. Shifting/reducing risks • In anticipation of this new environment: • Consider how risk (to PHI confidentiality, availability, and integrity) are distributed among you, your peers, BAs, patients in a routine e-sharing environment. BAs are now covered directly by ARRA; explore how this shifts risks. • Likely key typical provider changes and tasks: • Consider HIE governance elements that affect risk distribution. How will bad actors be managed? What would happen if you were a bad actor? • Educate patients about their role in security – and where your role ends. • Consider cyber-insurance for some costs associated with new risks (e.g. breach notice costs). Recognize that affordable insurance will likely come with obligations to run a secure environment. • Consult your attorney about the shift in your general business risk and malpractice risks. D

48. Collaborating with peers • In anticipation of this new environment: • Determine who your key partners will be and how to work with them in new or existing forums. Make/adjust forums if needed. • Likely key typical provider changes and tasks: • Formulate projects in these forums that focus on • Issues that require group consensus (e.g. HIE governance issues) • Issues that are solved more easily via group-generated information/support (e.g. generation of check lists. Model RFPs, training on security/privacy). • Consider how to minimize the time delay in action normally associated with reaching consensus with peers on an issue. • NC has many useful peer-based forums: NCHICA, CareShare, NCPHIT Committee, NCALHD, HWTF’s HIT Collaborative, others. D

49. Working with the public • In anticipation of this new environment: • Determine when to approach your patients on this change and via what means. • Likely key typical provider changes and tasks: • Aiding patient’s in understanding your data sharing policies. • Helping patients understand how you share data with them electronically and the best form of partnership to make that sharing productive. • Prepare how you will interact with patients about: accounting of disclosure requests, self-pay restriction requests, providing e-copies of various PHI collections, notice of breach. D

50. Online Resources • Key HHS web site: http://healthit.hhs.gov - see, especially, links labeled “Meaningful Use” - for a list of the meaningful use objectives recommendations. “Privacy and Security” - for key documents related to HITECH and HIPAA P&S elements. • NCHICA: • http:www.nchica.org - links to tools and collaboration opportunities. • HIPAA FAQs: • http://www.hhs.gov/ocr/privacy/hipaa/faq/index.html - question and answer format