The Office for Civil Rights (“OCR”) of the Department of Health and Human Services (“HHS”) has announced that it will resume this fall a program of audits to assess compliance with the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”).1 This round of audits, which is required by the Health Information Technology for Economic and Clinical Health Act (“HITECH”),2 will include both HIPAA covered entities (“CEs”) and, for the first time, business associates (“BAs”).3
OCR officials have stated that the 2014 and 2015 HIPAA audits will target provisions that were trouble areas in the pilot audit program, including risk analysis and risk management.4 An evaluation of the results of the pilot audit program showed that more than two-thirds of audited entities lacked a complete and accurate risk analysis, and 12 percent of the total audit findings involved risk analysis.5
These audits are the latest indication that BAs are coming under increasing scrutiny, and they follow closely on the heels of the final HIPAA omnibus rule. This 2013 rule made BAs directly responsible for adherence to certain provisions of the HIPAA Security Rule, including the provisions that require analysis of the potential risks and vulnerabilities to electronic protected health information (“ePHI”)6 and implementation of security measures to reduce those risks.7 The omnibus rule also set a maximum penalty of $1.5 million per violation.8
The omnibus rule additionally extended the definition of a BA. HHS defines a BA as any person or entity that performs certain functions or activities on behalf of the CE involving the use or disclosure of protected health information (“PHI”).9 The omnibus rule expanded that definition to expressly include health information organizations and similar organizations that provide data transmission services with respect to PHI; personal health record vendors; organizations that undertake patient safety activities; and subcontractors that create, receive, maintain, or transmit PHI on behalf of the BA.10
These clarifications highlight the fact that BAs are not all created equal in terms of the level of risk they represent to ePHI. Organizations whose business models involve the use and manipulation of large volumes of ePHI represent highly significant risks to that sensitive and protected data. These organizations are commonly referred to as healthcare IT companies.11
The Rise of Health IT
HITECH was designed to promote the widespread adoption and interoperability of health information technology.12 By offering incentives to encourage meaningful use of electronic health records (“EHRs”), the Act spurred on the creation of an entire ecosystem of healthcare IT (“HIT”) companies.
These third-party technology companies facilitate everything from implementation of EHRs and web-based portals to patient diagnosis and treatment, all of which require the use or disclosure of ePHI. One natural but unfortunate outgrowth of this increased dependence on technology is the resultant exposure of that ePHI. In fact, HITs have played a significant role in large data breaches. Roughly 40 percent of all breached patient records reported to HHS have involved HIT companies.13
Because their business models are built on their ability to compile and manipulate large volumes of ePHI from multiple sources, HIT companies have much at stake when it comes to protecting the data with which they are entrusted. In addition to the potential breach or exposure of ePHI, other risks could include a failure in the functionality (i.e., integrity) of the service or substantial downtime (i.e., availability) of the service — all of which could comprise HIPAA violations.14 While the dollar costs of noncompliance are significant, the loss of credibility associated with a data breach or system malfunction can potentially cripple the BA and cause substantial harm to the CE in the form of breach notification, reputation damage and lost business. For HIT companies, assessing and managing these risks should be a critical priority.
Increased Focus on Risk Analysis and Risk Management
Regulators continue to shine a bright light on the need for risk analysis and risk management with regard to ePHI. In its recent announcement of a record $4.8 million HIPAA settlement with New York-Presbyterian Hospital (“NYP”)and Columbia University (“CU”), HHS specifically noted risk analysis and risk management as areas of deficiency. In its press release, the agency noted, “neither entity had conducted an accurate and thorough risk analysis that identified all systems that access NYP ePHI. As a result, neither entity had developed an adequate risk management plan that addressed the potential threats and hazards to the security of ePHI.”15
NYP and CU work together in a joint arrangement in which they operate a shared data network which links to NYP patient information systems containing ePHI. In this case, both organizations are covered entities. However, BAs and the providers that entrust their ePHI to them should take the regulators’ message to heart: “When entities participate in joint compliance arrangements, they share the burden of addressing the risks to protected health information.”16
What does this heightened level of scrutiny mean for BAs, particularly HIT companies? How do they know that they are complying with HIPAA risk analysis and risk management provisions? While the provisions themselves are succinct, achieving compliance with them requires a nuanced understanding of these concepts.
CMS Clarifies Risk Analysis and Risk Management
In its HIPAA Security Series papers, the Centers for Medicare & Medicaid Services (“CMS”) clarifies that the Security Rule “does not prescribe a specific risk analysis or risk management methodology.”17 However, CMS does provide the following common risk analysis steps, which are adapted from the approach outlined by the National Institute of Standards and Technology (“NIST”):18
- Identify the scope of the analysis
- Gather data
- Identify and document potential threats and vulnerabilities
- Assess current security measures
- Determine the likelihood of threat occurrence
- Determine the potential impact of threat occurrence
- Determine the level of risk
- Identify security measures and finalize documentation
Only after establishing this thorough understanding of the risks that are inherent to the BA’s services can the company develop and implement a risk management plan, including security measures that reduce the risks to reasonable and appropriate levels, CMS says.19 According to HIPAA, CEs and BAs must take into account a number of internal factors when determining the most appropriate security measures, ranging from the size of the entity to the “probability and criticality of potential risks to ePHI.”20
HIT companies are in the business of collecting large volumes of heterogeneous data sets and subsequently manipulating that data to provide value to the CEs and other BAs that they serve. As a result of the sophistication and complexity of these systems, the probability and criticality of potential risks is generally very high. For example, a data analytics company that runs complicated algorithms on health claims data to detect fraud has created an environment where information could be leaked or breached, or data integrity could be compromised. Without understanding those inherent risks at a meaningful level, the analytics company can’t be confident that it has put in place an appropriate risk management plan and security measures.
Protecting the Business Through Holistic Risk Management
HIT companies, such as the data analytics company described above, need peace of mind that their internal controls protect the information with which they are entrusted — for their own sake, as well as that of their CEs and of patients.
Such a holistic risk management process as the one outlined by CMS is essential to achieving such peace of mind. The process begins with a thorough understanding of the system that the HIT company uses to perform certain functions or activities on behalf of the CE and the risks that are inherent to that system. Consider an HIT company that analyzes ePHI and other healthcare data to improve quality of care and patient outcomes while reducing costs. This company’s customers expect 24x7 availability, assurance of the security and privacy of their patients’ ePHI and proper management of that data to ensure its quality. An assessment of the full scope of the risks that the organization poses to its customers enables the BA to identify the domains that are central to its efficacy: in this case, availability, data integrity, security and privacy. Within these domains, the HIT can build a criteria framework against which they can design and deploy mitigating controls, as well as measure and monitor the efficacy of those controls.
Incorrect Approaches to HIPAA Compliance
This step of identifying criteria relevant for risk mitigation is a critical one in the risk management process. When BAs skip this step they often jump to an incomplete solution that will most likely fail to address their risk management needs and those of their customers, as well as HIPAA compliance requirements. For example, many HIT companies (and the CEs that employ them) believe that by obtaining a Service Organization Control (“SOC”) 1 report, also known as SSAE 16, they have achieved HIPAA compliance. Prepared by a CPA in accordance with American Institute of CPAs’ [“AICPA”] Statements on Standards for Attestation Engagements (“SSAE”) 16, SOC 1 was designed to attest to internal controls over financial reporting (debits and credits).21 A basic Internet search uncovers numerous HIT companies that offer up SOC 1 reports as evidence that they have fulfilled their HIPAA responsibilities, even though AICPA standards explicitly restrict the report from being used to address operational and compliance risks (e.g., security, privacy, integrity and availability risks).22 Note that SSAE 16 may indeed be relevant if the HIT company provides services that could affect debits and credits (such as revenue cycle management or claims adjudication); however, the standard is not designed to address the risks that are at the heart of HIPAA compliance.
In other instances, companies believe that they have conducted a risk analysis by applying a prescribed set of security standards. HIT and other technology-based companies tend to apply the ISO 27002 information security standard. However, no pre-defined set of controls can fulfill HIPAA requirements, because controls are only effective if they are relevant and pragmatic in the organization’s unique environment. Given the wide variance in business models, processes, and IT systems deployed by HIT companies, the controls that are appropriate in one company would be inadequate to address the risks of another company.
Assurance Reporting Tailored to the Risk Environment
When BAs thoroughly evaluate their risks and clearly understand the criteria upon which they design mitigating controls in the context of that risk analysis, they can adopt appropriate reporting that provides the assurance they need, whether for purposes of demonstrating compliance with HIPAA or other regulatory standards.
The AICPA service organization control assurance reporting framework includes one option, SOC 2, that was designed specifically to provide a high level of transparency into controls around security, confidentiality, processing integrity, availability and privacy — in other words, the risk domains common to BAs.23 By providing a detailed level of transparency into the system, risk analysis process, design and effectiveness of controls, a SOC 2 report enables users of IT services, such as CEs, to effectively manage their risks while demonstrating compliance with HIPAA Privacy and Security Rules. The structure also is scalable, so the BA can incorporate additional criteria as necessary to address its unique business risk management and reporting needs.
Organizations that are responsible for managing and manipulating ePHI on behalf of CEs need a high level of assurance that they are protecting the confidentiality, integrity and availability of that sensitive data, not only to demonstrate compliance with the HIPAA Risk Analysis and Risk Management provisions, but also to protect their own business and that of their CEs. To gain the peace of mind that they are protecting ePHI, and thus complying with HIPAA, all BAs need to adopt a thorough process that provides them with a comprehensive view of the organization’s IT-related risks.
Dan Schroeder, CPA, CIPP/IT, CISA, PCI-QSA, CISM, MBA is partner-in-charge of HA&W’s Information Assurance Services practice. HA&W services Dan oversees include Information Risk Assessments, SSAE 16 and SOC 2 reporting, and compliance for ISO 27001, PCI, HIPAA/HITECH, and EU Safe Harbor. Dan is the immediate ex-chairperson of the AICPA Information Management Technology Assurance Committee and currently serves as the chairperson of the AICPA Privacy Task Force. He can be reached at email@example.com.
Healthcare Info Security, “HIPAA Audits: Round 2 Details Revealed,” retrieved on April 28, 2014, from http://www.healthcareinfosecurity.com/hipaa-audits-round-2-details-revealed-a-6747/op-1.
U.S. Department of Health & Human Services, “Health Information Privacy: HIPAA Privacy, Security, and Breach Notification Audit Program.” Available at http://www.hhs.gov/ocr/privacy/hipaa/enforcement/audit/.
Ibid. “The focus of BA audits will be on HIPAA security risk analysis and risk management, as well as breach reporting to covered entities, according to the presentation.”
Office for Civil Rights, “HIPAA Privacy, Security and Breach Notification Audits Program Overview & Initial Analysis,” presented May 21-22, 2013 at 2013 NIST/OCR Security Rule Conference. Available at http://csrc.nist.gov/news_events/hipaa-2013/presentations/day1/rinker_day1_215_hipaa_privacy_security_breach_audits.pdf.
HIPAA §164.308(a)(1)(ii)(A): Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.
HIPAA §164.308(a)(1)(ii)(B): Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a):
HIPAA §160.404 Amount of civil monetary penalty, Available at http://www.law.cornell.edu/cfr/text/45/160.404.
U.S. Department of Health & Human Services, “Health Information Privacy: Business Associates.” Available at http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/businessassociates.html
While there is no formal, widely accepted definition of a healthcare IT company, several organizations have offered their perspectives. HHS says that health information technology involves the exchange of health information in an electronic environment. The Office of the National Coordinator for Health Information Technology specifies that health IT “makes it possible for health care providers to better manage patient care through secure use and sharing of health information” and “includes the use of electronic health records (EHRs) instead of paper medical records to maintain people’s health information.” Available at http://www.healthit.gov and http://www.hhs.gov/ocr/privacy/hipaa/understanding/special/healthit/.
Based on data extracted from http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html.
HIPAA § 164.306 Security standards: General rules.
(a) General requirements. Covered entities and business associates must do the following:
|17||CMS, “HIPAA Security Series Vol. 2 Paper 6: Basics of Risk Analysis and Risk Management.” Revised 3/2007.|
|18||CMS, “HIPAA Security Series Vol. 2 Paper 6: Basics of Risk Analysis and Risk Management.” Revised 3/2007.|
HIPAA §164.306(b)(2): In deciding which security measures to use, a covered entity or business associate must take into account the following factors:
AICPA, “Service Organization Controls (“SOC”) Reports for Service Organizations.” Available at http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/ServiceOrganization%27sManagement.aspx.
AICPA AT § 801.02: The focus of this section is on controls at service organizations likely to be relevant to user entities' internal control over financial reporting…
AICPA, “Service Organization Controls (“SOC”) Reports for Service Organizations.”