RealSecurity

In early August I wrote a short piece on the HITECH Act that is part of the American Recovery and Reinvestment Act (ARRA) of 2009. Granted, it was a bit tongue –in-cheek, so I wanted to write something that really boils down the act into salient points that will actually help people within the realm of information security.

Although HITECH contains a great deal of information, it really comes down to a law concerning breach notifications and fines related to breaches. Of course, from this point it begins to spread out concerning who, what, and how these manifest, which is why HITECH has become of great interest.

HIPAA (45 CFR 160.103) defines covered entities and business associates. However, it is HITECH that adds a new requirement and states clearly in section 13402 that business associates must meet the security provisions of 45 CFR part 164, the security and privacy part of HIPAA, specifically sections 164.308 (administrative safeguards), 164.310 (physical safeguards), 164.312 (technical safeguards) and 164.316 (policy and procedures and documentation requirements). In short, this means that business associates of covered entities will be required to be compliant with the security and privacy core elements of HIPAA.

Now that covered entities and their business associates have to be compliant, this begins to set the scope of who is responsible for the security and protection of private information. There are various definitions from HIPAA and HITECH encompassing Personal Health Record (PHR) defined in section 13407 of HITECH, Protected Health Information (PHI) defined in HIPAA (45 CFR 160.103), and Electronic Health Record defined in 13400 in HITECH. In short, HIPAA defines “the” information and HITECH goes on to quantify this further as electronic information and associates with access (among other details) to personal health record (PerHR). Nevertheless, when in doubt, anything HIPAA defines as PHI is the foundation of information in any form or structure.

With regards to disclosure of PHI and the applicability to breach notification and all this implies, is founded on “unauthorized” access. This is specifically defined in section 13400 in HITECH definitions as part of the definition of a breach:

“The term ‘breach’ means the unauthorized acquisition, access, use, or disclosure of protected health information which compromises the security, privacy, or integrity of protected health information maintained by or on behalf of a person. Such term does not include any or privacy of such information, except where an unauthorized person to whom such information is disclosed would not reasonably have been able to retain such information.”

There are a few important points to make with this definition. First, “unauthorized” is as one would expect. Therefore, if an authorized user (employee) exposes private information in performing their duties, this is not a beach. Of course, there are additional provisions I’ll discuss shortly. Another point is the terms “security, privacy, or integrity of PHI…” referring to the characteristics attributed an unauthorized breach. The term privacy is technically easy; PHI is private information and should only be made available to those who have been authorized. Also, integrity is easy; any unauthorized changes to the data. However, the term “security” is far more ambiguous and I personally think this is used in an attempt to convey the spirit of the law. Without the term there is simply too finite of a scope in definition.

As for the additional provisions they are your typical legalese that everyone can understand. If there is an “unintentional acquisition, access, or use” that was in good faith of an employee (individual in a covered entity and/or business associate) this does not qualify as a breach as stated. Also, and important, that the information is not further acquired, accessed, used, or disclosed by such employee or agent. In other words, if an employee is operating in good faith and inadvertently exposes information this is not a breach, but if it goes farther, it becomes a breach. For example, an employee sends an e-mail containing PHI to the wrong address and it ends up on the web, that’s a breach.

What this all translates to is if information (PHI) is exposed by an authorized party performing their assigned duties related to their authority and in good faith, and that information does not go beyond (“further acquired, accessed, used, or disclosed”), it is not a breach. Therefore, this brings us back to “unauthorized” and of course the definition of authorized and how authorization materializes.

Interestingly, the quantification of “authorized” is not explicitly provided, and frankly nether is “unauthorized”. This is somewhat understandable because organizations affected by this regulation will have different operational demands that will resonate differently in who or what may or may not be authorized. However, a simple definition of authorized would have been appropriate because authorization (implied by “unauthorized” in definitions) is the root of the entire regulation.

Nevertheless, this leads me to another aspect of HITECH and that is guidance and audits from the government. Like many other regulations of this nature and of recent publication, there is an association with standards bodies, specifically NIST, who has received $20M so far in funding to create healthcare information technology (HIT) security standards. However, in this case, the Secretary – as defined by HITECH as the governing agent, will provide guidance on security and privacy controls. What this means is that omissions concerning acceptable security practices will be provided later by the government. Of course, I hope they simply reflect what NIST defines. A second element that is a bit rare in regulations is the fact that the Secretary will perform audits against HITECH affected organizations. I suspect this will be limited to public (government) entities, but there is nothing that states this as a limit. As an additional note, HITECH refers to ANSI, so this does not limit directives from NIST only.

As far as guidance, preempting the Secretary, DHHS published 45 CFR 160 and 164 guidance specifying technologies and methodologies that render PHI unusable, unreadable, or indecipherable to unauthorized individuals for purposes of the breach notification requirements in 13402 in HITECH on April 27, 2009. It’s basically, DHHS providing guidance concerning HIPAA compliance in the face of a new regulation. Of course, this makes sense, but I begin to wonder if this guidance will be applicable over the long-term related to directives on acceptable controls from the Secretary and NIST. Only time will tell. Nevertheless, in HITECH does delve into the concept by way of “unusable, unreadable, or indecipherable” in section 13402, Notification in the Case of a Breach with regards to defining (13402.h) Unsecured Protected Healthcare Information (specifically, 13402.h.1.B). Actually, in 13402.h.1.A it states:

“Subject to subparagraph (B), for purposes of this section, the term ‘unsecured protected health information’ means protected health information that is not secured through the use of a technology or methodology specified by the Secretary in the guidance issued under paragraph (2).”

Here we’re introduced to the guidance from the Secretary on what controls are acceptable and then refers to paragraph (2), which states that the Secretary will provide guidance no later than 60 days after the enactment of the act and update annually. I will add that I’ve looked (admittedly not extensively) for this guidance assuming that the enactment date was in February to no avail, but have concluded that the related date is either September 2009 or will be February 2010 – I suspect the latter. It goes on to add:

“In the case that the Secretary does not issue guidance under paragraph (2) by the date specified in such paragraph, for purposes of this section, the term ‘unsecured protected health information’ shall mean protected health information that is not secured by a technology standard that renders protected health information unusable, unreadable, or indecipherable to unauthorized individuals and is developed or endorsed by a standards developing organization that is accredited by the American National Standards Institute.”

Now, this implies, and would make sense, that data encryption is the core technology to be employed. This brings us back to the DHHS guidance, which aptly refers to this statement in title, which specifically introduces encryption. Keep in mind that the term “encryption” does not appear in HITECH. In the five page document from DHHS, specifically page three, title II, DHHS begins to articulate potential technologies and methodologies. First, in HITECH the applicability of controls related to information is articulated as “access, maintain, retain, modify, record, store, destroy, or otherwise hold, use, or disclose”. Under typical security scenarios these are rendered as “store, transmit, and process” as seen with PCI. Therefore, DHHS’s guidance defines these states as “data in motion”, “data at rest”, “data in use”, and “data disposed” and goes on to refer to NIST on encryption guidance for one or more of these states (with the exception of data in use, for obvious reasons). Then a telling statement:

“Encryption is one method of rendering electronic PHI unusable, unreadable, or indecipherable to unauthorized persons. The successful use of encryption depends upon two main features: The strength of the encryption algorithm and the security of the decryption key or process. The specification of encryption methods in this guidance includes the condition that the processes or keys that might enable decryption have not been breached.”

Therefore, not only is encryption a meaningful solution, but – and s all security professionals are aware – the security of the key management system is paramount. This comment from DHHS almost suggest that keys are equivalent to PHI within the context of security, which technically speaking is accurate if encryption is used to secure PHI from unauthorized access and authorization is related to keys. Later, on page 4, the guidance provides section “B”, specific technology guidance, that states that PHI is rendered unusable, unreadable, or indecipherable if one or more of the following applies:

“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.” And refers to NIST CSRC SP800-111, 52, 77, and 113, and FIPS-140-2.

The other applicable element is related to media, such as the media that stored or recorded PHI has been shredded or destroyed. For paper, film, or other hard copy it must be shredded to a point where it cannot be reconstructed. And for electronic media it must be consistent with NIST SP800-88, Guidelines for Media Sanitization.

Here is basically what all this is saying:

• Unauthorized access is the crux of the breach notification,
• PHI must be secured from unauthorized access,
• To secure PHI from unauthorized is must be rendered unusable, unreadable, or indecipherable, meaning encrypted (or effectively destroyed), which includes data in motion and data in storage, for the most part, and
• Keys and processes related to encryption should be treated with the same protection as one would to PHI.

How this could be translated is that anywhere you have PHI it should be encrypted and keys provided to only those who are authorized. This does not eliminate meaningful access controls, system controls, application controls, user management, and other security features, which are all defined as part of HIPAA. But, once you address HIPAA, one could argue that HITECH is about encrypting data. Interestingly, this is also addressed in HIPAA, but HITECH ties this all to breach identification and notification – which is the root of the regulation. Basically, and in very oversimplified terms, it can be said that HITECH is an amendment to HIPAA focused on notification of breaches, which are defined as unauthorized access to PHI. To control this, encryption of data it the predominate control that will satisfy the securing of data that is rendering it unusable, unreadable, or indecipherable.

Of course, there is a lot more and much of it I covered in Part 1 of this article. Things such as fines, having to restructure contracts with business associates, notification processes, the fact that the Secretary has amazing control, reporting to congress, and apparently the government is going to perform audits. There is a ton of stuff there.

But what does it all boil down to? Well, a lot of companies that were not held to HIPAA are now going to have to be compliant and this is an enormous situation. Just think of the implications for services providers and the cloud. All of a sudden that healthcare SaaS requires that the provider be HIPAA compliant. That’s the really big part and I plan to write an entry on what these companies can do and what to look out for. Then of course all the notification processes and related fines, which can be substantial and open to interpretation. Not to mention that when a breach is reported there is no hiding the fact – everyone will have all the details via the web. Then the definition of “authority” may challenge some. This will have to be documented carefully. Just stating that all employees have authority to access, acquire, process, use, etc. PHI may not stand up under pressure, but if it’s true, then it’s true. Lastly, there is encryption. There are a vast array of options for you to accomplish this, especially with regards to data in motion – that problem was solved and standardized a decade ago. But data at rest… that one is remains a challenge in certain areas and will likely dramatically change the cloud moving forward, among other things. Endpoint encryption was gaining momentum in the market – a lot of companies are implementing it. Now with HITECH, I suspect that market will expand rapidly and you’ll have more options and solutions put in front of you that can be counted. When this happens, focus on performance, key management, compatibility, administrative capabilities, reporting, granularity (i.e. multi-user systems), cost, and, of course, that it’s using a standard algorithm.

All in all, this will be challenging for many organizations, but certainly not insurmountable. I will add that encryption is not the only solution; there are other security controls that can be used to effectively control access. But in this case, if you could find a silver bullet scenario, which doesn’t exist, the closest thing is encryption, I have to admit.

I plan to write more about this over time, so check back often.