B Institute of Medicine Report on HIT and Patient Safety

Transcription

1 Ongoing Challenges in HIPAA Compliance Are We Having Fun Yet? Marilyn Lamar, Esq. Liss & Lamar, P.C. AHLA Physicians and Hospitals Law Institute New Orleans, Louisiana February 5-7, 2014 On September 23, 2013, the Omnibus Rule 1 became effective, significantly expanding the privacy and security obligations of Business Associates and Covered Entities under the Health Insurance Portability and Accountability Act of 1996 ( HIPAA ). The Omnibus Rule consists of a set of amendments to the privacy, security, enforcement and breach notification regulations that implement HIPAA, many of which were required by the Health Information Technology for Economic and Clinical Health ( HITECH ) Act 2 or the Genetic Information Nondiscrimination Act ( GINA ). 3 Counsel for Covered Entities and Business Associates are now dealing with significant challenges in assisting clients with Omnibus Rule compliance including those arising from acts and omissions of a Covered Entity s Business Associates that may be deemed agents despite being described as contractors in an agreement. Some of this increased risk may be mitigated by applying rigorous selection criteria, conducting a thorough due diligence review and negotiating contract language that assigns an appropriate level of responsibility to the Business Associate. Section II of this outline discusses the increased risk presented by agents under the Omnibus Rule and Section IV provides contract language and considerations for indemnification to assist in mitigation. The safety of health information technology (IT) has also drawn a great deal of attention from federal regulators, especially with respect to the safety of electronic health records ( EHRs ). In addition to concerns about patient safety and how to comply with evolving rules, these new studies and tools may change the standard of care and become the focus of plaintiff lawsuits. The government initiatives are discussed in Section I below. Another overall issue in the health IT landscape is the goal of having complete patient information despite the obstacle presented by the significant limitations on disclosures by federally assisted substance abuse treatment centers under 42 C.F.R. Part 2. Section III below describes these limitations, some possible exceptions and an ongoing pilot program to make electronic forms of such information more readily available. Other issues arising from the Omnibus Rule are addressed in the outline prepared by Patricia A. Markus for the 2014 AHLA Hospitals and Health Systems Law Institute. Capitalized terms used in this outline without definition have the respective meanings assigned to them in the rules promulgated under HIPAA and HITECH. This outline assumes a basic understanding of the 1 Modifications to the HIPAA Privacy, Security, Enforcement and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules; Final Rule, 78 Fed. Reg (Jan. 25, 2013) (amending 45 C.F.R. Parts 160 and 164). 2 Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (ARRA), Pub. L. No , 123 Stat. 226 (Feb. 17, 2009), codified at 42 U.S.C. 300jj et seq.; et seq.; 3 Genetic Information Nondiscrimination Act of 2008 (GINA), Pub. L. No , 122 Stat. 881 (May 21, 2008). 1

2 Omnibus Rule, the Privacy Rule, 4 the Security Rule, 5 and the Enforcement Rule 6 promulgated by HHS under HIPAA and HITECH. I. Federal Government Initiatives Focusing on Health IT Safety A. Overview and Background Health IT patient safety issues have drawn significant attention from the Office of the National Coordinator for Health Information Technology ( ONC ) and are likely to have considerable impact on health care providers and IT developers alike. Recent examples of ONC s efforts in this area are the Health IT Patient Safety Action & Surveillance Plan 7 issued on July 2, 2013 and the SAFER Guides 8 issued on January 15, 2014, each of which are discussed in Sections C and D below. Health IT was also addressed as part of changes to the medical device provisions of the Food and Drug Administration Safety and Innovation Act of 2012, Pub. L. No ( FDASIA ). Specifically, Section 618 of the FDSIA requires the Secretary of HHS to post a report by January 2014 with a proposed strategy and recommendations on a risk-based regulatory framework pertaining to health IT, including mobile applications, that promotes innovation, protects patient safety, and avoids regulatory duplication. The report had not been issued when this outline was prepared, but the draft recommendations of a committee formed to make recommendations is discussed below in Section E. These efforts were preceded by the 2011 Institute of Medicine report on health IT and patient safety (the IOM Report ) discussed in Section B below. The focus on safety of electronic health records was also seen in portions of the Stage 2 meaningful use requirements adopted for the Medicare and Medicaid Electronic Health Record ( EHR ) Incentive Program. 9 Although the increased focus on safety may in fact improve patient care, counsel for providers and developers should also note the possibility that the increasing amount of safety data, studies and tools could affect the standard of care that may apply in negligence cases. For example, members of the plaintiff malpractice bar may use this information to argue that health care providers should be liable for health IT-related patient harm if they did not select a safe system or did not report, monitor or take appropriate action regarding health IT-related patient safety events. This is an evolving area which should be evaluated on an ongoing basis in light of industry developments and new case law. B Institute of Medicine Report on HIT and Patient Safety While EHRs and other HIT are often touted as improving patient safety, some studies have indicated that they can present complicated risks if not carefully designed, implemented and monitored in use. These risks appear to arise from numerous factors including (i) the wide range of health information that may be recorded by numerous personnel; (ii) the lack of uniform standards for how various types of health information are recorded and made accessible; (iii) constantly changing technology and standards of 4 Standards for Privacy of Individually Identifiable Health Information; Final Rule, 65 Fed. Reg (Dec. 28, 2000) (as amended) (amending 45 C.F.R., Parts 160 and 164). 5 Standards for Privacy of Individually Identifiable Health Information; Final Rule, 65 Fed. Reg (Dec. 28, 2000) (as amended) (amending 45 C.F.R., Parts 160 and 164). 6 HIPAA Administrative Simplification: Enforcement; Interim Final Rule, 74 Fed. Reg (Oct. 30, 2009). 7 (last visited Jan. 26, 2014). 8 News Release, U.S. Department of Health & Human Services, HHS makes progress on Health IT Safety Plan with release of SAFER Guides (Jan. 15, 2014), available at: (last visited Jan. 16, 2014) Fed. Reg

3 practice; and (v) complex human factors that affect clinical interaction with HIT, including the impact on care processes and workflows. For example, a poorly designed EHR that requires a user to remember specific patient information while navigating multiple screens to enter an order may increase the user s cognitive load to a degree that makes errors more likely, especially if the user is subject to interruptions while trying to enter the order. Drop down menus of medications listed alphabetically rather than by type (antibiotics, anti-depressants, etc.) has also been noted as a design factor that may lead to prescribing errors (sometimes referred to as juxtaposition errors ). Clinical alerts generated by EHRs are overridden surprisingly often, especially if the clinicians feel that they do not provide useful information. 10 The Joint Commission ( TJC ) was one of the first organizations to identify these risks and how they can be addressed in its 2008 Sentinel Event Alert titled Safely implementing health information and converging technologies ( SEA 42 ). SEA 42 suggested 13 actions ranging from an early examination of workflows and involving clinicians in planning to monitoring systems after implementation to track errors and close calls. 12 To date reporting of sentinel events is voluntary and statistics on SEA 42 reports are not published but there are pressures for more reporting and transparency as evidenced in the Plan described below. Perhaps recognizing that the increased use of EHRs encouraged by billions of dollars in meaningful use incentives could lead to increased risk, the Department of Health and Human Services ( HHS ) funded an Institute of Medicine report 13 examining how the use of HIT affects the safety of patient care (the IOM Report ). Although significant improvements were noted from use of CPOE (computerized provider order entry) and bar coding, the IOM Report also reviewed studies that reported some instances of HITassociated harm. 14 Although the full report should be reviewed for additional detail and context, some of the recommendations of the IOM Report 15 are summarized below: 1. HHS should publish an action and surveillance plan within 12 months with a schedule for working with the private sector to assess the impact of HIT on patient safety and minimize the risk of implementation and use. The plan should include actions by several government entities and accreditation organizations to (a) develop measures for safety; (b) work with vendors on promoting safety in development; (c) work with vendors and health care providers on post-implementation safety testing of EHRs for high prevalence, high impact EHR-related patient safety risks; and (d) adopt criteria for EHR safety for use by accrediting organizations. 2. HHS should ensure insofar as possible that vendors support and do not prohibit the free exchange of information about HIT safety, including details such as screenshots. 10 Several studies of unintended adverse consequences of HIT are summarized in materials provided for the 2007 and 2008 AHLA Annual meetings. See M. Lamar, Planning to Minimize the Pitfalls of Electronic Systems and Metadata (2007) and Lessons Learned from Electronic Health Record and Health Information Exchange Projects (2008). Additional studies are cited in the 2011 IOM Report and the Draft Report issued in connection with the FDASIA, both of which are cited below converging_technologies, accessed Jan. 16, Id. 13 IOM (Institute of Medicine) Health IT and Patient Safety: Building Safer Systems for Better Care. 14 IOM report at S-2 15 IOM Report at S-4 through S-11. 3

4 3. ONC should work with the private and public sectors to make comparative user experiences across vendors publicly available. 4. HHS should specify the quality and risk management process requirements that HIT vendors must adopt, with a particular focus on human factors, safety culture and usability. 5. HHS should establish a mechanism for vendors and users to report HIT-related deaths, serious injuries or unsafe conditions. Reporting would be (a) mandatory for vendors and (b) voluntary, confidential and non-punitive for users. Efforts should be made to encourage reporting by removing contractual, legal, logistical and other barriers to reporting. Reports then would be analyzed and the circumstances would be investigated. 6. HHS should monitor and publicly report on the safety of HIT. If it determines that sufficient progress is not being made, it should direct the FDA to regulate EHRs, HIEs and personal health records (although this would require a determination that these are medical devices in the scope of the FDA s regulatory authority). The FDA should begin to develop a regulatory framework. With respect to disclosures of HIT-related adverse events, software contracts commonly include confidentiality provisions that are intended to protect the vendor s intellectual property. The broad scope of these non-disclosure clauses apparently led the authors of the IOM Report to conclude that these provisions are a significant barrier to the full reporting of errors that the authors believe is necessary to improve patient safety. 16 C ONC Health IT Patient Safety Action and Surveillance Plan. As recommended by the 2011 IOM Report, ONC issued its Health IT Patient Safety Action and Surveillance Plan 17 (the Plan ) in July 2013 following a notice and comment period. 18 The Plan is a joint effort between ONC and the Agency for Healthcare Research and Quality ( AHRQ ) with two fundamental objectives: 1. Promote the use of health IT to make care safer; and 2. Continuously improve the safety of health IT itself. 19 To coordinate and implement the Plan, ONC established the Health IT Safety Program led by ONC s chief medical officer. 20 The Plan relies on substantial participation by the private sector to be successful. 21 ONC expects that through the Plan: 16 IOM Report at News Release, U.S. Department of Health & Human Services, Final HHS Health IT Safety Plan issued (July 2, 2013), available at hhs.gov/news/press/2013pres/07/ a.html (last visited Jan. 16, 2014). 19 U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, ONC Fact Sheet: Health Information Technology Patient Safety Action and Surveillance Plan (July 2, 2013) available at: (last accessed Jan. 16, 2014). 20 Pfister, Helen and Ingargiola, Susan, ONC Unveils Final Health IT Safety Plan, ihealthbeat, July 29, 2013 at 3 available at: ihealthbeat.org/insight/2013/onc-unveils-final-health-it-patient-safety-plan (last accessed Jan. 16, 2014). 21 News Release, U.S. Department of Health & Human Services, Final HHS Health IT Safety Plan issued (July 2, 2013), available at hhs.gov/news/press/2013pres/07/ a.html (last visited Jan. 16, 2014). 4

5 ONC will make it easier for clinicians to report health-it related incidents and hazards through use of certified electronic health record technology ( CEHRTs ). AHRQ will encourage reporting to patient safety organizations and will update its standardized reporting forms to enable ambulatory reporting of health IT events. CMS will encourage the use of standardized reporting forms in hospital incident reporting systems, and train surveyors to identify safe and unsafe practices associated with heath IT. ONC and CMS will consider adopting safety-related objectives, measures, and capabilities for CEHRTs through the Medicare and Medicaid EHR Incentive Program and ONC s standards and certification criteria. 22 To further these goals, the ONC contracted with The Joint Commission ( TJC ) to better detect and proactively address potential health-it related safety issues [including] as a contributing cause of adverse events. 23 TJC is to enhance the use of its Sentinel Events database and reporting program to identify, investigate, and ultimately prevent sentinel events 24 so the results can inform and potentially drive the direction of the Program. Under the contract, TJC will conduct at least 10 investigations (5 hospitals, 5 ambulatory sites) of HIT events and provide a written summary of the events. TJC will also produce a final report that will identify the resources needed to effectively conduct investigations and what factors may impact the ability of an external organization to conduct health-it related investigations. 25 D. SAFER Guides Implementation of the Health IT Safety Plan has started to take shape in the nine Safety Assurance Factors for EHR Resilience ( SAFER ) guides released on January 15, The goal of the SAFER guides is to offer health care providers an interactive self-assessment tool to evaluate where their EHR is vulnerable to patient safety risks and then determine how to optimize safety. 27 Each SAFER guide may be used interactively online or may be downloaded as a fillable PDF. 28 The nine SAFER guides consist of the following and are divided into three broad categories: Foundational Guides - High Priority Practices - Organizational Responsibilities 22 Id. 23 Id. 24 U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Investigation of Health IT-related Deaths, Serious Injuries, or Unsafe Conditions (ONC Contract #HHSP C) (July 2, 2013) available at: (last visited Jan. 16, 2014). 25 Id. 26 News Release, U.S. Department of Health & Human Services, HHS makes progress on Health IT Safety Plan with release of SAFER Guides (Jan. 15, 2014), available at: (last visited Jan. 16, 2014). 27 Id. and Health IT Videos: How to Use the SAFER Guides available at: (last visited Jan. 16, 2014). 28 News Release, U.S. Department of Health & Human Services, HHS makes progress on Health IT Safety Plan with release of SAFER Guides (Jan. 15, 2014), available at: (last visited Jan. 16, 2014). 5

6 Infrastructure Guides - Contingency Planning - System Configuration - System Interfaces Clinical Process Guides - Patient Identification - Computerized Provider Order Entry (CPOE) with Decision Support - Test Results Reporting and Follow-up - Clinician Communication The SAFER guides rely on a variety of checklists, evaluative tools, and recommended practice objectives that ONC and other stakeholders believe combine the latest applied knowledge of health IT safety with practical tools that will help providers according to ONC chief medical officer, Jacob Reider, M.D. 29 Each SAFER guide includes references to the sources of its recommended practices which the authors believe represent current industry best practices. Although they are not based on HIPAA or the EHR Incentive Program, there are references throughout the SAFER guides to the relevant portions of those regulations. 30 ONC also posted a short introductory video to the SAFER guides to be used by the team or risk manager performing the review. 31 The video explains that while each SAFER guide s checklist may only be 1-2 pages long, each checklist topic has an associated worksheet to help the user evaluate the organization s level of implementation of the recommended practice. Each guide also lists other types of professionals to potentially consult for further information, along with examples of relevant sample situations. 32 The High Priority Practice Guide, 33 for example, recommends completing the self-assessment with a multidisciplinary team to enable an accurate snapshot and lead to consensus about the organization s future path to optimize EHR-related safety and quality. 34 It is too early to tell whether the SAFER guides will be widely used and prove to be successful. However, they will likely be a valuable tool for organizations to begin their own internal self-assessment and evaluation processes, as well as for outside consulting groups looking to assist organizations with their health IT safety concerns. 29 Id. 30 U.S. Department of Health and Human Services, Office of the National Coordinator for Health IT, HIPAA: High Priority Practices available at: (last accessed Jan. 16, 2014). 31 Health IT Videos: How to Use the SAFER Guides available at: (last visited Jan. 16, 2014). 32 Health IT Videos: How to Use the SAFER Guides available at: (last visited Jan. 16, 2014). 33 U.S. Department of Health and Human Services, Office of the National Coordinator for Health IT, SAFER Guide - Self Assessment - High Priority Practices available at: (last accessed Jan. 16, 2014). 34 Id. at 2. 6

7 As noted above, tools like the SAFER guide may be cited by plaintiffs lawyers trying to establish a higher standard of care. However, the General Instructions for the SAFER self-assessment guides state that they are for informational purposes only and are not intended to be an exhaustive or definitive source. 35 E. Recommendations from FDASIA Committee As noted above, Section 618 of the FDASIA requires the Secretary of HHS to issue a report by January 2014 regarding health IT acting through the Commissioner of the Food and Drug Administration ( FDA ), in consultation with ONC and the Federal Communication Commission ( FCC ). Although the final report had not been issued when this outline was prepared, some elements of the draft FDASIA Committee Report issued in September may be helpful in anticipating what will be covered by the report and generally evaluating issues in this area. The Draft Committee Report initially considered what types of health IT should be subject to a risk-based regulatory framework (e.g., decision support algorithms) or excluded (e.g., claims and eligibility software). It used eleven characteristics of IT (e.g., purpose, intended users, possible severity of injury and transparency) and provided examples of low, medium and high risk on each characteristic in several use cases ranging from a nutrition app to an insulin pump with a glucose monitor. This approach intentionally did not provide a numerical calculation of risk. The Draft Report also evaluated current regulation by the FDA, ONC and the FCC on various dimensions including the impact each was likely to have on innovation and whether ambiguities and overlap could be eliminated. The many recommendations in the Draft Report included the following: Health IT should not be subject to FDA pre-market requirements except for medical device accessories, high risk clinical decision support and high risk software use cases (including those where the intended use elevates risk). Vendors should list products with some risk (assuming there is a non-burdensome way to do so). Need a collaborative post-market approach to surveillance of HIT including reports from users and vendors as well as post implementation testing. Safety issues should be aggregated on a nationwide basis. No federal agency was suggested to take the lead but inter-agency cooperation was deemed essential. Existing standards should be adopted and new standards developed. An independent group should administer a public process for customer rating of HIT to enhance transparency using validated measurement results. In its summary of lessons learned, the Draft Report noted that certification should be used judiciously so creativity and innovation are not discouraged. It also noted that transparency in the marketplace was preferred to innovation that is often limited to compliance with government requirements. National goals such as the meaningful use standards were also encouraged. 35 U.S. Department of Health and Human Services, Office of the National Coordinator for Health IT, SAFER Guide - Self Assessment - High Priority Practices available at: (last accessed Jan. 16, 2014) (last accessed Jan. 26, 2014). 7

8 II. Liability for Business Associates and Subcontractors A. Liability in General. The HITECH Act and the Omnibus Rule extend direct liability for compliance with certain provisions of HIPAA to business associates, making them civilly and criminally liable for violations of the applicable provisions. In the Preamble, HHS clarified that a person becomes a business associate by definition, not by contract, as previously mentioned. Therefore, liability for compliance with the applicable provisions of HIPAA attaches immediately when a person meets the definition of a business associate. B. Agents. In general, and subject to certain affirmative defenses, HHS will impose a civil money penalty upon a covered entity or a business associate for violating the applicable provisions of HIPAA. Despite the fact that HITECH made business associates directly liable for breaches of many provisions of the HIPAA rules, the Omnibus Rule eliminated a provision in the Enforcement Rule that previously protected a covered entity from liability for the acts of an agent so long as: (a) the agent was a business associate of the covered entity, (b) the requirements of the business associate agreement were met, (c) the covered entity did not know of a pattern or practice of the business associate in violation of its business associate agreement, and (d) the covered entity did not fail to act to cure the breach or end the violation, or, if such steps were unsuccessful, terminate the agreement or report it to the Secretary, as applicable. Instead, the Omnibus Rule makes a covered entity or a business associate liable when an agent of the covered entity or business associate, as applicable, is responsible for the violation. This liability may attach even when the covered entity or business associate, as applicable, has a compliant business associate agreement in place. Principles of the federal common law of agency determine whether an entity will be liable for the acts of its business associate or subcontractor, as applicable. Although the federal common law of agency is beyond the scope of this outline, HHS has provided some guidance behind these revisions. First, it expects that the federal common law of agency will offer a uniform platform for the definitions of principal, agent, and scope of agency, which it believes important when enforcing a federal law. In addition, HHS points out that an analysis of whether a business associate or a subcontractor is an agent will be fact-specific, taking into account the terms of the agreement between the parties and the totality of the circumstances. The most important factor is whether the covered entity or business associate controls the conduct of its business associate or subcontractor as it performs services. For instance, a relationship between a covered entity and a business associate where the only ability to control the business associate is to amend the agreement or sue for breach is more likely not to be an agency relationship than a relationship that provides that the covered entity will provide instructions to the business associate as it performs the services. Some of the other factors that may be considered include: The time, place, and purpose of the conduct; Whether the conduct is commonly done by a business associate or subcontractor to accomplish the service performed; Whether or not the covered entity (or business associate) reasonably expected that a business associate (or subcontractor) would engage in the conduct in question; and The type of service and skill level required to perform the services. 8

9 The labels associated with the relationship (such as independent contractor) are not definitive, although we would expect that such language will be incorporated into many business associate agreements. In addition, we would expect that indemnification provisions will become more heavily negotiated as covered entities and business associates attempt to manage this potential liability. Finally, in a somewhat ironic twist, covered entities or business associates that attempt to define by contract the terms of conduct of the business associate or subcontractor, as applicable, in order to better protect the privacy and security of PHI may find themselves taking on more liability. It is possible such efforts could be viewed as attempts to control the conduct of the business associate or subcontractor, thereby creating an agency relationship. III. Compliance with Federal Substance Abuse Program Records Requirements Liability for Business Associates and Subcontractors A. Specific Patient Consent Required. One of the continuing obstacles to achieving complete medical records are the stringent consent requirements of 42 C.F.R. Part 2 that generally prohibits the disclosure 37 or use of patient health records 38 maintained in connection with any federally assisted drug or alcohol program except as permitted by the rule or pursuant to a prior written consent of the patient that is compliant with 42 C.F.R. Part The consent to disclosure under the Part 2 regulations must be in writing and include all of the following items: (i) (ii) the specific name or general designation of the program or person permitted to make the disclosure; the name or title of the individual or the name of the organization to which disclosure is to be made; (iii) the name of the patient; (iv) the purpose of the disclosure; (v) how much and what kind of information to be disclosed; (vi) the signature of the patient and, when required for a patient who is a minor, the signature of a person authorized to give consent under 2.14; or, when required for a patient who is incompetent or deceased, the signature of a person authorized to sign under 2.15 in lieu of the patient; (vii) the date on which the consent is signed; (viii) a statement that the consent is subject to revocation at any time except to the extent that the program or person which is to make the disclosure has already acted in reliance on it (acting 37 Disclosure means the communication of patient identifying information, the affirmative verification of another person s communication of patient identifying information, or the communication of any information from the records of a patient who has been identified. 42 C.F.R Records mean any information, whether recorded or not, relating to a patient received or acquired by a federally assisted alcohol or drug program; Patient identifying information means the name, address, social security number, fingerprints, photographs, or similar information by which the identity of a patient can be determined with reasonable accuracy and speed either directly or by reference to other publicly available information. 42 C.F.R C.F.R