Looking for best of breed HITECH / HIPAA compliance tracking software?
Introduction
Need a HITECH Business Associate Contract? Check out the HSG Store.
This page contains detail information related to HIPAA's Security Rule ("SR"), specifically detail related to the SR's Technical Safeguards ("TS") . The reference PDF file that corresponds to each individual graphic is "interactive" and can be downloaded for project use or other reference purposes (Windows OS). Each diagram corresponds to a list of action items and specific tasks related to the corresponding standard.
You can use the following NIST document: Implementing the HIPAA Security Rule as a road-map for an SR project plan. The diagrams below were built using this document as a reference. However, not all action items specified must be addressed. Remember, this is NIST's interpretation of what needs to be done and they had a specific audience in mind, government agencies that must comply with HIPAA.
That said, at a minimum, it does serve as a good checklist of action items for all providers and facilities. Ultimately, what needs to be complied with for the TS is section 164.312. We recommend that you be thorough in how you "attack" the SR, but do not lose sight of the forest for the trees. Common sense business judgments will need to be made throughout the compliance process and can be justified as long as you are not cavalier regarding your approach.
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).
Essentially items 1-9 represent a list of action items that a provider should perform in order to satisfy this standard, according to this NIST document (see Introduction for more information). As you can see from the list, these items contain both analysis deliverables and implementation deliverables. You can download the interactive Access Control PDF (Windows OS) to "explode" these activities into specific tasks.
Items three (3) and (7) correspond to required implementations; refer to section 164.312 for additional information. The bottom line regarding this standard is that you must develop a repeatable process for administering access control that assigns a unique identifier to each user and provides a mechanism for emergency access.
Finally, if you want to avoid breach notifications then you should treat item 8 (i.e. the encryption aspect) as required.You will need to work with your software partner to ensure that the implementation meets HHS' Interim Final Rule on Breach Notification.
2. 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.
Essentially audit controls have to do with process verification. The concept is once you implement a standard (or set of standards) how do ensure that the systemic behavior is consistent with the policy? The only way to do that is to have checkpoints in place that signal whether or not the desired results are being achieved. This NIST document (see Introduction for more information) contains a list of questions that you should be asking as you "crosswalk" each action item.You can download the interactive Audit Controls PDF (Windows OS) to "explode" these activities into specific tasks. The questions are only found in the NIST document.
3. Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
One of the issues with the Security Rule (see Subpart C), and in particular with the Technical Safeguards, is that there is often no clean line of demarcation between the standards. This NIST document's attempt at providing a roadmap is illustrative (see Implementing the HIPAA Security Rule). In short, despite the fact that there are high quality resources available on the Internet, there remain no "cookbook" approaches to implement the HIPAA Privacy and Security Rules. Even for providers that rely on best practices, judgment calls will have to be made during each step of the process.
The Integrity standard is a good example. It touches on work that was commenced and/or completed elsewhere. However, where audit controls are designed to capture what has happened, the Integrity standard requires providers to be proactive and to remain ever vigilant regarding where potential compromises might occur, and put in a systematic process for detecting this exposure currently and going forward. In short, as with most of the HIPAA regulations, process is king. There is simply no one "big bang" project that will get you into full compliance and keep you there. If that is your perception then you need to revisit the premises upon which you compliance strategy rests.
You can download the interactive Integrity PDF (Windows OS) to "explode" these activities into specific tasks.
4. 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.
Authentication means verification that a person or entity is who who they say they are. This should not be confused with authorization. The latter means essentially, now that we know that the person or entity is who they say the are, what is it that that person or entity has authorization to access? Needless to say that authentication is an important aspect of any security implementation. It is usually accomplished by the presentation, on the part of the person or entity, of credentials trustworthy enough to satisfy the system that they are legitimate.
You can download the Person or Entity Authentication PDF (Windows OS) to "explode" these activities into specific tasks.
5. 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.
Transmission has to do with the concept of data in motion. Essentially any time EPHI is moved from point A to point B, a provider must ensure that the EPHI is still protected (i.e. in a manner similar to when the EPHI is at rest). As a practical matter, this standard has to do with network security, both within the provider's organization and across the wire when EPHI is move from one provider to another (or more generally from one covered entity or business associate to another). For most providers, even large ones, ensuring that adequate network security is in place will be done in collaboration with consulting partners that have a proven track record in this space. It is simply too complex an initiative for most in house staff to handle on their own.
You can download the Transmission Security PDF (Windows OS) to "explode" these activities into specific tasks.
