Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Thursday, March 11, 2010

Healthcare e-mail -- NOT an Option

I was asked the other day why we cannot communicate health information via e-mail.  We certainly communicate enough other information over e-mail and even use it in part to establish banking, health and other vendor account access through that channel.

I want you to follow along with me in a little experiment.
  1. Send e-mail from one e-mail account you have to another.
  2. Open up your e-mail client where you recieved the e-mail you sent to yourself.
  3. User whatever option is necessary to view your e-mail headers (for Outlook and G-mail, see the postscript below if you don't know how to do this).
  4. Count the number of times you see the string "Recieved:"
  5. Make a list of the IP addresses and host names you see on each line starting with "Recieved:"
  6. Identify who manages each of the servers identified on these recieved lines.
I sent myself a test e-mail from my corporate e-mail account to my gmail account.  I counted 6 Recieved:" headers.

Each of the Recieved: headers in the e-mail is placed there by an SMTP server.  Therefore, there are six separate servers where my e-mail to myself could have been stored before being subsequently forwarded to the next one in the chain.  Each of the servers has at least one, and possibly several connections to an outside or internal network.  They may also be backed up periodically, storing a permanent copy of the e-mail that was in transit.

In only two cases was the communication between the servers reported to be protected by encryption, but other cases may have been ecrypted, or physically secured within a data center.  In at least one case, the encryption was the weak RC4 cypher reported to be "unsafe at any key size".

If I were to send a credit card number through this path, there are six different servers that could be attacked to get that number, six different networks that could be sniffed to pick out the SMTP traffic that would contain it, and possibly a backup or two that might also contain the information that hadn't been forwarded.  I have no clue who manages these servers, networks and their backups, and whether they have the latest patches, et cetera (But I can certainly identify the product and in some cases even the version number of it being used, which makes attacking them much easier).  Would I send a credit card number through this channel?  No way.

So as a model to communicate healthcare information, e-mail by itself leaves quite a bit to be desired.  Something more is needed.  Additional security can be provided by S/MIME, but then you need to obtain certificates, and S/MIME isn't ubiquitiously available on all e-mail clients.  There is an additional human factor to consider.  An e-mail message is very easily forwarded from one person to another.  The e-mail tools make it very simple to do this, and they don't make it simple to ensure that when the message is forwarded, that it is transmitted securely.  So even though a single e-mail itself can be secured, it's just not the right way to do it because there are many other risks that make the content of the communication difficult to protect adequately.

There've been some attempts to develop new standards for e-mail that would make it safer, but that's a lot of infrastructure to update, and so those attempts haven't made much headway.

So why is it safe to use e-mail to establish accounts?  Well it really isn't, but:  The amount of information that a vendor sends you in in an e-mail to establish an account is really just to confirm the e-mail is correctly linked to your identity, which you provided them over a secured (https:) channel.  Usually it includes a conformation code that can only be used once, and having been used once cannot be used again.  The time between signing up and recieving that e-mail communication (and making use of it) is also very short in most cases, which leaves little opportunity for someone to use it against you.  If I do happen to be given login credentials over an e-mail channel, I immediately use them to login and change my password over the secure website.  That way I'm sure my password isn't sitting on some server somewhere where who only knows can read it.

P.S.  In Outlook, open an e-mail fully, then click on the View Menu and select Options.  In the dialog that is displayed, look at Internet Headers. 
In G-mail, open the mail.  Then click on the down arrow next to the Reply button in the upper right hand corner of the e-mail.  Then select "Show Orginal".


  1. Short form:

    All of the issues you list are lack of infrastructure issues, nothing fundamental. Small communities have dealt with these issues and use email for medical data. The lack of infrastructure has halted it's use in the larger communities.

    Longer form:

    The non-authoritarian system PGP works. It remains sufficiently strong that the FBI still finds a different way to get information against organized crime activity protected by PGP. I've been using PGP since 1994. But market penetration is tiny, and the authoritarian players will not accept it.

    The authorities do not support personal certificates effectively, and the infrastructure support for mixed self-signed and authoritarian certs isn't there. But in smaller communities, such as various European regions and the US dental community, the certificate infrastructure has been provided and S/MIME email is used for medical data.

    The ability to forward is a red herring. It doesn't matter whether I use e-mail, couriers with media, or the latest IHE transports. The recipient is always capable of forwarding data. It's inherent in the exchange of medical data that you must trust the recipient (or don't send that data).

    There is also the issue of gmail and webmail in general. These are not configured to support encrypted mail well. It can be done, but it is very inconvenient. Again, an infrastructure problem.

  2. Despite a lot of rhetoric about privacy protections, there remains no leadership to organize and build the market to support a privacy-protecting infrastructure architecture. This especially includes an orderly and extensible set of market semantics so we all can be clear of what "privacy" means. There is also no leadership to establish a risk evaluation framework so we all could make good economic decision about how much protection we should afford.

    It's hard to market something that you cannot describe unambiguously and cannot place a value on.

    While there are limited-scale counterexamples, the fact remains that ubiquitous easy-to-use private e-mail is not available. I don't blame this on market-dominating vendors. Rather, I do point the finger at those who could but fail to lead and build the market.

    I do not expect this to come from the government. In fact, I dread that it might.