[ Wednesday, August 27, 2003 ]
Encryption:
[warning: read the update below. If you're techie enough to, say, set the clock on a VCR, then you should know more about this than me and should recognize that this isn't nearly perfect encryption and is really only good to protect against non-intentional improper recipients (as opposed to those who are actually trying to improperly access PHI). If you're not techie enough to set a VCR clock, then you really need to check out encryption with someone in your organization who has the knowledge to help you to make the decisions on whether to, and how to, encrypt.]
As you know, encryption is an "addressable" implementation specification under the Security portion of HIPAA. That is, you don't have to encrypt the PHI you store and transmit, but you do have to address whether it would be appropriate and make your determination to encrypt or not encrypt.
As you also know, sending information over the internet is fraught with peril. It gets broken into packets which might be meaningless if intercepted, but it is certainly possible that someone could intercept the information in a useful form. Not likely, but possible. And you don't want to be the test case if it were to happen to you.
I learned from Jeff Pounds yesterday that there is an easy way to encrypt information: use zipped files. A zipping program (like WinZip) takes an existing file or document and compresses the information in it by using some sort of algorithm. The file can be "unzipped" and restored to its original state by reversing the algorithm. While compressed, the file is basically meaningless unless you know the algorithm. The way you can use a zipping program is to zip the file and send it as an attachment to an e-mail, and send the algorithm in a separate e-mail. Nobody would be able to unzip the file if they intercepted it, unless they intercepted both the file and the algorithm key.
Of course, if you send the information to the wrong location; if someone improperly accesses the mailbox where you sent the file and the key; or if the disclosure is improper in the first place, encryption won't help you. But if the disclosure is proper, the recipient is authenticated, and the recipient's mailbox is secure, "zipping" might be a good encryption strategy where you need it.
Disclaimer: I'm going on what Jeff Pounds told me. I'm not techie enough to know if this will work or how, but it sounded good to me. You should be able to find "winzip" or similar zip programs online for free or at low cost. Do a "google" or "yahoo" search for winzip, or go
here for share-ware. Finally, check with your tech folks before you download this or any other software, and make sure you run it through a virus scanning program like MacAfee or Norton to make sure you aren't loading the SoBig virus as well.
UPDATE:
I heard from a reader, Norman Harman, that indicates that Jeff Pounds might be overselling the use of zip programs as encryption. He makes a few technical points (my algorithm description is inartful: I mean the key, which I believe is the application of the algorithm (or its reverse, I would think) to the compressed file to decompress it), and acknowledges that if the compression program is used with a "password protection" feature, it might provide some security. Obviously, I don't know too much about this, but it seems that there is an algorithm for encrypting, PLUS a key for decoding, although for the life of me I cannot understand how the key and the algorithm are unconnected (how does the key know what to unlock if it's not related to the lock?). Norman says there are just a few compression algorithms; I assume that he also means that there are a larger number of keys, so that if the password or key is protected, there might still be some encryptive value in compression with password protection (if I understand myself, and I'm not sure I do, the algorithm is pretty easily descernable -- there are only a few of them -- but you need the password as well, and there are lots of them).
Norman makes a few other good points, too (and I'm sure he'll re-email me and set me further straight on the algorithm/key issue above). First is that if you send by separate e-mails the encrypted document and the ability to decrypt it, there is a strong likelihood that the person who captures the first e-mail will capture the second. Yes, and no; if the interception is done because of how the e-mail passed over the internet (it was routed through a server where a bad guy could snatch it), it is likely that the next e-mail will travel over a different route (unless the server where it was captured is the server where the sending or receiving e-mail resides). If it was captured by someone who had improper access to the recipient's or sender's e-mail account, obviously any type of password of key sent to or from those accounts would be subject to theft as well. If the password is short enough or simple enough to be sent by telephone, that would obviously help to solve that problem (noting, of course, that the sender or recipient might be overheard, might write the password on a post-it note and leave it around, or might otherwise disclose it, thereby screwing the whole pooch). (yes, that's a legal phrase)
Remember, however, that you need to make a determination about whether you need to encrypt in the first place (it is an addressable, rather than a required, implementation specification under the Security Rule). Also, keep in mind that if you are sending PHI via e-mails and don't want to be bothered with encryption, you should de-identify it if possible.
Jeff [11:30 AM]
http://www.blogger.com/template-edit.g?blogID=3380636
Blogger: HIPAA Blog - Edit your Template
