HIPAA and Healthcare Applications, Part 2 of 3: What You Need to Know About Auditing
This is the second part of our three-part series discussing the Security Rule section of HIPAA in healthcare application development. Here, we’ll go over what needs to be audited and what is considered an appropriate level of auditing. Our previous post on user authentication decodes the Security Rule as it applies to patient portal and mHealth app development, specifically with regard to user authentication. The next post will discuss relevant issues related to data transfer.
What needs to be audited?
The auditing requirement for covered entities was created to ensure that controls are in place for monitoring activity on electronic systems that use or contain electronic protected health information (ePHI). These entities must also have policies in place to systematically review and monitor audit records to establish that all activity on these electronic systems is appropriate. Logons and logoffs, file accesses, updates, edits, and security incidents are a few examples of activities that should be monitored.
The only obligatory audit is a risk analysis, which is required regardless of a provider’s size. In this analysis, providers must accurately determine whether potential vulnerabilities and risks to the integrity, confidentiality, and availability of ePHI exist within their systems. Conventional controls for these audits generally include the application of software, hardware, and/or procedural mechanisms which analyze activity in systems containing ePHI.
How long do audit records need to be retained?
Audit records and all associated documentation must be retained for six years. This period begins either on the date of the creation of audit records and documentation, or the date for which they were last in effect (whichever is later). Logs of system activity and records of security breaches are examples of information that must be available from audits within the six-year period.