As someone starting a new software development project, I have a keen interest in ensuring that my product does not create HIPAA headaches for users. Complying with the Security Rule’s technical safeguards seemed like a good start, so I decided to review their implementation specifications while developing security requirements.
The technical safeguards are covered in sections 164.312(a)-(e). They appear below.
|Access Control||Unique user identification – Assign a unique name and/or number for identifying and tracking user identity.
Emergency access procedure – Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
Automatic logoff – Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
Encryption and decryption – Implement a mechanism to encrypt and decrypt electronic protected health information.
|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.|
|Integrity||Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
Mechanism to authenticate electronic protected health information – Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
|Authentication||Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.|
|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.
(i) Integrity controls – Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
(ii) Encryption – Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
As can be seen, the implementation specifications are not very specific. Regrettably, this often leaves the matter of compliance open to interpretation. For example, the implementation specifications for the access control standard (unique user ID, automatic logoff, and emergency access) are straightforward and simple to implement. However, decryption and encryption requirements are more puzzling. What is to be encrypted/decrypted and when? Should protected health information (PHI) be encrypted while stored, or is it enough to provide encryption capability when it is moved from one place to another (e.g. over the network or when exchanged with outside entities)?
The integrity standard presents another conundrum. It requires that there be a mechanism to “… corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner…”, but offers no clue as to what is acceptable. Do database and operating system logs count toward meeting this requirement? What about the integrity features built into modern database management systems?
Because certified EHRs are required to meet technical safeguard requirements, I decided to look at EHR certification test procedures to see if they shed any light on what is required to meet implementation specifications. Unfortunately, the testing procedures are too simplistic to offer any useful insight. For example, the general encryption test procedure only requires that EHR vendors prove that an EHR is capable of encrypting and decrypting a data set. The procedure offers no hint as to what is expected in terms of the operational use of encryption features.
The integrity test procedures are no more helpful than the encryption tests. These procedures determine if an EHR is capable of generating, comparing, verifying, and exchanging hash values. However, as is the case with encryption capability, no clue is provided as to when these features should be available for operational use. One obvious use is covered in the test procedure–verifying that no alteration has taken place in a data set sent from one entity to another. Aside from this, no hint is given as to how this capability should be put to use in an EHR. I fail to see the value in proving a capability is present while ignoring how it might function in day-to-day use.
Given the modest nature of the certification requirements, it is difficult to see how any EHR could ever fail to measure up. On one hand, this is comforting because it makes certification a necessary, but easily dealt with, evil. On the other hand, it is disconcerting because certification standards provide little useful guidance to clinical software developers as to what is needed to meet HIPAA’s requirements in real-world settings.
Fortunately, as a developer, I can make use of the excellent information security resources provided by NIST to aid in formalizing security requirements. However, EHR purchasers may not fare as well. Since current certification testing does not utilize real-world scenarios, some unlucky EHR buyers may discover the quality of the technical safeguards built into their systems in the same way one learns the fate of Schrödinger’s cat. Sigh, poor cat.