Should HIPAA be overhauled? Anthem data breach raises alarm for privacy advocatesMaybe Congress can take a wee bit of time out from its umpty-dozenth Quixotic attempt to "Repeal ObamaCare" and amend HIPAA to require "Encryption at Rest."
By Dan Taylor, National Monitor | February 07, 2015
HIPAA, which was passed in the 1990s before the Internet was commonplace, does not require data to be encrypted, which could have prevented the release of information of 80 million people in Anthem’s database.
Insurers have no requirement to encrypt the data of its consumers as part of a federal law from the 1990s — which may mean the law could be in need of some updating for the Internet age after a recent massive data breach of Anthem, the second-largest U.S. health insurer.
Encryption protects data by scrambling it using mathematical formulas, so that anyone who does get their hands on it will not be able to figure out what it says. However, the data of 80 million people that was stolen from Anthem’s database was not encrypted, according to an Associated Press report.
The federal law in question is the well-known Health Insurance Portability and Accountability Act, or HIPAA. While the law encourages encryption, it stops short of mandating it.
This latest data breach could cause the public to lose confidence in the ability of the government to protect data even as it increases the computerization of medical records and tries to increase electronic information sharing among hospitals.
David Kibbe, CEO of nonprofit advocacy group DirecTrust, was quoted in the report as saying that maybe it’s time to update HIPAA.
Kibbe argued that any data that identifies the patient should be encrypted, and that it should make no difference whether that information is transmitted over the Internet or is simply sitting in a company database — the latter being the case with Anthem.
The incident has gotten the attention of federal lawmakers, as the Senate Health, Education, Labor and Pensions committee will take a look at encryption requirements as part of a review of health information security.
Nahhh... "Onerous Regulation" and all that.
ePHI Security is governed in part by 45.CFR 164.312:
§164.312 Technical safeguards.Emphases mine. The author cited above is correct. There are presently neither federal statutory nor regulatory requirements to encrypt ePHI. Here's essentially all you will find in the new Final Rule.
A covered entity or business associate must, in accordance with §164.306:
(a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in §164.308(a)(4).
(2) Implementation specifications:
(i) Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.
(ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
(iii) Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
(b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
(c)(1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
(2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
(d) Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
(e)(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
(2) Implementation specifications:
(i) Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
(ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
[68 FR 8376, Feb. 20, 2003, as amended at 78 FR 5694, Jan. 25, 2013]
HIPAA Omnibus Final Rule, pg 5644 Federal Register / Vol. 78, No. 17 / Friday, January 25, 2013 / Rules and RegulationsPer 45 CFR 164.3 et seq, it should be noted, in fairness, that "addressable" does not mean "optional" -- just that the CE or BA claiming subclause forbearance must show to the satisfaction of HIPAA auditors that its Policies and Procedures suffice to meet the ends of ePHI protection, in this case breach protection so effective that encryption is not necessary.
We encourage covered entities and business associates to take advantage of the safe harbor provision of the breach notification rule by encrypting limited data sets and other protected health information pursuant to the Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (74 FR 42740, 42742). If protected health information is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information.
Worked out really swell for Anthem here, 'eh?
Also noteworthy here is that states have differing laws and regulations pertaining to privacy, security, and encryption -- important because unlike other areas of federal law ("federal supremacy"), HIPAA is trumped by stricter state laws. I don't have an up-to-date tabulation of those requirements. You'd have to have a WestLaw account via which to search out that kind of detail.
Interestingly, as it relates to my prior post Yet another ONC Interoperability "Roadmap," keyword-search the 166 page ONC Interoperability report for "encrypt" or "encryption."
UPDATE: OK, COMES A COUNTERVAILING VIEW
When my friend Fred Trotter speaks, one has to listen.
It is fine to be outraged at Anthem and I am sure they could have done more, but I can assure you that no insurance company or hospital in the United States is prepared to defend against nation-state level attacks on our infrastructure. In fact, Anthem is to be applauded for detecting and cutting off the attack that it did find. Hackers are much like roaches, if you can spot one, there are likely dozens more successfully hiding in the walls.From "Anthem was right not to encrypt" on THCB. More...
Encryption is a mechanism that ensures that data is useless without a key, much in the same way that your care is made useless without a car key. Given this analogy, what has apparently happened to Anthem is the security equivalent to a car-jacking.
When someone uses a gun to threaten a person into handing over both the car and the car keys needed to make that care [sic] useless, no one says “well that car manufacturer needs to invest in more secure keys”.While I have been aware that encryption is not without its own problems (e.g., overhead bandwidth burden, and potential errors associated with extra process steps), Fred brings a new vector of thought to the issue.
In general, systems that rely on keys to protect assets are useless once the bad guy gets ahold of the keys. Apparently, whoever hacked Anthem was able to crack the system open enough to gain “programmer access”. Without knowing precisely what that means, it is fair to assume that even in a given system implementing “encryption-at-rest”, the programmers have the keys. Typically it is the programmer that hands out the keys...
You see encryption at rest, unlike encryption in transit, comes with significant risks. The first risk is that keys might be lost. Unlike car keys, once encryption keys are lost there is no way to “make new ones”. Of course you could backup your keys, securely, off-site, but that is extra costs, extra steps. Second, if encrypted data becomes corrupted, it is much more difficult to recover than unencrypted data.
In short, there are cases where encryption-at-rest can be dangerous and there are only a few cases where it can be helpful...
So, really the onus is back on breach prevention, in Fred's view, given that encryption perhaps gives us a false sense of security. Recall that this goes to the heart of 45 CFR 164.402(2)(iv) (breach notification requirements):
(iv) The extent to which the risk to the protected health information has been mitigated."rendered unusable, unreadable, or indecipherable to unauthorized persons," that is the crux, according to Fred. If the Bad Guys get the keys as well as the data, well, point taken. You'd rightfully have to demonstrate that you'd not handed over the keys to be off the hook for breach notification (and all the litigation and punitive regulatory enforcement that might ensue). But, if the Anthem data were unencrypted when filched, then they are usable by the crooks straight away.
Unsecured protected health information means protected health information that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Public Law 111-5.
Not everyone in THCB comments is amused by Fred's argument:
Fred’s post is misleading in the extreme. The Business of Medicine needs to be held accountable for their practices. Laying the Anthem breach at the feet of the NSA is equivalent to wishing for a police state. A public interest perspective to what’s going on comes to a very different conclusion. There are at least three things Anthem can be held accountable for: encryption, minimization, and persistence.
First, data encryption can be done securely for a bit more money. The keys are kept separate from the data and fetched as needed. In this case, an excess 80 million fetches of the keys would have been noticed earlier, wouldn’t you think? Also, I would like an email from Anthem each time the keys to my data are fetched. How hard would that be? Ahh, but what about the expense? Our US private insurance system has 3X the administrative cost of single-payer. Maybe we need to increase that to 4X so they can afford encryption and accounting for disclosures? Or maybe we should save all that money and let NSA handle the whole thing.
Second, how much data does Anthem need about me? Do they really need my social security number? Why can’t Anthem give me an Anthem ID to use? If a service provider wants to get paid, they need to supply my Anthem ID number, period. Much of the Business of Medicine is still paving the cow path of our paper-based history. I’m old enough to remember the little books of tiny credit card numbers that merchants would be required to check prior to accepting payment. That was before everything got connected. Today, I can buy a cup of coffee with a debit card and the back responds in a second. Why can’t healthcare payments that average 100X that amount be made without reference to my SSN and other personal info?
Third, how long does Anthem need to keep a copy of my data. An hour, a day, three months, three years, forever? The answer obviously depends but in an age when storage cost is effectively Zero relative to my $10,000 health insurance bill, what keeps Anthem and every other actor in the Business of Medicine from storing all of my private data forever?
Privacy comes at a cost. When VIPs go to the hospital or the pharmacy their information isn’t treated the same way as mine. The Anthem breach is a teachable moment for how we’re paying for the most intimate and important information we have. This is not a time to be letting the Business of Medicine and our regulators off the hook.I have some personal interest in this dustup. We are not Anthem customers, but, nonetheless, my wife's company notified everyone that if we engage providers who take Anthem insurance, we may have been caught up in the hack.
More to come...