As Phase 2 of the HIPAA audit program begins, covered entities (CE) and business associates (BA) will be watching their email for an audit letter from OCR. Of those chosen for audit, most will be selected for a desk audit. They'll have 10 days after receipt of the email to gather requested documents for OCR's auditors.
But how will CEs and BAs know they are collecting the right information? A careful reading of the updated Phase 2 audit protocol (www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/index.html) will help guide CEs and BAs. But if the protocol isn't read carefully, and in full, important documents could easily be left out, leading to inaccurate audit reports and even a visit from OCR's investigators.
The Phase 2 audit protocol expands the Phase 1 compliance areas to reflect changes made by the 2013 HIPAA omnibus final rule. The updated audit protocol also includes information for BAs, which were not audited during Phase 1 but will be in the current round of audits. The protocol contains a description of the audit areas, general instructions and definitions, and a keyword-searchable table.
Phase 2 audits will be conducted in three rounds. The first two rounds will consist of desk audits of specific audit targets, while the third round will be comprehensive audits. Round one audits will target CEs and round two audits will target BAs.
Q: Is it permissible to take pictures of patients for identification purposes as a part of the registration process? Do the patients need to sign a consent form before their picture can be taken?
A: It is permissible to take pictures of patients for identification purposes if the patient agrees to it. Since the Privacy Rule considers full-face photographs to be a patient identifier, it is a good practice to get the patient's written consent to take a photograph and file it with the patient's electronic record. The patient should be allowed to opt out of the photograph if he or she chooses.
Editor's note
Brandt is a healthcare consultant specializing in healthcare regulatory compliance and operations improvement. She is also an advisory board member for BOH. This information does not constitute legal advice. Consult legal counsel for answers to specific privacy and security questions. Opinions expressed are those of the author and do not represent HCPro or ACDIS. Email your HIPAA questions to Associate Editor Nicole Votta at nvotta@hcpro.com.
Creating and conducting an organizationwide risk analysis: Part 2
Editor's note: This is part two of a series about implementing an organizationwide risk analysis. See the May 2016 issue of BOH for part one.
Performing a regular organizationwide risk analysis is a basic HIPAA requirement and also simply good business practice. Beyond checking off an item on the HIPAA compliance list, a risk analysis will help an organization identify and rank security weaknesses, efficiently use resources to address them, and ultimately protect the security and integrity of an organization's data, including PHI, financial, and business operations information. Yet in a world of competing demands and limited resources, a risk analysis may be put off until it's too late. Even if one is completed, security officers may encounter obstacles when trying to act on the results of the risk analysis.
The purpose of a risk analysis is to develop a strategic plan of action that addresses and corrects vulnerabilities, and shouldn't be used to simply create a report on the current state of security, says Kate Borten, CISSP, CISM, HCISPP, founder of The Marblehead Group in Marblehead, Massachusetts. "Only when an organization performs periodic and as-needed risk assessments, and then mitigates significant risks, can the ISO [information security officer] and leadership have the confidence that their security program is functioning and adequate," she says.
A risk analysis is one of several activities that is part of a risk management program, says Rick Ensenbach, CISSP-ISSMP, CISA, CISM, CCSFP, manager of risk advisory and forensic services at Wipfli, LLP, in Eau Claire, Wisconsin. The risk management program is about managing risks to the organization (i.e., business mission, image, reputation, and patient safety and privacy), organizational assets, and workforce. An organization can't mitigate risks it isn't aware of and doesn't understand.
Risks are first identified, then analyzed and evaluated based on what action is needed, Ensenbach says. They also must be monitored on an ongoing basis, a vital step that if missed can undermine an otherwise solid risk management program.
The Health Information Technology for Economic and Clinical Health (HITECH) Act, part of the larger American Recovery and Reinvestment Act of 2009, was created to encourage and regulate the use of technology in healthcare. HITECH brought meaningful use, an incentive plan designed to increase the use of certified electronic medical records, and amendments to the Security Rule of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Although some provisions of HITECH have not been implemented (e.g., the more robust three-year accounting of disclosures for electronic protected health information [PHI]), the following is a list of the major topics that have been amended with the adoption of HITECH:
A breach of PHI is the last thing a privacy or security officer wants but, large or small, breaches can happen. The best-laid defenses can be undermined by simple human error or a cyber-criminal hacking on the cutting edge of technology. When that happens, you need a security incident response plan.
Disaster plan
A formal security incident response plan should be developed and maintained similar to a data center disaster response plan, Kate Borten, CISSP, CISM, HCISPP, founder of The Marblehead Group, Marblehead, Massachusetts, says. IT departments should be accustomed to disaster recovery plans that guide the department's response to any disaster (e.g., fire, flood, earthquake) that affects computer systems. Security incident response plans can be seen as comparable and equally important.
When a breach is identified, the first step should be to stop the bleeding. Take steps to prevent a recurrence or limit the damage. This could be especially important for security breaches that involve hacking or PHI that was accidentally made accessible to the public on a website or cloud service. In such a situation, it would be prudent to shut down affected websites, portals, or remove access to data repositories, according to Frank Ruelas, MBA, principal of HIPAA College in Casa Grande, Arizona.
Follow a plan from the start to ensure that risks are mitigated quickly. The plan should include appropriate steps to take depending on the type of security incident, who should be part of the incident response team, and how information about the breach should be communicated within the organization, according to Chris Apgar, CISSP, president of Apgar and Associates in Portland, Oregon. Having a detailed plan that lists members of the incident response team means more time can be spent addressing the breach than asking questions about who should be involved.
A security incident response plan will also help an organization determine what level of action it needs to take. "There will be some incidents, including breaches, where it's not necessary to pull together the whole team and go through every step in the plan," Apgar says. "For example, if a patient notifies you that she received another patient's EOB [explanation of benefits], it may not be necessary to call everyone together."
In that example, Apgar says, because the organization already knows who was impacted by the breach, the response is simply a matter of following the breach notification steps set by HIPAA and any applicable state laws.
