Not a week goes by that we don’t get asked: “Can you host HIPAA-compliant email for us?” The answer is always “Yes, but…” which is not always the welcomed response, but it’s the truth.
The real truth is that, first and foremost, the Covered Entity is ultimately responsible for compliance. This is not because our lawyers have added a clever clause to our contract absolving us of such responsibility, it’s because that’s the law. And if you don’t believe us, Google something like “Is Microsoft Azure HIPAA Compliant?” and you’ll see links to all of Microsoft’s white papers saying the same thing.
So here’s how we approach HIPAA compliance when deploying Zimbra or Exchange email for clients. This is not a comprehensive checklist BTW; it’s an overview only and intended to get you thinking about some of the major things when migrating from self-hosting to Cloud Hosting.
- Let’s Get Legal. We need a Business Associate Agreement before we can touch any of your ePHI. We have a template and can likely work with yours too, but even when we have a Master Services Agreement already in place, we can’t go near your ePHI until we have both executed the BAA.
- End User Training. Technology can overcome only so much, so training users not to do things like put ePHI in the Subject of an email (the To:, From:, Subject: and other headers never get encrypted in flight) is something we like to schedule right away — before the new email system is deployed.
- Changed Workflow Requirements. We often find that healthcare providers’ existing workflows may not be HIPAA-compliant and need to change. Several years ago, we came across a doctor who had configured his work email to forward everything to his home Time-Warner email account, so he could get the emails on his phone (his work email did not support IMAP nor ActiveSync). We don’t do HIPAA audits, but we do have a big bucket of good best practices, so when we see something that gives us pause, we will speak up. Again, HIPAA compliance is ultimately the responsibility of the Covered Entity, and we treat our clients’ domiciling of their patients’ ePHI as if we were one of those patients.
- Real Insurances. Our parent company has insurance, including a $25 million umbrella policy, but so should you. We strongly recommend having a conversation with your attorney and your insurance broker to address things like Data Breach insurance ahead of time. It’s not our place to dictate to clients how much risk they should mitigate, but we feel compelled to make sure clients not only have options, but that we feel confident the client actually “gets” how much risk we think they may be exposing themselves to.
- Technical Insurances. Good end user training only goes so far, so even though we can lock down and configure the Zimbra or Exchange Cloud server to be HIPAA compliant (including things like encryption at rest and in flight, and policies preventing users forwarding email), these days clients want more. Consequently, we’ve started deploying a DLP appliance (Data Loss Prevention) to act as the outbound email relay for the email server. The appliance can be configured to encrypt all outgoing email — in which case the recipient gets an email with just an https web link to be able to retrieve the actual email. The appliance can also be configured to apply DLP “policies” so when for example a Social Security number is mistakenly placed in the Subject field (remember the Subject never gets encrypted!), the appliance blocks the email from being sent at all, and replaces it entirely with a notification to the recipient to collect the email via an https web link.
- “Process Insurances”. Unlike many providers who only have a SOC 1 (SSAE16) audit, we have a SOC 2 Type II audit covering Security, Availability and Confidentiality. Many providers misrepresent their SOC 1 as a true operational audit, when in fact the AICPA only allows a SOC 1 audit to be used for ICFR (Internal Controls over Financial Reporting) purposes, e.g. when a public company subject to Sarbanes-Oxley uses an outside payroll processing firm; the payroll processor will have a SOC 1. A SOC 2 audit however, does not allow the provider to cherry pick control objectives which have to be met like in a SOC 1; each Trust Principle (three in our case: Security, Confidentiality and Availability) comes with its own basket of control objectives, and we have to prove to our auditor (who renders an opinion) that our processes and procedures, and our adherence to our processes and procedures during the audit period, are OK to meet all of the control objectives. The depth and comprehensiveness of a SOC 2 Type II audit is quite extraordinary, and goes a long way to explain why the audit fees are five figures.
Although the HITECH Act clarified an awful lot, as compared to other regulated industries like finance, HIPAA often tells you what you need to accomplish but not always how to do so precisely. In finance, 17 CFR 240.17a-3 and 17 CFR 240.17a-4 (Commonly referred to as SEC 17a-3 and 17a-4) clearly specify the technical and administrative requirements for email archiving (i.e. retaining a copy of all inbound and outbound messages in a particular form for a specified length of time on storage media meeting specific technical and access requirements). There’s no such equivalent within HIPAA/HITECH, and (one last time…) it’s the Covered Entity that is ultimately responsible for compliance.
If you are a Covered Entity considering moving email, EHR or other applications with ePHI off-premises to a secure Cloud provider like us, our experience has been that you will have many questions, so please give us a call at (207) 772-5678 to start the conversation.
L. Mark Stone
General Manager, Managed and Private/Hybrid Cloud Services
A Division of OTT Communications
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone and do not necessarily reflect those of Reliable Networks, OTT Communications or Otelco Inc. The contents of this site are not intended as advice for any purpose and are subject to change without notice. We make no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.