Direct Project: Secure e-mail in MU2

MU2 is here, and with it: secure e-mail

As Meaningful Use 2014 EHRs come online this winter, clinicians across the country gain access the host of new features included in the MU 2014 Certification Requirements. In this post, we’ll dig into one of these features: EHR-based secure e-mail capabilities that operate using the “Direct Project” specification. (If you’re new to this world: when you hear “Direct Project,” you should think “secure e-mail for healthcare.”)

It’s a party!

In theory, giving every clinician in the country a secure e-mail inbox ought to enable something amazing (and amazingly familiar, for anyone who has used e-mail outside of healthcare): the ability to converse electronically, back-and-forth, in one-on-one or one-to-many discussions with… well…  whomever you choose.

… but not everybody’s invited 🙁

Unfortunately, the practice hasn’t caught up to the theory. EHRs provide restricted inboxes that allow messaging to some recipients but not others. Why? It comes down to “trust,” which is a broad topic that we’ll treat only glancingly, where it intersects with the technology.

One of the requirements for Direct Project messaging is security, which means (among other things) that messages must be encrypted as they travel. To properly handle encryption, the sender’s EHR software (or Health Information Service Provider) needs to reliably discover the recipient’s cryptographic certificate, extract a public key from that certificate, and use that public key to encrypt each message before sending it out over the wire.

So far so good. But how does certificate discovery work? When you find a certificate associated with a recipient’s Direct address, how do you know whether that certificate is genuine? This is where “trust” comes in. Direct Project implementations generally answer this question in one way: you know a certificate is genuine if and only if it’s been signed by an organization that your organization trusts.

This has some real, practical (and really practical) implications: end-users don’t get to decide where and to whom they can send Direct messages. They’re restricted by their organization’s policies. This means that a physician working at Good Health Clinic might not be able to send a secure e-mail to her colleague across town, or receive a secure e-mail from a new patient seeking a consult.

The problem grows when you consider that many organizations do not maintain their own trust infrastructure.  Instead, EHR products handle this functionality on behalf of their customers, and often at a national scale — which means that the same trust policy applies to all of a vendor’s customers across the entire country.  If Good Health Clinic uses this kind of EHR, then there is effectively no way to customize the trust policy at the organizational level or the clinician level.

What will clinicians see?

With the EHR systems being deployed for MU2, the user experience will include failure and frustration when clinicians try sending a secure e-mail to anyone on “the fringes” of their community. By “fringes,” I mean anyone who lives in a different state, or uses a different EHR, or (gasp!) uses self-hosted email infrastructure. Over time, EHR users may simply come to expect that secure e-mail only sort-of works; when it fails, the error messages will be mysterious, unactionable, and often wrong. And if one of those “fringe” people tries sending you a secure e-mail, your EHR system can reject it without ever informing you. The message will simply “bounce back” to the sender before it hits your inbox, so the scale of the problem may be invisible to you.

Got five minutes and a 2014 EHR? Try an experiment with me!

If you’re using a 2014 Certified EHR, please try an experiment with me. Try sending a message to and Tweet the result @JoshCMandel.  You’re likely to see an error message like: “Sorry, you cannot send to because that address invalid.”

Moving forward: Mass Medical Society leads the way

The Massachusetts Medical Society recently looked at this issue from the perspective of physician autonomy, and they put forth the following resolution:

… that all Direct secure e-mail systems, mandated by Meaningful Use stage 2, including health information exchanges and electronic health record systems,  allow a licensed physician to designate any specified Direct recipient or sender without interference from any institution, electronic health record vendor, or intermediary transport agent.

Effectively, MMS  is advocating for user-specific whitelists that override any external restrictions on whom physicians are allowed to converse with. They envision a world that looks a lot like the e-mail systems we know and use every day in our “civilian” lives.

As things stand, clinicians across the country now have access to a secure inbox feature that should provide amazing value — but the feature falls short of the promise. I think it’s an incredibly important conversation for the community, and I admire the clear and (ahem!) direct vision that MMS has described.