Even though the full extent of the HIPAA and HITECH requirements will not be required for Business Associates until 2011, my experience with helping organizations reach compliance with appropriate security requirements suggests that compliance efforts should begin right away. Proposed changes to the rules can be viewed at regulations.gov (http://www.regulations.gov/search/Regs/home.html#documentDetail?R=HHS-OCR-2010-0016-0001).The deadline for submitting comments has passed on August 13th; however I would be surprised to find significant changes from those that have been proposed.
With Business Associates having to comply with the same requirements as Covered Entities, there are many important requirements with regard to handling ePHI. Companies should quickly become familiar with:
Performing periodic risk assessments that include ePHI – Organizations may decide to use guidance provided by HHS or use their own discretion.
Ability to respond to ePHI access inquiries – Just as covered entities, BAs need to be able to respond to requests regarding access to individual’s ePHI.
Incident investigation timeframe – In accordance with the HITECH requirements, responding to security incidents and issuing appropriate breach notifications must take place within a relatively short timeframe. While 60 days may not seem very short, having participated in a number of incident investigations, I can assure that this is not a lot of time.
Implementation of the above mentioned requirements may warrant creating new or modifying existing policies, implementing new security controls, and providing training for IT staff and other ePHI custodians. Failure to comply with policies and practices may cause the company to be viewed as negligent, triggering significantly higher fines and possible consequences for company leadership.
For those companies who have relatively new security and privacy programs, I strongly recommend referencing HITRUST Common Security Framework (CSF) for detailed implementation requirements for individual HIPAA and HITECH controls. While this may be seen as over-kill for small Business Associate organizations, the range of control implementation considerations will help organizations realize all possible consequences of these healthcare regulatory requirements. With implementation of some of the more technical controls requiring considerable cost and operational changes, organizations should take advantage of the time before the requirements have been mandated and companies fall into the scope of the HIPAA and HITECH enforcement efforts.
One of the common and consistent themes at HIMSS (Healthcare Information and Management Systems Society) this year was achieving “Meaningful Use” requirements so that healthcare providers can apply for EHR (Electronic Health Record) stimulus money. The “Meaningful Use” requirements focus on:
- Improving quality, safety, efficiency, and reduce health disparities
- Engaging patients and families
- Improving care coordination
- Improving population and public health
- Ensuring adequate privacy and security protections for personal health information
Naturally, my interest is within the last item in the list, and within this post I hope to bring more clarity to a small subset of what clearly is becoming the newest “hot-item” of the healthcare industry. Based on the “Meaningful Use” matrix created by the HIT (Health IT) Policy Committee, here are the security and privacy goals that need to be reached within the next year and a half:
2011 Objectives:
Compliance with HIPAA Privacy and Security Rules and state laws
Compliance with fair data sharing practices set forth in the Nationwide Privacy and Security Framework
2011 Measures:
Full compliance with HIPAA Privacy and Security Rules
An entity under investigation for a HIPAA privacy or security violation cannot achieve meaningful use until the entity is cleared by the investigating authority
Conduct or update a security risk assessment and implement security updates as necessary
What the above means is that healthcare companies need to conduct (or update an existing) security risk assessment, and implement the appropriate controls to meet HIPAA requirements. However, since conducting risk assessments is technically a part of HIPAA / HITECH compliance, the requirements could be further simplified to say that by the end of 2011, companies need to be HIPAA compliant.
One thing that companies really need to address is making sure that HIPAA compliance goes beyond EMR (Electronic Medical Record) applications, and includes the litany of small applications and medical devices that process, store, or transmit PHI. In order to ensure and demonstrate a comprehensive and complete state of compliance, healthcare providers need to make sure that risk assessments take into account all applications and medical devices, and provide clear supporting documentation of implemented controls and regulatory compliance.
For additional information, I have provided future 2013 and 2015 objectives below:
2013 Objectives:
Use summarized or de-identified data when reporting data for population health purposes (e.g. public health, quality reporting, and research) where appropriate, so that important information is available with minimal privacy risk
2013 Measures:
Provide summarized or de-identified data, when sufficient, to satisfy a data request for population health purposes
2015 Objectives:
Provide patients, on request, with an accounting of treatment, payment, and health care operations disclosures
Protect sensitive health information to minimize reluctance of patients to seek care because of privacy concerns
2015 Measures:
Provide patients, on request, with a timely accounting of disclosures for treatment, payment, and health care operations, in compliance with applicable law
Incorporate and utilize technology to segment sensitive data
As a continuation of the HITRUST blog series, in this post I would like to take a closer look at the Common Security Framework CSF, and what it’s all about.
The CSF is designed based on the ISO/IEC 27001:2005 and ISO/IEC 27002:2005 standards. Additionally, the framework currently includes:
NIST 800 series of standards
ISO/IEC 27799:2008 Health Informatics
COBIT
PCI
HIPAA
HITECH Act
FTC 16 Red Flags Rules
HITECH is planning to add other regulatory requirements and standards, such as EHNAC’s Healthcare Network Accreditation Program (HNAP-EHN), Healthcare Information Technology Standards Panel, and CMS Information Security (IS). However, the real value of the framework is not in that it provides a clear cross-reference between these and future requirements, since this information is already available within a broad range of compliance management tools, but rather that the reconciliation of the different standards and the additions of the controls are based on experiences and best practices from the HITRUST participants.
Each control described within the framework includes basic information such as control objectives, descriptions, and a few different categories that it may be associated with. Additionally, each control includes the following, which differentiates it from others:
Control Implementation – This is a prescriptive description of a control that provides detailed information about different aspects of implementation.
Control Audit Procedures – Detailed instructions that clearly document the steps that CSF assessors should take in order to accurately ascertain compliance with the specific control.
Control Standards Mapping – All regulatory requirements and standards that apply to the particular control.
Alternative Controls – Compensating controls that have been approved by HITRUST, that may be used in place of the controls listed. All organizations may submit their alternative or compensating controls to HITRUST for approval, which will subsequently include them in the framework for the benefit of other companies.
Required for Certification – Some controls are marked as required for certification, while others are only recommended for compliance with specific regulatory requirements. (I know that ability to certify while not being compliant is odd, but hang in there, I will tackle this topic in the next blog post).
Organizational or System – Organizational controls are implemented for the entire organization, while system controls should be implemented and audited on each system containing ePHI.
The engine supporting the framework allows easy searching and navigation of the framework. Additionally, all regulatory requirement and standards references are presented as hyperlinks that will navigate directly to the original authoritative sources. HITRUST also has created several reports that can enable companies to determine gaps within any of the regulatory standards, based on the framework control references. Overall, since the framework is available free of charge, I strongly recommend people to register with HITRUST and browse around.
In addition to providing a list of controls, HITRUST has also incorporated different levels of implementation for different controls. These are guided by the size of the organization, and range from Level 1 (most basic implementation) to Level 3 (most advanced security). Therefore, in order to understand which level of implementation would be applicable for a specific organization, it’s important to pay attention to the organizational and system factors, which include a wide range of consideration such as the need for PCI compliance, number of patient visits or hospital beds, number of employees, internet connectivity, or many others. However, in order to allow for easier and more automated determination, HITRUST has created spreadsheets where an organization simply needs to fill out some basic information, and the next tab will provide the required levels of implementation for each control.
To summarize, the CSF is specific, prescriptive, and scalable, providing not only guidance for implementation, but also for validation and attestation of compliance. The framework is intended to be in continuous development, by addition of formally accepted alternative controls, as well as entity type specific implementation requirements. Another important misconception is that CSF is a new standard. In truth, the CSF is an interpretation of other existing standards. Therefore, even if adopting a relatively new framework seems like a risky investment of time and resources, I would encourage organizations to at least become familiar with it. You never know, you just might find some great ideas that may be applicable for your environment.
In the next post in this series, I will focus on the topic of HITRUST certification, and what it means in the context of compliance with other regulatory requirements such as HIPAA, HITECH, and PCI.
HITRUST is rapidly gaining popularity in the healthcare and security consulting fields, and NetSPI is investing significant resources in developing services that will assist clients in taking advantage of the new Common Security Framework (CSF), as well as in achieving all the benefits of optimizing information security programs against an industry-developed and accepted framework. As a way of introducing this new development, I will write a series of blog posts intended to familiarize anyone interested with just what HITRUST and the CSF are all about. So, let’s dive in…
Imagine that health providers, payers, and service providers got tired of constantly having to deal with different interpretations of regulatory requirements, an ongoing series of compliance and third-party audits, and inconsistencies among different regulatory standards. Also, imagine that they decided to get together and perform the tremendous task of not only correlating various regulatory requirements, but also reconciling any differences among standards. Well, that happened… sort of. More specifically, the Health Information Trust Alliance (HITRUST), a for-profit company, brought them all together and assisted them in this very ambitious effort called the Common Security Framework (CSF), available for free from their website. (http://www.hitrustalliance.net)
In addition to developing the framework, HITRUST has positioned itself as a certification body that will allow companies to demonstrate their acceptance of the CSF framework, by issuing a certification. It is important to note that certification does not mean that the organization has implemented 100% of the controls described within the framework, but rather that it meet a specific certification threshold. Another important note is that certification does not mean compliance with all standards included in the CSF… but more on that later. The minimum certification requirement has been agreed upon by all participating members as the current minimum standard for security controls that an organization in healthcare should maintain. This approach is consistent with the goal of having the framework be based on practical expectations rather than often unrealistic regulatory expectations.
The reality is that most companies are currently not compliant even with the most basic requirements required by HIPAA, and now further enforced by the HITECH provisions of the 2009 American Recovery and Reinvestment Act (ARRA). Even with the level of specificity added by HITECH, there is a lot of room for interpretation of the requirements by auditors and security analysts. Recognizing this problem, the HITRUST Alliance has decided to leverage the power of the healthcare community at taking a step forward in defining a certain minimum set of requirements, intended to move all providers, payers, and business partners in the right direction. Additionally, if your organization has the misfortune of having to defend its security controls and demonstrating HIPAA compliance in court, being able to demonstrate the use of controls approved by the larger healthcare community will provide a stronger legal position.
Check back for a more detailed look into the CSF, as well as information about the certification path and my humble opinions about the future opportunities and challenges for HITRUST.
