The OCR HIPAA Audit program analyzes processes, controls, and policies of selected covered entities pursuant to the HITECH Act audit mandate. OCR established a comprehensive audit protocol that contains the requirements to be assessed through these performance audits. The entire audit protocol is organized around modules, representing separate elements of privacy, security, and breach notification. The combination of these multiple requirements may vary based on the type of covered entity selected for review.
Learn more about the OCR HIPAA Audit Protocol.
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) set national standards for health care electronic technology and security. Any organization that handles protected health information (PHI) may be considered a covered entity and may be responsible for maintaining the privacy and security of the patient data. Meeting the defined privacy and security standards for PHI is usually just referred to as "HIPAA compliance".
The HIPAA Audit protocol is broken down into 37 established performance criteria. The performance criteria cover the broad topics of privacy, security, and breach notification.
The established performance criteria are not grouped under these three broad topics in the HIPAA methodology or the report templates. Below, we have provided more details on the performance criteria, organized into groups based on the order in which they appear.
For more information, please review the OCR HIPAA Audit Protocol from the U.S. Department of Health & Human Services.The performance criteria in this section focus mostly on the management and broader workforce looking at the existing security measures and policies.
The tester also seeks to understand how policies and procedures are created, implemented, and updated as well as who is in charge of the organization's security policies. This information will likely be useful when necessary changes are identified!
Next, the tester turns their attention to the broader workforce looking to understand who has access to what. The tester needs to undestand who in the organization can access what PHI and how that access was given to them. And, they need to verify that there are training programs in place to make sure that everyone who has access to PHI has the proper amount of security awareness.
Next, the focus switches to some worst-case scenarios to make sure that the organization has procedures for dealing with a security incident and a contingency plan if data is lost.
Finally, the focus switches back to evaluations and business contracts. The evaluations must be carried out correctly to ensure that HIPAA compliance is actually attained. And, any business contracts or agreements must also meet security requirements when working with PHI.
How do people access the PHI? This phase of testing deals with the different ways that people access the PHI and what controls are in place to prevent the wrong people from accessing it.
The first line of defense is physical access to the data whether that's access to a building, a specific piece of equipment, a workstation, or a specific device. The tester also looks at the policies and procedures that surround data encryption, file permissions, user ids, and other access controls. And, the tester makes sure that audit controls.
This phase of testing circles back to some of the themes from earlier phases of testing. The tester verifies that everyone who needs access to PHI has it and that authentication methods are in place to make sure that people who don't need access to PHI cannot access it. The tester also looks at how data is transmitted and that the process is secure.
There are many common situations that require disclosure of PHI so the organization needs to have policies in place to handle these situations in a way that still maintains the overall security of the PHI.
The tester looks at the current policies involving PHI uses and disclosures for situations including a deceased person, whistleblowers, victims of crimes, business associates, treatment/payment/health care operations, and more.
In many situations, patients must specifically authorize that their PHI can be used or disclosed under a specific set of circumstances. There are also certain situations where the individual must be given the opportunity to agree or object to the use or disclosure of their PHI. This could be for healthcare purposes, emergency treatment, or even a situation like disaster relief. There are also other situations where the patient doesn't need to be given the opportunity to agree or object to the PHI disclosure like judicial proceedings, research, public health activities, or as required my law.
The tester also looks at some other requirements mostly related to how employees deal with PHI.
Privacy and proper notifications are obviously important in HIPAA compliance. Patients must be notified about the potential uses and disclosures of their PHI so that they can agree or object as needed. And, the tester confirms how the organization communicates to patients about their PHI, how restrictions to PHI use or disclosure can be terminated, and how patients can access or amend their PHI.
The tester also checks to make sure that PHI disclosures are appropriately documented and that there is a system in place to manage and resolve privacy complaints.
The tester also reviews that the administration is fulfilling all of the requirements to attain HIPAA compliance, going back over many of the broader concepts already discussed in earlier phases of testing like training, access controls, and safeguards.
If the organization's security is breached, they need to have a plan to deal with the breach and manage the situation with much care as possible.
The tester verifies that procedures are in place and adequate for alerting individuals to a breach of their own PHI. If the breach involves the PHI of more than 500 people, the media and the Secretary also have to be notified. In some cases, notifications may need to be delayed due to law enforcement requests.
Community Edition package |
Professional Edition package |
|
|---|---|---|
| Methodology templates | ||
| Project templates | ||
| Sample project | ||
| HTML report template | ||
| Word report template | ||
| Issue, Evidence, and Note templates | ||
| Download now | Download now |
Detailed versions of these instructions are also available in the instructions.txt file in your Compliance Package.
Filename:
This full project is ready for you to export and test. The project comes pre-populated with Notes corresponding to the various compliance tasks outlined in the HIPAA Methodologies. Each Note contains a Title and a Type field that should not need to change from one project to another. The Description field should be edited with specific details about your project and can contain any combination of paragraph text, code blocks, and screenshots.
See the Importing and Exporting Projects page of the Working with Projects guide.
(Pro): Use the dradis-export-word_report.zip file when working with the Word report template and use the dradis-export-html_report.zip file when working with the HTML template.
Filename:
The project template contains the same content and formatting as the Full Project export but are in template form so that you can load the content as a project template on your instance of Dradis.
dradis-template-html_report.xml or methodology-project-template.xml as Dradis::Plugins::Projects::Upload::Template.dradis-template-word_report.xml file when working with the Word report template and use the dradis-template-html_report.xml file when working with the HTML template.See the Project templates page of the Working with Projects guide.
Filename: hipaa-html-report-template.html.erb
This HTML template will generate a HIPAA compliance report organized into major sections based on the Node structure in the Full Project Export or the Project Template. Each Note (with the category set to Report) will export into the report based on the Type field value.
Place the HTML report template in the templates/reports/html_export/ folder of your local install.
See the Creating HTML Reports guide for more details.
hipaa-html-report-template.html.erb template and click Export.See the Report templates page of the Administration manual or the Creating HTML Reports guide for more details.
Filename: dradis_template-hipaa.docx
Your custom Dradis Word report template is organized into major sections based on the Node structure in the Full Project Export or the Project Templates. Each report also contains a cover page and a table of contents. Every Note in your project (with the category set to AdvancedWordExport ready) will export into the Report template based on the Type field value. See the Note template for a list of the possible Type field values.
Upload the Word report template to Dradis using the instructions on the Report Templates page of the Administration guide
Filenames: note.txt
This Note template will be useful when you’re manually creating Notes and need to match up the Type field values to correspond with the values that the report templates (both the HTML report template and the Word report template) are looking for. When manually creating a Note, be sure to select just one of the possible values under the Type field.
Your email is kept private. We don't do the spam thing.