I like to watch industries evolve in how they deal with information security. It was interesting to watch retail evolve as PCI got more organized. The PCI Council put together the DSS with dates and penalties for breaches and non-compliance, and that drove significant change. It appears that a similar major change within healthcare is starting to take place. We have begun to see a proactive shift that incorporates compliance with HIPAA, an understanding of risk, and the development of security programs.
As I’ve discussed in the past, the healthcare industry is significantly behind in dealing with IT-related risk. For an industry to change its approach to information security / risk, its culture needs to evolve. In my opinion, risk is the most effective driver of this change. If the risk is great enough, industries develop a mature understanding of risk management (of which security is a subset). The military and banking have tangible risks tied directly to their IT assets; therefore, they understand risk. The problem is that this mature understanding of risk doesn’t exist in most other industries. Without risk driving a security program, industries must rely on other drivers - usually compliance (also a subset of risk).
What we’re seeing within healthcare is that PCI is driving the maturation of risk. For example, one key issue that keeps coming up, especially in hospitals, is the belief that PHI is more important than PCI / credit card information. Yet it is PCI compliance that has forced organizations to think systematically about risk. How do you reconcile the budget for PCI compliance with the lack of budget for PHI-related security?
In addition, PCI has forced multiple groups (including IT, security, audit, and finance) to work together to deal with compliance and, ultimately, information security issues. Many of these same groups are now being asked to deal with HITECH / ARRA / updated HIPAA. With the new interpretations of HIPAA, the new regulations, and with these new sets of eyes, these groups are beginning to understand that they are not compliant with HIPAA, that they have significant risk exposure, and that they need to develop programs to deal with this exposure.
From what we are seeing with many of our healthcare clients, the combination of a more pervasive awareness of PCI and new healthcare-specific regulations are creating a more mature understanding of risk and driving a new focus on developing successful information security programs. Let’s hope this trend continues.
I was at the Healthcare Information and Management Systems Society (HIMSS) national conference last week in Atlanta. Overall, the conference wasn’t much different than past years. From an information security perspective the presentations and conversations were limited, but there were a number of interesting things that I took away from the conference.
First and foremost, healthcare is still very far behind other industries in addressing security concerns at the application provider, hospital and insurer levels. It appears that the larger application providers have begun to address certain concerns; e.g., most healthcare software companies are beginning to address compliance. What’s interesting is that PCI and PCI PA-DSS are the main drivers forcing these organizations to at least review their products. This is obviously backwards, since any healthcare organization would claim that patient information is more important than credit card information, but it’s a testament to how important the stick of strong regulations and standards are when it comes to affecting change in a specific industry. Healthcare software companies still don’t view security or third-party review of their applications as important, but having seen the findings after many of these applications have gone through review, it’s something they will realize that they need to do.
Hospitals and insurers are similarly behind in developing strong information security programs, however many organizations are doing the right thing. It appears that it is mainly larger organizations (revenues $5B+) that have well developed security programs that address risk and compliance programmatically. These organizations generally have the funding and executive support to develop programs that are essentially what you would find in a similarly sized and well-managed Fortune 500 firm. The smaller firms ($5B and less) are generally much farther behind other similarly sized organizations in other industries. Many are just addressing PCI and are just starting to think about how they are going to truly address securing protected health information (PHI).
Based on these observations, there is a lot of work to be done to improve information security within healthcare. One would hope that the discussion surrounding this would take place at a conference like HIMSS. While security was not a main track at the conference, there were some discussions on security at HIMSS within the context of the American Recovery & Reinvestment Act (ARRA) and electronic medical records (EMR) security, including a daylong ARRA seminar on Sunday before the formal conference opening. However, since ARRA isn’t focused on security, the coverage of information security within these presentations tended to be somewhat limited.
It was very interesting that the Health Information Trust Alliance (HITRUST) was not discussed much at the conference. As the most comprehensive and usable solution for healthcare security, there weren’t any sessions on the topic and even conversations surrounding it were heavily overshadowed by discussions about ARRA. As one of the most valuable new initiatives for enhancing healthcare information security, hopefully this will change next year as the industry begins to understand how the HITRUST security framework can be of value to them.
With all the focus and money targeting healthcare IT, the next year will be very interesting and addressing security should be a high priority. Ideally, with the massive amounts of new funding available, more organizations will adopt a risk-based approach to their businesses, backed up by a strong information security program. As illustrated by the success of PCI (even within healthcare), it will probably take a combination of drivers to achieve this, including a strong dose of regulation to force changes within the healthcare industry. Hopefully, the outcome will incorporate standards such as HITRUST to ensure consistency, maturity, and higher levels of security within the healthcare industry.
In this conclusion of the HITRUST blog series, I would like to discuss some definite opportunities and challenges that HITRUST is likely to face.
Putting together a single prescriptive framework for the healthcare industry is truly an ambitious effort. However, cross-referencing this framework with different regulatory requirements and then proposing a mechanism by which companies can be certified against this framework takes any such ambitions to a whole new level. The good news is that many of the healthcare industry’s biggest organizations have gotten onboard and made significant contributions to this effort. Additionally, with the way HIPAA is written, there seems to be a lot of need for a framework such as this, which can enable companies to better defend their interpretations of HIPAA requirements. Therefore, I think the future of HITRUST is going to be defined within the following considerations:
Quality of the Framework – In order for the framework to gain traction, it must be of good quality, and it should achieve its stated objectives of being risk-based and prescriptive. Even though the framework is a product of multiple organizations collaborating, HITRUST does not necessarily govern by community and will make the final decision about CSF content. Another important aspect of the framework will be the approval process of alternative or compensating controls, and ensuring that the process of approvals or denials is transparent. Nothing will de-value the framework faster than perception of its being driven by the agenda of any specific company rather than the industry as a whole.
Maturity of the Certification Process – Having gone through the assessor training, I feel this is perhaps the weakest HITRUST point so far. In starting a certification program from scratch, mistakes are easy to make and are common (just ask the PCI Council). However, PCI DSS was not a voluntary program; compliance was mandatory. Requirements such as submitting complete gap analysis reports to HITRUST (including all found vulnerabilities spelled out in detail) are clearly not going to last, since I can’t imagine any company willing to submit a comprehensive set of their dirty laundry (including all areas where they are not compliant with regulatory requirements) to a for-profit company for their assessment and evaluation. However, I feel that once they begin to get this kind of feedback from HITRUST practitioners, they will make the necessary changes in their approach.
Certification Quality Assurance – Not all consulting firms are equal; in fact they differ greatly in the quality of their work. Therefore, HITRUST needs to establish a better-defined QA program, to govern the certification process. Protecting the integrity of the HITRUST certification will be essential for internal auditors to begin considering it in place of alternative third-party audits.
First Breach / Legal Challenge – In spite of the fact that HITRUST does not make any representations that regulatory compliance is synonymous with HITRUST certification, the first time a HITRUST-certified company suffers a breach or is a subject to regulatory inquiry, we will see the first official test of the framework. One of the big selling points of the framework is that their interpretations of HIPAA are valid and substantiated by the whole healthcare industry. However, if a judge disagrees with any of their interpretations, this may be very damaging to HITRUST acceptance.
I really want HITRUST to succeed. I think it’s a great initiative that has a lot of promise for the whole industry. However, I think it has a long way to go before it is widely accepted, and the certification process is sufficiently mature to inspire confidence on all sides. My recommendation for all healthcare providers and vendors is to begin looking at HITRUST and seeing how their security controls compare with those specified within the CSF. For those companies that do not have a security program in place and are looking to undergo a HIPAA gap assessment for the first time, I would recommend adopting the CSF. After all, the risks are fairly small, since the framework is based on current standards and not anything new. As to the expense of undergoing a full certification, I would recommend putting that on hold until the framework is more widely accepted, or in cases of service providers, until your customers begin to ask you for it.
As a continuation of the HITRUST blog series, in this post I would like to explore the concept of certification, and what it means.
So, by now I hope you’ve followed my advice and have been browsing the framework up and down. Perhaps you generated a few reports that show you just how easy it is to identify controls for each regulatory requirements and standard. You are now a CSF Ninja and have mastered the framework engine, and now you are ready for bringing the idea of HITRUST certification to your organization. However, there is a very important concept that I must stress with regard to certification:
HITRUST certification does not mean you are compliant with ANY of the regulatory requirements or standards referenced within CSF.
Since this is somewhat counter-intuitive, please take a few minutes to absorb this information. So, what is the value of a HITRUST certification?
To answer this question, it’s important to go back and review my first blog post in this series, and understand that one of the missions of HITRUST is to be practical and realistic in its approach to security. Therefore, the current certification is based on a certain minimum standard that had been agreed upon by all participating organizations. Therefore, the certification is not to be used as a way of proving HIPAA or HITECH compliance, but rather as proof of meeting the most basic security requirements the healthcare industry has deemed as most important. To a healthcare industry outsider this may appear weak and indecisive, and perhaps there is at least some truth in that statement. However, those that deal with the daily challenge of responding to a seemingly unending stream of third-party audit checklists and audits, and those who have to manage controls for hundreds of applications and hundreds of different medical devices will view even such a humble beginning as a monumental effort.
The overall goal is for the HITRUST certification to be used as a way of showing that a particular organization is focused on security and has all the basics covered. As the industry gets better with managing security, I fully anticipate the certification threshold to go up and become even more difficult to obtain. However, while HITRUST seeks acceptance by medical practitioners and various service providers, I think it’s wise to keep the certification requirements more attainable, even if the certification does not equal regulatory compliance. After all, each organization may choose to implement more than the certification minimum and get to a level of compliance before this is required by HITRUST.
In my view, the real value of the HITRUST certification is in simplifying and streamlining conversations between healthcare providers and vendors about the security of PHI data. If a vendor has a single framework to comply with, it may choose to spend more resource on achieving that compliance, and not worry about various checklists and rule interpretations by different security consultants and auditors. Similarly, if a patient care provider can focus on adopting a single framework, and requiring that all vendors do the same, the CSF certification may be acceptable in place of any other third-party assessments.
Please, check back for the fourth and final installment of the HITRUST blog series, when I present some of the opportunities and challenges HITRUST will face in the future.
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.
Subscribe