When HIPAA first became a law, at the end of 1997, most healthcare organizations were so sure that it would be repealed or rescinded when Bush came into office, that they never quite got around to doing that first risk analysis.
Later, the risk analysis requirement got harder and tougher, when the Office of Civil Rights (OCR) added their guidance document in May 2010, and suggested that in addition to HIPAA Security and HIPAA Privacy, and the HITECH ACT, that organizations should also use NIST Special Publication 800-66 as a reference guide for the risk analysis and the protection of electronic Protected Health Information (ePHI).
The risk analysis has gotten more complicated, by the tightening of requirements, and by the need to include business associates, third party vendors, and an all-hazards threat approach.
Using a detailed project plan as you start the risk analysis is a good way to not only deal with the technical requirements, but also to inform management and stakeholders in the organization what a risk analysis includes, and to outline their potential participation.
There are different roles including IT users who will answer questions related to HIPAA control standards, management who will provide financial data and approve different values, and department managers, who will supervise their own staff and make sure they answer the surveys and cooperate with the analyst in a timely manner.
After the roles have been assigned, the data gathered, the reports approved, the project plan can be used to create the mitigation activites, a corrective action plan, and used to manage and track the new controls that are implemented.
If you’d like to see a HIPAA Project Plan, just email me at chamilton@riskwatch.com