The principles of privacy and security in relation to an individual's medical record were identified in the Health Insurance Portability and Accountability Act of 1996 and subsequently reinforced in the passage of various regulations and in the 2009 Health Information Technology for Economic and Clinical Health Act. Compliance with the required components of HIPAA and HITECH is mandatory, a prerequisite for payment of meaningful use incentive payments created by the HITECH Act, and are generally attested to within the provider agreement between CMS and a covered entity.
More specifically, The HITECH Act's Breach Notification Rule requires each contracting party to conduct a risk assessment and provide assurances that they are compliant with the expanded HIPAA Privacy and Security Rules. In 2010, the Office for Civil Rights, building upon on the standards set forth by the National Institute of Standards and Technology, released guidance on HIPAA's risk analysis requirements.
An organization may be adversely impacted if the precautions identified in the risk assessment are not taken. While there is no single method for performing a risk assessment, non-performance places Security Rule enterprises at risk of non-compliance. This article will address: (1) the requirements for meeting these standards; and (2) why SAS 70 Type II compliance does not equate to complete HIPAA compliance.
Risk assessment components
Providing annual guidance on HIPAA Security Rule provisions is the responsibility of the OCR. Risks and vulnerabilities are required to be evaluated and reasonable and appropriate security measures implemented by an organization that is subject to the Security Rule. A risk analysis is required. The Security Rule expressly states, "[c]onduct 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 [organization]."
OCR suggested utilizing the NIST Special Publication (SP) 800-66 to assist organizations with identifying issues associated with Security Rule implementation. Some fundamental questions include:
The Security Rule further indicates the role of a risk analysis in achieving compliance with other standards and specification procedures. In particular, there are several implementation specifications that are designated as "addressable" rather than "required." It is important to note that an addressable implementation is not optional; "rather, if an organization determines that the implementation specification is not reasonable and appropriate, the organization must document why it is not reasonable and appropriate and adopt an equivalent measure if it is reasonable and appropriate to do so." Therefore, it is important for entities falling under the Security Rule umbrella to recognize this requirement or risk being held accountable for a violation.
The risk analysis outcome is vital for addressing what implementation specifications or equivalent measures are reasonable and appropriate. This information can be used to: design appropriate personnel screening processes; identify appropriate data and storage methods; evaluate the use of encryption, but recognize that if encryption is not used, per the HITECH Act, breach notification is required; authenticate data and protect integrity; and plan the appropriate manner for the transmission of PHI.
While numerous methods exist for conducting risk analyses, OCR identified fundamental elements that must be incorporated in accordance with the Security Rule. These elements include: the scope, which includes both potential risks and vulnerabilities of PHI storage and transmission; data collection; identify, anticipate and document threats to PHI; assess current security measures; determine potential impact of threat occurrence; determine level of risk; finalize documentation; and conduct periodic review assessments. By conducting a comprehensive risk analysis, enterprises can reduce the risk of adverse findings in a CMS audit and reduce the likelihood of penalties being applied.
Unlike various securities laws, the standards set forth by HHS do not expressly indicate that an SAS 70 Type II audit is required, nor does it provide that this audit assures compliance with all the required elements of HIPAA and the HITECH Act. Furthermore, as the chart demonstrates, there is not a "one-for-on"” match between the HHS Standards and SAS 70 Audit Control Objectives. Editor's note: SAS 70 and HIPAA Security Standards are available at www.sas70.us.com/industries/hipaa-and-sas70.php.
In the area of information technology, an SAS 70 Type II audit needs to clearly address the scope of the audit and the entity requesting the audit needs to communicate to the auditor all of the HIPAA and HITECH Act standards being evaluated. Therefore, if an entity promotes or stipulates in its contracts that it conducted a HIPAA/HITECH Act SAS 70 Type II audit, but did not address all of the Privacy, Security and Breach Notification Rule requirements, including evaluating business associate agreement compliance, this could amount to a material misrepresentation and detrimental reliance. Furthermore, if either the covered entity, business associate or subcontractor is non-compliant, the liability extends to the other entities, and may lead to preclusion from the Medicare program depending on the violation.
While the HITECH Act "makes BAs directly liable for civil money penalties for uses and disclosures of PHI that violate the Privacy Rule, BAs remain contractually liable to Covered Entities pursuant to their BAAs."[2]And, "[t]o the extent the BA is to carry out a Covered Entity's obligation under this subpart, the BA [and Subcontractor] must comply with the requirements of the Privacy Rule that apply to the Covered Entity in the performance of the obligation." Hence, all enterprises connected by BAAs need to appreciate that liability flows both downstream and upstream.
Rachel V. Rose, JD, MBA, Rachel V. Rose - Attorney at Law- PLLC, is a licensed attorney in Houston, Texas. Ms. Rose is published on various facets of healthcare, which include physician reimbursement, ICD-10, access to care issues, Anti-Kickback and Stark law, U.S. Supreme Court cases impacting the medical device industry, international comparative healthcare laws and HIPAA/the HITECH Act. She is vice-chair of the publication committee for the Health Law Section of the American Bar Association and vice-chair of the Enterprise Risk Management Task Force for the American Health Lawyers Association. She may be reached at_rvrose@rvrose.com
Footnotes:
[1] Lux Sci®, HIPPA HITECH 2010: Email Hosting at LuxSci, available at www.luxsci.com (Lux Scientiae, Inc. is a company specializing in secure technical safeguards for electronic media as it relates to the healthcare industry and HIPAA/HITECH Act requirements).
[2] Stacy A. Tovino and Cynthia Y. Reisz, Protecting PHI: Legal Duties of Health Care Lawyers Post-HITECH, p. 17 (Feb. 9-11, 2011), American Health Lawyers Association, Physicians and Physician Organizations and Hospitals and Health Systems Law Institutes White Paper (detailing the nuances of the HITECH Act and the impact on covered entities, business associates and subcontractors, with an emphasis on attorneys).
More specifically, The HITECH Act's Breach Notification Rule requires each contracting party to conduct a risk assessment and provide assurances that they are compliant with the expanded HIPAA Privacy and Security Rules. In 2010, the Office for Civil Rights, building upon on the standards set forth by the National Institute of Standards and Technology, released guidance on HIPAA's risk analysis requirements.
An organization may be adversely impacted if the precautions identified in the risk assessment are not taken. While there is no single method for performing a risk assessment, non-performance places Security Rule enterprises at risk of non-compliance. This article will address: (1) the requirements for meeting these standards; and (2) why SAS 70 Type II compliance does not equate to complete HIPAA compliance.
Risk assessment components
Providing annual guidance on HIPAA Security Rule provisions is the responsibility of the OCR. Risks and vulnerabilities are required to be evaluated and reasonable and appropriate security measures implemented by an organization that is subject to the Security Rule. A risk analysis is required. The Security Rule expressly states, "[c]onduct 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 [organization]."
OCR suggested utilizing the NIST Special Publication (SP) 800-66 to assist organizations with identifying issues associated with Security Rule implementation. Some fundamental questions include:
- Have you identified the ePHI within your organization? This includes ePHI that you create, receive, maintain or transmit.
- What are the external sources of ePHI? For example, do vendors or consultants create, receive, maintain or transmit ePHI?
- What are the human, natural and environmental threats to information systems that contain ePHI?
The Security Rule further indicates the role of a risk analysis in achieving compliance with other standards and specification procedures. In particular, there are several implementation specifications that are designated as "addressable" rather than "required." It is important to note that an addressable implementation is not optional; "rather, if an organization determines that the implementation specification is not reasonable and appropriate, the organization must document why it is not reasonable and appropriate and adopt an equivalent measure if it is reasonable and appropriate to do so." Therefore, it is important for entities falling under the Security Rule umbrella to recognize this requirement or risk being held accountable for a violation.
The risk analysis outcome is vital for addressing what implementation specifications or equivalent measures are reasonable and appropriate. This information can be used to: design appropriate personnel screening processes; identify appropriate data and storage methods; evaluate the use of encryption, but recognize that if encryption is not used, per the HITECH Act, breach notification is required; authenticate data and protect integrity; and plan the appropriate manner for the transmission of PHI.
While numerous methods exist for conducting risk analyses, OCR identified fundamental elements that must be incorporated in accordance with the Security Rule. These elements include: the scope, which includes both potential risks and vulnerabilities of PHI storage and transmission; data collection; identify, anticipate and document threats to PHI; assess current security measures; determine potential impact of threat occurrence; determine level of risk; finalize documentation; and conduct periodic review assessments. By conducting a comprehensive risk analysis, enterprises can reduce the risk of adverse findings in a CMS audit and reduce the likelihood of penalties being applied.
Statement on Auditing Standards No. 70
Developed by the American Institute of Certified Accountants, The Statement on Auditing Standards No. 70 serves as serves as a widely recognized auditing standard for control activities and related processes over information technology. The SAS 70 Type II Standard, periodically tests the effectiveness of internal controls. Laws such as the Investment Advisors Act of 1940 and Sarbanes-Oxley expressly prescribe its use.Unlike various securities laws, the standards set forth by HHS do not expressly indicate that an SAS 70 Type II audit is required, nor does it provide that this audit assures compliance with all the required elements of HIPAA and the HITECH Act. Furthermore, as the chart demonstrates, there is not a "one-for-on"” match between the HHS Standards and SAS 70 Audit Control Objectives. Editor's note: SAS 70 and HIPAA Security Standards are available at www.sas70.us.com/industries/hipaa-and-sas70.php.
| HHS Standards |
SAS 70 Audit Control Objectives |
| Security Management Process |
Five Elements of Internal Control |
| Information Access Management | Logical Security |
| Transmission Security | Network Security |
In the area of information technology, an SAS 70 Type II audit needs to clearly address the scope of the audit and the entity requesting the audit needs to communicate to the auditor all of the HIPAA and HITECH Act standards being evaluated. Therefore, if an entity promotes or stipulates in its contracts that it conducted a HIPAA/HITECH Act SAS 70 Type II audit, but did not address all of the Privacy, Security and Breach Notification Rule requirements, including evaluating business associate agreement compliance, this could amount to a material misrepresentation and detrimental reliance. Furthermore, if either the covered entity, business associate or subcontractor is non-compliant, the liability extends to the other entities, and may lead to preclusion from the Medicare program depending on the violation.
What it means for your organization
In order to adhere to the OCR guidance on risk assessments, enterprises should consider: breaking down the technical issues, delineating implementation requirements based upon regulatory language, identifying if the action is "required" or "addressable" under HIPAA, and listing compliance solutions for both non-electronic and electronic PHI.[1] It is important to re-emphasize that addressable does not mean optional. Information safeguards and compliance by enterprises are the focus of the Privacy and Security Rules. "The regulations call for organizational and administrative requirements along with technical and physical safeguards." The regulations also detail organizational requirements, which address business associate contracts, and other items. While risks are inherent in every industry, the stringent requirements to protect an individual's health records under HIPAA and the HITECH Act make the stakes higher for those enterprises handling PHI.While the HITECH Act "makes BAs directly liable for civil money penalties for uses and disclosures of PHI that violate the Privacy Rule, BAs remain contractually liable to Covered Entities pursuant to their BAAs."[2]And, "[t]o the extent the BA is to carry out a Covered Entity's obligation under this subpart, the BA [and Subcontractor] must comply with the requirements of the Privacy Rule that apply to the Covered Entity in the performance of the obligation." Hence, all enterprises connected by BAAs need to appreciate that liability flows both downstream and upstream.
Rachel V. Rose, JD, MBA, Rachel V. Rose - Attorney at Law- PLLC, is a licensed attorney in Houston, Texas. Ms. Rose is published on various facets of healthcare, which include physician reimbursement, ICD-10, access to care issues, Anti-Kickback and Stark law, U.S. Supreme Court cases impacting the medical device industry, international comparative healthcare laws and HIPAA/the HITECH Act. She is vice-chair of the publication committee for the Health Law Section of the American Bar Association and vice-chair of the Enterprise Risk Management Task Force for the American Health Lawyers Association. She may be reached at_rvrose@rvrose.com
Footnotes:
[1] Lux Sci®, HIPPA HITECH 2010: Email Hosting at LuxSci, available at www.luxsci.com (Lux Scientiae, Inc. is a company specializing in secure technical safeguards for electronic media as it relates to the healthcare industry and HIPAA/HITECH Act requirements).
[2] Stacy A. Tovino and Cynthia Y. Reisz, Protecting PHI: Legal Duties of Health Care Lawyers Post-HITECH, p. 17 (Feb. 9-11, 2011), American Health Lawyers Association, Physicians and Physician Organizations and Hospitals and Health Systems Law Institutes White Paper (detailing the nuances of the HITECH Act and the impact on covered entities, business associates and subcontractors, with an emphasis on attorneys).