HITECH Could Catch Healthcare Service Providers With Their Pants Down
With the passage of the HITECH Act, the administrative, physical and technical requirements of the HIPAA Security Rule now apply in equal measure to folks in the healthcare market channel. And quite frankly, the channel is under-prepared. Assuming we want to serve our customers the best way we know how, what are some strategies to go from where we are now to where we need to be?
02/03/11 8:00 AM PT
Have you ever found yourself paying the penalty for a rule you didn't even know you were breaking? Like getting a ticket for speeding when you didn't realize the speed limit had changed? Or paying a work-related travel expenses out of our own pocket because you didn't realize your firm's travel policy had a restriction that you didn't know about?
It stinks, right? The stock answer of "ignorance of the law is no excuse" -- though we probably agree with it on one level -- seems like a tremendous injustice when we're the ones on the receiving end. But unfortunately, this is exactly the position that many service providers and vendors (i.e., in "the channel") in the healthcare market could find themselves in if they don't take action. The rules of the game have changed, and not following the rules could bring about penalties -- but many of us don't even realize any of this is happening.
I'm referring to recent changes in the law that has occurred as a result of the HITECH Act (Health Information Technology for Economic and Clinical Health). The HITECH Act, a part of 2009's economic stimulus act (i.e., the American Recovery and Reinvestment Act), includes requirements for the folks you'd expect: "covered entities" like healthcare providers, health insurance companies, clearinghouses, etc. However it also defines requirements for other folks too -- folks you might not intuitively expect. Specifically, it extends security requirements to "business associates" -- the vendors, service providers, consulting/staffing companies, and other partners that handle patient data and medical records on behalf of covered entities.
With the passage of this law, the administrative, physical and technical requirements of the HIPAA Security Rule -- the same regulatory requirements that protect medical records within a hospital and protect diagnostic information at a health insurance company -- now apply in equal measure to folks in the channel. And quite frankly, the channel is under-prepared.
Art Gross, president of healthcare-focused service provider and consultancy Entegration, put the situation this way: "Most business associates don't realize they have to do anything for compliance. For example, a hosting vendor might be responsible for any number of different clients -- some in the healthcare sector and some not. They might not even realize that there is medical data in a particular environment."
That's a hard situation to be in when the law requires that you address the security of that data. Assuming we want to serve our customers the best way we know how -- and not to mention avoid potential regulatory action down the line -- what are some strategies to go from where we are now to where we need to be?
Step 1: Assess. Are You a Business Associate?
It almost goes without saying, but straight away it's important for those of us in the channel to take an accurate stock of ourselves to determine if we are a business associate. The law (note: I'm not a lawyer, this is not legal advice) in 45 CFR §160.1031 (i.e., the "definitions" section) defines a business associate in such a way that it seems pretty clearly to include those of us in the channel. Specifically, the definition includes a business if it:
Provides a "... function or activity involving the use or disclosure of individually identifiable health information, including claims processing or administration, data analysis, processing or administration, utilization review, quality assurance, billing, benefit management, practice management, and repricing?" [45 CFR §160.103(1)(i)(A)]; or
"Provides ... legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, or financial services to or for such covered entity" [45 CFR §160.103(1)(ii)]
If this strikes you as a pretty broad definition, it is. In addition to reading the full text of the definition for yourself, you're also best served by discussing it with your legal counsel (be it internal, retained, or otherwise). But while you are doing that, Gross recommends as a practical litmus test that service providers look to see if they've signed a business associate agreement in the past with a covered entity.
"Covered entities have been required to enter into business associate agreements for years under the old rules," he said. "So if you've signed one of these, somebody considers you to be one ... plus it's pretty hard to argue that you're not a business associate if you've previously executed a contract stating that you are."
If you take these steps and conclude you aren't a business associate, congratulations to you. However, you might be surprised at what you find. In the case that you do conclude yourself to be a business associate, you have some work to do.
Step 2: Welcome to the Security Rule!
So it turns out that you're a business associate. What next? The next step, according to Gross, is to go directly to the Security Rule for guidance.
"Become educated on what your requirements are," he said. "Put together the policies and procedures that address the regulation just like a covered entity would."
So start by reading through the regulation, reading through the educational information the HHS has made available, and implement a requirement-by-requirement action plan for your particular service offerings. If you're a vendor that already has faced the challenges of other regulatory requirements like PCI, a compliance exercise like this one should not be unfamiliar ground to you -- and it would ideally involve the same people who have addressed other regulatory requirements in the past.
Lastly, see if there is a way to fold in the specific requirements of HIPAA Security into your existing compliance program; you may find that there is quite a bit of overlap between HIPAA's requirements and other regulations.
Gross also recommends that service providers who provide hosting or other managed service environments build out a HIPAA-tailored environment.
"I'd recommend very strongly that vendors have a specific environment that addresses the HIPAA security rule," he said. "If you support a car dealership, for example, transporting a server to a data center is obviously very important, and if that server goes missing, it's not ideal. But if you're transporting somebody's EMR [Electronic Medical Record] system and it goes missing, it's a different situation entirely -- that could involve notification requirements and potentially penalties. Clearly, the two situations are different."
The providers that you service and support are going to be looking for a willingness to work with them as a business associate -- through, for example, execution of a business associate agreement as well as being able to answer specific questions about how you address the requirements. It's not the end of the world that these requirements you might not already know about apply to you. By educating yourself to the point that you can demonstrate knowledge of -- and can tell a convincing story about how you address -- the requirements, you not only satisfy regulatory requirements but you can also demonstrate a potential competitive advantage.
Ed Moyle is a senior security strategist with Savvis, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner of Security Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development.