It seems everyone in the healthcare industry these days has a HIPAA disclaimer in their email postscript. Millions of these postscripts are transmitted along with additional millions of patient data points every day. It is often easy enough to simply send "That patient with the regurg? His O2 sat is stable". However, as formal means of electronic collaboration develop and the affordances of these electronic collaborations become more expected, this problem of privacy over open networks has the potential to become a major seam in the security of patient privacy. Here are some examples:
Attention!!!!! In accordance with the Health Insurance Portability and Accountability Act (HIPAA), this email may contain privileged and/or confidential information that is intended solely for the person(s) to whom it is addressed. If you received this email in error, please delete it immediately and contact the sender by return email. Thank you.
This document may contain information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. Healthcare information is personal and sensitive and must be treated accordingly. If this correspondence contains healthcare information it is being provided to you after appropriate authorization from the patient or under circumstances that don't require patient authorization. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Redisclosure without additional patient consent or as permitted by law is prohibited. Unauthorized redisclosure or failure to maintain confidentiality subjects you to application of appropriate sanction. If you have received this correspondence in error, please notify the sender at once and destroy any copies you have made
The documents accompanying this transmission contain confidential privileged information. The information is the property of the XXXXX University Medical Group and intended only for use by the individual or entity named above. The recipient of this information is prohibited from disclosing the contents of the information to another party. If you are neither the intended recipient, nor the employee or agent responsible for delivery to the intended recipient, you are hereby notified that disclosure of contents in any manner is strictly prohibited.
I have several issues with such disclaimers. First, their language suggests they are strictly specific to that particular email, even as they are unclear as to exactly what text they are referring to, particularly if the message is forwarded, which is presumably the only context these disclaimers are intended for. The body of text is ambiguous because email text is easily manipulable and most mail clients do not display the header, thus the content is not clearly demarcated. Indeed, RFC 2822 does not specify any terminating fields for email, thus if we stacked two emails, the only thing telling us one has ended is that the next one's beginning. Even as these disclaimers apply only to the vague instance, they often explicitly limit themselves to a particular jurisdiction, usually the US federal jurisdiction. The American geneticist counseling Saudi parents about the pre-conception risk of hemolytic anemia is either out of luck or sending meaningless drivel. Tangentially, I am not opposed to the fact that these disclaimers are spread virally, that is, people apparently copy-and-paste them from other people, but the parochial and instance-oriented verbage, however verbose, has stifled explicit, intelligent debate about what should be in the postscript, if anything at all.
Third, these disclaimers leave the appearance that one can send plaintext email with an expectation of privacy, which is not true. First and foremost, email is transmitted in the clear. The only way to protect information is to hash it before pressing send. People tend to muddle the assumption that their messages reliably get to the intended recipients with an entirely different possibility that their messages may get to unintended recipients. Indeed, email is relatively reliable at getting the message across because it can be sent to intermediate servers.The recipient may also, unbeknownst to you, have set up their account to forward to another account. Wireless devices that offer e-mail without true web-browsing are also essentially forwarding. The information goes to the service-provider's server before arriving at your phone/blackberry/Treo/Gizmo-of-the-day. The sender cannot know in advance which servers any given message will go to, and the recipient can only guess based on what's in the header.
Fourth, these postscripts are about as binding as a wet noodle. They're bluffs. We're daring clever people, or not so clever people, to compromise our integrity.
Finally, these disclaimers create a culture of fear, which leads to more irrational assumptions, in part because these disclaimers fail to provide a solution to the growing problem that people — patients, policy makers, other providers — assume healthcare providers do utilize the affordances of electronic collaboration. Not insignificantly, this culture of postscript disclaimers has failed to include solutions to the problem. This is a failure that needs to be corrected.
There is, of course, a solution. It's called encryption. PGP encryption to be precise. Indeed, the technical standards of HIPAA's security rule require the use of encryption, such as PGP, for electronic communication of protected health information over open networks. Here's a list of links to start learning about pgp. The PGP literature in fact mainly addresses the primitive encryption algorithms which actually underlie the implementation of most modern secure communications, including SSH, TSL, SSL, PKI, VPN (Virtual Private Networking, used for those Internet robo-surgeries), etc, etc. Cryptographers mainly work on primitive algorithms; hackers, aka software engineers, develop implementations of those algorithms. It just so happens that the PGP literature seems to be particularly readable. PGP encryption also very nicely solves the problem of demarcating which message the postscript refers to. Change a single character and the hash is broken. GnuPG is a very popular, free, open-source PGP project. It is worth noting that encryption, being an academic mathematical sort of thing, is actually made more secure by being open source because it is subject to peer review.
New tools make PGP free and a click away:
- For Windows
- WinPT manages your keyrings and it can encrypt files (like an excel spreadsheet) and the contents of your clipboard (copy-encrypt-paste)
- Once that's installed, you can add FireGPG, which integrates this functionality into Firefox, making it absurdly easy to encrypt in any web-based email application. It even provides buttons in Gmail
- For Mac
- Mac Gnu Privacy Guard manages your keyrings and provides several additional tools, all in usual, good Mac taste.
- Once that's installed, you can add FireGPG, which integrates this functionality into Firefox, making it absurdly easy to encrypt in any web-based email application. It even provides buttons in Gmail
- For Linux
Here's a public key let's say it belongs to somebody named John:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP Key Server 0.9.6
mQGiBEAg6gMRBAC8gDTmEfOghtVTorxdPYorRQyqzb2qXdwEwvqR6yk1kFIKzMJO
lRtv8gDIDRP7dKYlML7eVrMa4K/4eaxfPoAqqHhiQAn1jqDOdiVA4qhZUgge7uAN
Vo7rExuPC1T6ktptMNsa3ELzluvcVCsMTG9pdDOfH1LV/sSAv2MvW+6WbwCgm54Q
T8oKneghymgagi1wdIxtKNcD/Rlm2s/kKUMyAmdPfJTpxhJmiCeWEOQiPS0V7WgV
+aVQpFWcXYlrnoL5bBw4jy5NzSNojumAzYXm1/p2+zZ192Z/bf6tiOOR5kTXPiBM
PefQDG3/ZNFzsU8oK0PXTW20dU3cY/V+4GmNv3mi9irpQfT4h+qUO/XvPkTSmcAw
exTkA/0Zvcchjf6+8cm9vdX0X1tB495b4VA6gWpgF012UP4AmtjJeIZFBbLkn2F/
y3+jZNRWrtus0qCA1gKlVfrTA6vvtHlXwwivocGqlw28m0dw/KlO6ZsAfg1Juduv
AgMDFgIBAh4BAheAAAoJEOtJEPqfyZ2Th9wAnRPiND9kRns1rqtm8SFYggVHQJYN
AJ405Q60dKCVJmhTNqznZFOHcL4LXLkBDQRAIOoFEAQAktPKMTYYfuYXI64HdL83
bO5/mDjE9AWm46MzRFiqGOlou+UC4y5n59n1FNR8A0dSX1m+OAqNerZk9L4rU1+u
Okeo+0YLKII3S2xWmG9FZRiLFYh1DrTqLxYhZQ+abfM3I+1HldwFsy7e6QIpepBX
rMzpAiwxJfJLACT3t6BAOj8AAwUD/iJIiv2OlZHa2GwjHNeZf5RRRiLGfOD4SIGW
Wl2l61OCvcCfnjyA3oJOVhf3YzmNn6UHiJITEyKbV2LZrfWHO6pvSEXeDTggUmvp
kTcxeWzkzEbhq7BgFTI5GLmm7t4ssPtTXWJMkxzNXC3wYaqkZM9oTtTTZhtsW8Y6
3SjWAj5/iEYEGBECAAYFAkAg6gUACgkQ60kQ+p/JnZPNzQCghKKD0wS2io4voR74
lyU25MrHaJUAn3SAMAPCXaYGqusqX3RXQjlS7XM5
=2wUi
-----END PGP PUBLIC KEY BLOCK-----
Here's a message:
Hello, John,Mary Ann's blood sugar is stable now that she's using a pump. Where do you want her A1C?
Niels
Below is that message hashed with John's public key. This is what would be in my sent mail, this is what would be on the servers, this is what would be on John's computer. When John gets the message, he hits the button 'decrypt', enters his passphrase and a new window pops up with the message in it. As soon as he closes the window, the information disappears. If someone stole John's computer, the thieves would see the hash. Even if they had his public key, they couldn't figure it out. It's a one-way hash. That's what so cool about public key encryption. They would have to use his private key to decrypt it, and even then they'd have to guess his passphrase. If they had his passphrase and didn't have his private key, they're still out of luck. Gotta have all the pieces.
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: http://firegpg.tuxfamily.org
hQEOA9t60JOpttkXEAP/dMshitT2Xb8VtiDsV5o1tULXIHNSd6KQFU4CAeneDIp1
cNPqI6SEnRGkKEukiVjkm8HWYIzgltXi0/PlYBs09jjcrcfqWYUDp1ncM4DyWGUF
npG5MW/BVr4WQ/aHMG7qSzIu6CeeHu97QMUEp2c3LtL9Lc2fuhFBt1H29QwBi+YD
/3M1DYwRqy9//307BrsWtdjier7R9l2OZhD+9Hu2HWrQ2T6zo9lScmr3GIP8OWVL
Inl5Wgjt1hbJHK/8FtI/8lgt4n9RI5Mk+ZPSVdBvsQjGnT9xPbRcMQO6cmoOodCN
K6mt6GgXpgfLm1bQEZCLidkp3bsjB+kyt2wwtXESQxAQ0q4BEy89xkiLl+i0tIFk
zqtdI3e1J6Oq3KaDfckOn3VTgZ1jlzqO1jXilbOhn10VCzJntYtxYf1zs2qkchQJ
VuxV6a7tAubg2n8JCeelFoAiEyvzsCyzdX6ADzh9ONUy278WQYoUHTx6MaaV4XDy
MRD+Iv606s2IGxtVpO46Js378ww2R8UUfEAiIu+Qmw5KXtd6KHP5KpQxgd0keXTe
Z/C4RrJv2Ja6kuQ0WZVzuCw=
=4xKW
-----END PGP MESSAGE-----
What John sees after he decrypts and enters his passphrase, until he closes it:
You can have any combinaton of features the Air Ministry desires, so long as you do not also require that the resulting airplaine fly. —Willy Messerschmidt.
As much as I would like to say that PGP offers all the affordances of face-to-face speech, and all the affordances of the hand-written note, and all the affordances of every form of communication ever conceived, it doesn't. First and foremost, the machine must render your message indecipherable to everyone but the person you trust to decipher it. Security is the primary affordance. So, a word about the logistics of encryption: it's up to you to make it possible for other people to send you secure information. When a CIA agent goes out in the world to get her spy thing on, Langley provides her a way of sending secure messages back to the home office. That doesn't mean Langley can contact her. When we send jets up off an aircraft carrier, the crypto has to be in the plane before it takes off. If you want people to send you secure email, you have to provide them a public key first. It also means you can't send a secure message to someone unless they provide you a public key.
But Niels, servers send me encrypted information all the time when I make online purchases. True. But first you initiate the session, which is the point at which your browser quietly provides the server with a public key that is valid for that session, and the server quietly provides your browser a public key that's valid for that session. This works because you're interacting in real time. Email is asynchronous. You send information long before someone else reads it. So the public keys have to be available for long periods of time and they have to be long. Your https session with Amazon.com might be 128-bit encryption. Your PGP key will be at least 768 bits, most people start at 1024 bits, and 4096-bit encryption is not uncommon. The size of the key makes little difference to legitimate people (the processing time is negligible) but long keys are big problems for attackers. Read the PGP Attack FAQ and the DH vs RSA FAQ for some estimates of how many decades it would take for a million computers to crack a 2048-bit PGP key. If you continue to think there's another way to skin the cat that doesn't require individuals taking responsibility for their own encryption, I recommend this freeBSD thread driven by a network administrator trying to implement HIPAA security for an organization of 28,000 people. I feel I should say something about local security: your organization can provide you all the smart cards, RFID tags, and biometric scanning in the world, that still only controls machine-level access, at best the network administrators can add that identifying data in the LDAP directory and then they can use it across the local "closed" network (few networks are truly closed). That doesn't solve the open network, internet (internetwork) problem. Even on the local network, say, a university network, recall from the first part of this article that it's unlikely you'll know in advance the route your message will take to all your recipients; that's a very real security seam unless your recipients provide you a PGP key.
Of the three postscripts I quoted at the beginning, I think the third is the best because at least it's not parochial. I think we can do better and we need to do better. Like I said, I'm not opposed to the viral spread of these postscripts. In fact, that's why I'm writing this. Using the sample text below, I started the Wikipedia article HIPAA compliant email postscript in the hopes of developing a community standard. Your edits there would be greatly appreciated. Get PGP and use it. Publish a public key on the keyservers. You may not need it today. You may not need it tomorrow. But some day, somebody is going to need to tell you something. Some day, you're going to need to tell somebody something. Get the Wikipedia postscript, or one like it, that points the way to better patient privacy. Spread the word.
First Name Last Name
Organization
example@example.com
w xxx.xxx.xxxx
p xxx.xxx.xxxx
c xxx.xxx.xxxx
http://example.com
This message contains private information for the person named above. Others are prohibited from disclosing the information to anyone else. If you received this message without a PGP wrapper, assume it was compromised, delete it, tell the sender and try to tell the person named. Do not send someone else's private information if you're not reasonably certain the recipient has a need to know and that the message will be kept private. Plain email is not private. In some cases, such as health information protected under the Health Insurance Portability and Accountability Act or information protected under the Privacy Act, plain email may be illegal. If you must relate a person's identity to their private information in email, insist your recipients provide you a PGP public key. You can get my public key from the keyservers or my webpage.
