When working with as many healthcare providers as we do, we begin to see trends regarding the common questions and concerns surrounding sending and receiving ePHI over email. Even more common are questions concerning internal messages, wherein
bob@hospital1 seeks to send patient data to
alice@hospital1. While this is a deceptively nuanced topic we’ll attempt to impart some clarity.
Please note that Oppor Co. is not a law firm and that this discussion is an opinion and should not be construed as legal advice. For definitive information concerning local or federal regulatory impact consult your legal team.
As there are an infinite number of ways to implement and operate an email infrastructure, we’re going to narrow the scope of this discussion to 2 popular configurations:
Question 1: Is it Possible to Send ePHI Over Hosted Email While Still Complying with HIPAA?
Yes, it certainly is possible. Consider the following:
When you use your Google Apps or Office 365 account to send messages to a coworker, the following occurs:
- You communicate securely with Google/Microsoft to create or upload the ePHI
- While enabling their own access, Google/Microsoft prevents public access to the data
- Your coworker communicates securely with Google/Microsoft to view or download the ePHI
While Step 1 and step 3 both satisfy § 164.312(e)(1) of the law, hopefully #2 caught your eye.
In order to give a third party access to your regulated data in this way you must ensure there exists an executed Business Associate Agreement. This is familiar territory for Google and Microsoft and both will happily accommodate. Here’s Google’s BAA initiatory info and here’s Microsoft’s.
Question 2: Should I Send ePHI Over Email?
Probably not, or, at least not without considering the following:
In Question 1 above we touched on an oversimplified scenario illustrating that there is no fundamental breach occurring when sending an internal message. Unfortunately, the story does not end there.
Your email mailbox data (I.E., everything you’ve ever sent or received that hasn’t yet been deleted) is inherently rife with confidentiality issues. Here are a few commons ways things can go awry.
Ex. A) Unauthorized access to a single message
Bob intends to email ePHI to
alice@hospital1, but accidentally sends after allowing autocorrect to change the recipient to
Ex. B) Unauthorized access to a copy of an offline mailbox
Alice regularly receives ePHI from coworkers. She accesses her email using Microsoft Outlook on a new, fully patched, antivirus and antimalware-laden, laptop. Her mail profile is configured to store the entire mailbox on the local hard disk to allow convenient offline use. Alice is afforded 25GB of mailbox storage and after three years of employment her mailbox contains records for 10,000 patients.
Alice returns to her car after lunch to discover that the laptop has been stolen.
Ex. C) Unauthorized access to an entire email account
Bob sends and receives ePHI throughout the day. He never downloads offline copies of his mailbox and manages his email exclusively via his browser. Bob attempts to keep his mailbox storage low and minimize the number of patient records in his account by deleting extraneous messages.
After seeing a series of unfamiliar messages in his Sent folder, Bob discovers that has fallen victim to a spearphishing attack, yielding complete account access to a third party for the past 2 months.
Question 3: Can I Avoid These Issues With An Internal Mail Server?
Probably not. Here’s why:
Examples A, B, and C above are all subject to the same vulnerabilities irrespective of mail server location. If your users have the ability to 1) send external email, 2) access mail using common email clients, or 3) access accounts externally then an internal mail server does little to help.
That said, if the internal mail server enforces the specific inability to 1) send external email, 2) access mail using common email clients, or 3) access accounts externally, then the native vulnerability is certainly reduced.
With that vulnerability reduction also comes a reduction in functionality, to a degree that few organizations will tolerate. Which, would likely introduce the operation of two parallel email infrastructures: one traditional and one for private internal sending.
Question 4: What’s The Best Way To Transmit ePHI
In light of the problems facing email-based ePHI transmission, alternate ways of sending ePHI internally should be considered. We’ll cover those in part 2 of this series. Stay tuned.