Security standards exist because someone recognized a need. HIPAA, for example, was created to protect sensitive healthcare data. All information security regulations were created for a reason. Healthcare organizations are required to comply with HIPAA and HITECH. HIPAA and HITECH define a standard that should be placed on certain healthcare data. While they might give us a sense of security, do HIPAA and HITECH really make us more secure?
I thought HIPAA was “old news” by now, but when I asked several people who work in clinical environments about HIPAA, their responses varied. My single favorite comment was that “HIPAA sucks. We did all this **** anyway, but now we spend three times as much time proving it.” Answers like “HIPAA interferes with patient care” and “HIPAA is good policy, and it makes us better” reflect the controversial nature of these regulations. While the goal of HIPAA was to simplify administration, no one I talked with described that way. Instead, several people said, “HIPAA is a burden.” Obviously, my results are completely informal, but despite the quotes I used, the general consensus seems to be that although HIPAA is a good thing, it is not cheap. More than one person I asked said that HIPAA was the single most expensive thing they ever did.
Depending on whom you ask and where you look, spending on HIPAA compliance alone is estimated to average one to five billion dollars annually. Although HIPAA should save money by simplification of administration and standardization of e-records, the results suggest that the savings have not been nearly enough to compensate for the cost of compliance.
So, we’ve established that HIPAA costs money. I will repeat the question – does HIPAA make us more secure?
The answer is an unqualified ”it depends.”
Fear can be a great motivator–fear of the $25,000 fine per violation, fine of up to $250,000 for mis-use of patient information, or up to $1.5 million in event of “willful neglect.” At the same time, it can be hard to justify spending limited resources to avoid what has mostly been the threat of theoretical fines. Some of those things are easier to deal with, as you don’t necessarily need full HIPAA compliance to avoid the worst fines. My own experience has been that organizations either “do HIPAA” or they don’t – there are very few partial implementations, though I suspect and hope, that we are past the willful ignoring of HIPAA.
If I have seen any failures in HIPAA it is the relative lack of full-scale adoption of Electronic Medical Records (EMR). The April 16, 2009 edition of the New England Journal of Medicine says that only about 1.5% of U.S. hospitals have a “comprehensive electronic-records system… and an additional 7.6% have a basic (EMR) system.” The numbers are not exactly overwhelming. Indeed, the EMR itself is not as relevant as the fact that other HIPAA requirements were put in place to help protect these EMRs.
I know of a medical complex that passed HIPAA compliance audits, yet because they failed to control the process by which someone is granted authorization to access patient records, a breach of patient confidentiality resulted. The hhs.gov website is full of similar breach notifications where a “HIPAA compliant” component of an organization’s security program failed.
The catch is that if you focus on straight “HIPAA compliance” you can show at least some compliance, but still be lacking security. So, compliance does not necessarily equal security. The better approach is to think about “security,” and use the HIPAA standard to help identify an appropriate level of security for your own environment.
Once upon a time, I took a walk around the cafeteria and parking garage of a large hospital with some members of the board. They were a little shocked at how much we overheard, including patient names, and diagnostic information. The big shocker was the doctor we heard giving dictation through his cell phone, identifying a prominent local “celebrity” by name, and describing the symptoms of the sexually transmitted disease from which he was suffering. The hospital immediately publicized a “no talking about patients in public” program, including a new “Code White” policy. If you heard someone having an improper conversation about private information in a public location, you were supposed to call a “Code White” on them – a nicer way to say “shut up.” The initiatives were justified on the grounds of HIPAA compliance, supported by patient privacy initiatives, including informal training and informal reminders. Guidance firm, consistent and effective. In this case, HIPAA helped by being the club they used to correct a flaw in their normal work habits. HIPAA was the justification, expenses were actually pretty limited, and their practices improved.
I once saw the results of a rather bloody Joint Commission audit. The auditors had a four day visit, at the end of which the hospital was given nine pages of findings, and told that their practices were “marginal at best.” The hospital complex was worried. They would be subject to a follow-up audit and face penalties if the “findings were not addressed.” This was a non-profit hospital, operating on a relatively low margin, potentially facing fines, decertification, and suspension of Medicare reimbursements. Panic set in.
They needed an approach to help them manage their findings, so we helped them develop a strategic approach to their security program.
1. We helped them conduct an assessment. We did part of the assessment as a third party, and their internal IT staff and auditors did part of it as well. The purpose of the assessment was to focus on one thing: HIPAA Compliance. We did an evaluation of hospital practices against each and every line item requirement in the HIPAA standard (45 CFR Parts 160, 162, and 164, Health Insurance Reform: Security Standards; Final Rule).
2. They ended up with a set of findings that matched the recommendations from their earlier audit pretty closely. We then worked with them to prioritize findings, identifying issues which would have more or less impact on their overall security, and issues which would require more or less effort to resolve.
3. They picked the “low effort” tasks to address their out of compliance issues, and closed many of the identified issues pretty quickly.
4. For every issue that remained open they defined an action plan that described their approach to close the issue and milestones to complete the tasking.
They continued to work on the priority items until they received notice that they were going to be re-audited. About a week before the auditors were onsite, the hospital mailed the results of their own assessment, including the action plans, to the auditors. Their re-audit lasted less than a day, and the auditor left with no new findings. Instead, he told them to keep working on their action plans.
Completion of the items in their action plan was not without pain and expense. But, the fact that they had gone through a formal HIPAA evaluation, and actually had a “plan” was crucial to their improved security. The first assessment was a shock to them because it revealed so much. In a sense, ignorance is bliss. They were a hospital complex, and had never gone through a full assessment or audit from a security point of view. As part of their own security program, they implemented a formal review of their compliance and practices, and included that as a foundation of their program (see 164.308(a)(1)(i) Standard: Security management process).
HIPAA became the structure upon which they built their security program. They used plenty of other guidance to define the actual policies, procedures, and exact controls that they put in place, but the entire program was continually measured against the following three goals:
1. Did it support their business?
2. Was it fundamentally good security?
3. Was it HIPAA compliant?
In their case, a HIPAA Compliant-driven security program worked, because they looked at the intent of each requirement, and adjusted practices and controls accordingly. HIPAA effectively defined the structure of their security program, and undefined components supported that structure. The used HIPAA to help become more secure, and security effectively dragged along compliance for the ride.
What are the most “security” relevant portions of HIPAA?
1. Risk Management – The first one is obvious – 164.308(a)(1)(i) Standard: Security management process, specifically paragraph 164.308(a)(1)(ii)(A) Risk Analysis. This is the concept that you actually base your security program on a true analysis of risks to your data in your environment.
2. Assess – If you pair that up with 164.308(a)(1)(ii)(D), and you actual do the Information system activity review, you would be going a long way towards identifying risks, as well as the underlying weaknesses that lead to those risks.
3. Access and Authorization Management – 164.308(a)(3)(ii)(A), and many others (i.e., 164.312(a)(1) and (2) which define associated technical controls) require effective authentication, along with an authorization process that helps ensure that people who have access to sensitive information are indeed the people who they claim to be, and that they are truly authorized to have such access.
4. Contingency Planning – 164.308(a)(7)(i) and (ii) require contingency planning, disaster recovery, and business continuity planning that protect the data, and the organization’s ability to access that data in a meaningful manner, in order to provide required care or service.
5. Encryption – 164.312(a)(2)(iv) is almost buried as a sub-requirement, but requires the use of effective encryption to secure protected health information.
6. Integrity – 164.312(c)(1) is designed to protect the integrity of healthcare data – you have to make sure that the data is accurate to support quality of care.
Yes, there are plenty of other HIPAA requirements. We can argue about where they fall in the hierarchy, but I assert that the rest of the HIPAA requirements mostly support these six in one form or another.
The ultimate answer seems to be that as long as the compliance is thought of as one component of an integrated security system, and not the only answer, then compliance is good for security. Perhaps the better answer is that security is good for compliance.
