7 HIPAA Compliant Assumptions That Can Trip Up IT
IT Teams Do the Heavy Lifting to Ensure HIPAA Compliance
Are you or aren’t you? Compliant, I mean. Seems like an easy enough question to answer, but ever since passage of the Health Insurance Portability and Accountability Act (HIPAA) in 1996, businesses have struggled with their response. Even after a decade-and-a-half to prepare, many providers and other covered entities were scrambling to meet the September 23, 2013 deadline imposed by the Omnibus Rule.
The deadline has come and gone, but the question remains: are you or aren’t you? The path to compliance can be difficult to navigate, made all the more confusing by updates to the law since its initial passage. HIPAA contains few absolute measures that must be implemented to achieve compliance. And once you have deployed the technology solutions, implemented the policies and trained your personnel, there’s still no centralized “compliance agency” waiting to give you a stamp of approval.
As if interpreting the requirements weren’t confusing enough, there’s also a substantial risk to non-compliance in the form of fines up to $1.5 million per incident. And with the passage of the Omnibus Rule, those fines apply equally to covered entities and business associates.
While not just an IT problem, IT teams have nonetheless been called on to do the heavy lifting necessary to ensure HIPAA compliance. These efforts are often undertaken with little understanding of what’s actually required in order to achieve HIPAA compliance and frequently result in processes that are lacking in small but important ways. From my conversations with customers regarding their compliance needs and solutions, I hear several recurring incorrect assumptions that can spell trouble.
Here are seven of the most common incorrect HIPAA compliance assumptions that I’ve encountered. If any of these sound familiar, you may need to take a closer look at your organization’s compliance program.
- Our vendor’s service is HIPAA compliant, so my system is compliant.
I frequently encounter IT managers who firmly believe that deploying a software package touted as “HIPAA compliant” is all that’s required to achieve compliance. Compliance with HIPAA requirements is not transferable; while your vendor’s status is important, your organization should implement its own comprehensive HIPAA compliance program. You’ll want to make sure that your processes are HIPAA compliant, then select vendors that fit your organization’s security framework.
- My vendor signed a BAA, so I’m covered.
With so much ambiguity within HIPAA, it’s easy to have a disconnect with vendors’ interpretation of compliance. Vendor selection should be guided by established protocols in your overall HIPAA compliance program. When entering into a relationship with a vendor, it’s like the old adage says: trust, but verify. Even if a vendor willingly offers to sign a Business Associate Agreement (BAA), you should always perform due diligence to ensure their product or service is a match for your organization.
- We don’t use cloud services because they are insecure.
This assumption is no more true than concluding that on-site solutions are always secure. Cloud services offer a number of advantages – cost savings, increased efficiency, lower infrastructure overhead – over their traditional counterparts, and many offer HIPAA compliant services tailored to the needs of healthcare customers.
- Our corporate policies restrict user access to PHI, so we are in compliance.
While policies and procedures are key to any HIPAA compliance program, these elements are nothing without rigorous monitoring and ongoing enforcement. Your organization should always be on the lookout for security breaches, both technological and procedural, to ensure Protected Health Information (PHI) is secure. As additional reinforcement, consider conducting routine training sessions with employees regarding policies and procedures covering access and use of PHI.
- We use an in-house fax server so our transmissions are secure behind our firewall.
Fax servers can help ensure the security of PHI during transmission, but often fall short in protecting the same data while stored on your network. Fax servers often hand-off PHI data to email or file servers that may be vulnerable to unauthorized access from within your network. As an additional layer of security, consider solutions that offer “at rest” encryption of PHI while stored within your systems.
- Our EHR system has a well-documented audit trail, so a document sharing policy would be redundant.
An audit trail is great, but it only covers data while it lives within your EHR system. What happens once a record is printed? Consider implementing a clear, comprehensive document sharing policy that addresses handling of PHI both within and outside of your EHR system. Think of the document sharing policy as a complement to your EHR audit trail, not a redundancy.
- Our email provider offers TLS encryption, so we’re secure in sending email attachments.
TLS encryption is a great tool to help secure emails in transit, but only works if both sides of the email transaction are configured properly. Many consumer email providers aren’t equipped to support TLS encryption for their subscribers. If your email provider is only using opportunistic TLS and the recipient doesn’t support TLS, emails with PHI could be transmitted with no encryption at all. You may want to think twice about sending PHI over email, particularly when other, more secure methods are available.
There are no simple assurances when it comes to HIPAA compliance, but by making yourself aware of these seven missteps, you will be better prepared to give greater consideration to the compliance of your data and document management processes.
This article is contributed by: eFax Corporate® is a brand of j2 Global®, Inc. (NASDAQ:JCOM). Founded in 1995, j2 is an award-winning, leading provider of Internet services through its two divisions: Business Cloud Services and Digital Media. As of December 31, 2013, j2 had achieved 18 consecutive fiscal years of revenue growth. For more information about eFax Corporate®, please visit: enterprise.efax.com