HHS Provides Guidance on Protecting PHI
When you see a document with a title such as
Guidance Specifying the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements under Section 13402 of Title XIII (Health Information Technology for Economic and Clinical Health Act) of the American Recovery and Reinvestment Act of 2009; Request for Information, you know our tax dollars are hard at work.
This document is, in fact, the work of the U.S. Department of Health and Human Services. It is intended to meet the requirements of one of the provisions of the HITECH portion of the ARRA stimulus package, by providing guidance on exactly what constitutes "secure" as opposed to "unsecure" protected health information (PHI) as it relates to possible breaches of such PHI by covered entities or business associates as defined by HIPAA and HITECH. Since medical transcription services and independent contractors are now classified as business associates by HITECH, this is information we definitely need to know.
The Guidance is rather lengthy, but here are a couple of the salient points:
- PHI should be encrypted in order to be secure.
- If "secure" PHI is breached, the notification requirements under HITECH are waived.
On the first subject, the Guidance has this to say:
Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals only if one or more of the following applies:
a) Electronic PHI has been encrypted as specified in the HIPAA Security Rule by "the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key" and such confidential process or key that might enable decryption has not been breached. Encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.
i) Valid encryption processes for data at rest are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.
ii) Valid encryption processes for data in motion are those that comply with the requirements of Federal Information Processing Standards (FIPS) 140-2. These include, as appropriate, standards described in NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, and may include others which are FIPS 140-2 validated.
b) The media on which the PHI is stored or recorded has been destroyed in one of the following ways:
i) Paper, film, or other hard copy media have been shredded or destroyed such that the PHI cannot be read or otherwise cannot be reconstructed.
ii) Electronic media have been cleared, purged, or destroyed consistent with NIST Special Publication 800-88, Guidelines for Media Sanitization, such that the PHI cannot be retrieved.
I don't pretend to be a HIPAA expert by any means, but what I get out of all of this is that in order to secure PHI, data MUST be encrypted, as opposed to the original HIPAA regulations which said data COULD be encrypted as one possible option. As far as I can gather, neither the HHS Guidance nor the NIST guide mention specific encryption tools/programs that meet the requirements, so once again, it's up to us to do the due diligence to make sure the tools we use to protect PHI are adequate.
In doing so, it's important to keep in mind all the various states in which data can exist. From the HHS Guidance:
"data in motion" (i.e., data that is moving through a network, including wireless transmission); "data at rest" (i.e., data that resides in databases, file systems, and other structured storage methods); "data in use" (i.e., data in the process of being created, retrieved, updated, or deleted); or "data disposed" (e.g., discarded paper records or recycled electronic media). PHI in each of these data states (with the possible exception of "data in use") may be secured using one or more methods.
What this means in practical terms is that data residing on your local hard drive may need to be protected differently than data which is in the process of being transmitted over the Internet, which in turn may need to be protected differently than data residing on a server somewhere on the Internet awaiting download by another party. For example, FTP applications which use SSL to encrypt files during transmission over the Internet generally do not protect files while they reside on the remote FTP server, and thus would not meet the criteria for securing PHI unless the files themselves were encrypted separately.
The second issue of interest to me in the HHS Guidance is in regards to the notification requirements of HITECH. From the HHS Guidance:
If PHI is rendered unusable, unreadable, or indecipherable to unauthorized individuals by one or more of the methods identified in this guidance, then such information is not "unsecured" PHI. Thus, because the breach notification requirements apply only to breaches of unsecured PHI, this guidance provides the means by which covered entities and their business associates are to determine whether a breach has occurred to which the notification obligations under the Act and its implementing regulations apply.
While covered entities and business associates are not required to follow the guidance, the specified technologies and methodologies, if used, create the functional equivalent of a safe harbor, and thus, result in covered entities and business associates not being required to provide the notification otherwise required by section 13402 in the event of a breach. However, while adherence to this guidance may result in covered entities and business associates not being required to provide the notifications in the event of a breach, covered entities and business associates still must comply with all other federal and state statutory and regulatory obligations that may apply following a breach of PHI, such as state breach notification requirements, if applicable, as well as the obligation on covered entities at 45 CFR 164.530(f) of the HIPAA Privacy Rule to mitigate, to the extent practicable, any harmful effect that is known to the covered entity as a result of a breach of PHI by the covered entity or business associate.
What this says to me is that as long as you properly use encryption to protect PHI at all stages of its lifecycle, if a breach does occur, you're not required to notify either the government or the individual whose PHI was breached. Furthermore, according to my reading of the Guidance, it's up to you to determine whether or not you properly protected PHI, and thus whether or not notification is required.
Quite frankly, this Guidance leaves somewhat to be desired, in my opinion, in terms of concrete guidelines for specific situations. In fact, the Guidance itself also includes a Request for Information, meaning, I suppose, that HHS could change its mind after gathering input from stakeholders. However, this is more than we had when ARRA/HITECH was first enacted, so I guess that's progress for our legislative system.