HIPAA Articles Roadmap      Posted March 13, 2013

HIPAA Articles Roadmap represented by a map and magnifying glassAs we near the date on which the new 2013 HIPAA Omnibus goes into effect (March 26, 2013), we wanted to provide this HIPAA articles roadmap that describes our current and upcoming HIPAA Articles.

In general we want this series to represent What You Need to Know about the 2013 HIPAA Omnibus. Our goal is not to just educate you on what has changed, but also cover a general overview about some of the important security and privacy rules of HIPAA. Accordingly, we’ve split the articles into three general areas. Articles are linked below, and those without links are pending publication.

Changes to HIPAA Rules

These HIPAA articles focus on specific rule changes in the 2013 HIPAA Omnibus, focusing on the Security Rule and the Privacy Rule.

Changes related to Applicability and Liability

These HIPAA articles focus on how the 2013 HIPAA Omnibus has changed who the HIPAA requirements apply to, and has changed what organizations can now be found legally liable for HIPAA violations.

General HIPAA Security and Privacy Awareness

These HIPAA articles provide a general overview of what organizations need to do to be compliant with the HIPAA Security Rule and the HIPAA Privacy Rule. Also covered in this section are what HIPAA Audits entail, and how to handle a HIPAA Breach.

Overall we hope that these HIPAA articles help to educate organizations about HIPAA’s requirements and their role in fulfilling them. Please contact us if there are additional areas you’d like to see addressed in future HIPAA Articles.


HIPAA: Identify a Breach      Posted January 17, 2014

HIPAA has specific requirements for reporting breaches of Protected Health Information. How do you identify a breach, and how do you know whether you need to report a breach?

Protected Health Information Asset Management

You should have a list of all places that protected health information resides within your office, your network, and your systems – and any business associates you work with. Ideally, you should also know which records are located where, so that when it does come time for notification, you’re ready. If there is a loss, theft, or attack, you know if that system had PHI on it or not, and can act appropriately. Being able to identify a breach becomes easier when you have all of this information.

What is a Breach?

identify a breach - a hacker's laptop

First, a breach is “the acquisition, access, use, or disclosure of protected health information in a manner not permitted [by the Privacy Rule] which compromises the security or privacy of the protected health information.” (45 CFR 164.402)

There are 3 statutory exceptions to a breach:

  1. “unintentional acquisition, access or use of protected health information by a workforce member… if it was made in good faith, within the scope of their authority, and does not result in further use or disclosure in a manner not permitted by the Privacy Rule” (Omnibus)
  2. “inadvertent disclosures of protected health information from a person who is authorized to access protected health information at a covered entity or business associate to another person authorized to access protected health information at the same covered entity, business associate..” (Omnibus)
  3. “where a covered entity or a business associate has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.” (Omnibus)

and, what I like to call the “opt-out”: a breach didn’t happen if the information was “secured” using specific technologies and methodologies – ie. encryption or destruction. (13402(h) of the HITECH Act) So, as long as your protected health information is encrypted, and it can’t be decrypted – it’s not a breach if it was stolen.

It’s a “breach”, now what?

The Omnibus ruling has four specific guidelines in a risk assessment that you must address to determine if a breach occurred:

  1. The nature and extent of the PHI. What was the data exposed? How many records were exposed? Was the data copied or merely viewed?
  2. The unauthorized person. Who accessed the data? Was it an employee or was it another patient or an unknown attacker?
  3. Whether the PHI was actually acquired or viewed. Was the data actually accessed? Could the unauthorized person see the data? Was it encrypted or in plain text?
  4. Any risk mitigation in place. What else is in place to protect the data? Was the unauthorized employee under NDA? Is there a confidentiality agreement with the business associate? Is the file password protected (if not encrypted)?

If, after all of these factors are considered, there is a low probability that PHI has been compromised, then it’s not a reportable breach. But the covered entity or business associate is responsible for making that determination.

The Department of HHS will assume it’s a reportable breach, unless and until the covered entity and/or business associate proves otherwise. Of course, there’s a strong incentive for a breach to be “non-reportable” – notifications cost time and money that the entity or business associate does not want to spend. And, without an audit or complaint, no one will ever know that a “breach” occurred and was not reported. Nevertheless, any covered entity or business associate would be well served to maintain records of any risk assessment that occurs. Not notifying HHS of a breach can result in hefty fines and penalties. The ability to accurately and quickly identify a breach is important to avoiding some of those fines.


Covered entities are responsible for notifying affected customers, although they may have contracted the notification to the business associate which caused/identified the breach. Business associates are not required to report a breach to the public, but their contracts with their covered entities will dictate when they need to report a breach, since the covered entity is still responsible for reporting the breach. Check any contracts that are in place between covered entities and business associates for timeframes. Covered entities must report the breach within 60 days of when it should have reasonably been known that the breach occurred.

If you are a business associate, notify your clients/customers as soon as you suspect a breach – even if you’re not sure that it’s a breach. This allows you to work as a team to identify a breach and identify what notifications are required and when.


HIPAA Physical Safeguards      Posted November 14, 2013

Section §164.310 of the Health Insurance Portability and Accountability Act describes the physical safeguards that a covered entity or business associate must employ when handling electronic protected health information (ePHI). These physical safeguards cover several areas, including facility access, use of workstations, and use and disposal of devices and media that contain ePHI.

Physical Safeguards – Facility Access Controls

Physical safeguards must be in place in any location where protected health information is stored. These safeguards must be formalized in policies and procedures which protect physical access to sensitive data. These policies must take into account the sensitivity of the data being stored, and provide measures that restrict physical access to locations that store ePHI only to those who require it for business purposes. The complete requirements are listed in the following implementation specifications:

Contingency Operations

Procedures must be established that allow necessary physical access to the facility when restoring lost data after an emergency. This restoration must take place under a formalized disaster recovery plan.

Facility Security Plan

A formalized plan must be established to protect facilities from unauthorized access.

Access Control and Validation Procedures

Access to the facility must be contingent upon the verification of an individual’s identity as well as their need for access to carry out business functions. This includes visitor control.

Maintenance Records

Any changes to the physical layout of the facility that may affect the access control policies and procedures must be documented.

Physical Safeguards – Workstation Use

For facilities where workstations are used to access ePHI, those workstations must be kept in a secure state. To this end, a covered entity or business associate must have formal policies that determine how workstations are to be used, and what physical state those workstations are to be kept in. For example, this policy could mandate that a specific workstation can only run a restricted list of programs, and that when it is in use, the user must be supervised by an administrator.

Physical Safeguards – Workstation Security

a locked laptop represents one of the HIPAA physical safeguardsCovered entities and business associates also must implement policies that create physical safeguards to the workstations themselves. In any case where a workstation has or could have access to ePHI, there must be a formal policy in place that restricts physical access to that workstation only to those who are authorized to use it. This policy also must detail the procedure through which authorization is obtained.

Physical Safeguards – Device and Media Controls

Physical controls must also be enacted for devices and media which may house ePHI. A covered entity of business associate must have formalized policies that indicate how devices and media are handled inside of a facility in order to prevent the accidental or malicious theft or destruction of ePHI. There are four policies or procedures that a covered entity or business associate must enact to be compliant with the device and media physical controls requirement.


Procedures must be established to securely dispose of devices or media that contain ePHI when they are no longer in use.

Media Re-use

Procedures must be established for secure and complete removal of ePHI from devices and media before they can be repurposed for other use.


The owner or party responsible for devices or media that contain ePHI must be tracked and recorded throughout the life cycle of the medium.

Data Backup and Storage

Retrievable backups of ePHI data should be created before any equipment is moved. These backups are subject to the same rules as other removable media that contain ePHI.

Changes in the 2013 HIPAA Update

The 2013 HIPAA Omnibus Rule changed the scope of the physical controls requirements to apply not only to covered entities, but also to business associates. No other changes were made in the update.


HIPAA Business Associate Contracts      Posted November 7, 2013

This article will explore section §164.308(b) of HIPAA, which deals with the business associate contracts and their protection of electronic protected health information (ePHI).

Business Associate Contract and Other Arrangements

“A covered entity, in accordance with § 164.306, may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with §164.314(a) that the business associate will appropriately safeguard the information.” [§164.308(b)(1)]

HIPAA Business Associate Contract being signedWhile section §164.314(a) covers the organizational requirements in more depth, this requirement covers the security requirements that apply to dealing with business associates. This portion of the security rule requires a covered entity to have a contract or other formal arrangement with any individual or organization that qualifies as a business associate. A full definition of what constitutes a business associate can be found in section §160.103 of the HIPAA law.  In simple terms, a business associate is any entity that is not employed directly by the covered entity but engages in activities on behalf of the covered entity that are subject to HIPAA requirements.

This particular requirement is only applicable for business associates who handle ePHI as part of their relationship with the covered entity. The covered entity must ensure that the business associate will safeguard ePHI in accordance with all requirements of the HIPAA law.

Implementation Specification

The business associate contract rule has one implementation specification:

“Document the satisfactory assurances required by paragraph (b)(1) of this section through a written  contract or other arrangement with the business associate that meets the applicable requirements of §164.314(a).” [§164.308(b)(4)]

This specification is fairly straightforward – it simply requires that the business associate contract containing the security assurances required by HIPAA is formally documented.

An auditor will verify this by inquiring whether there is a process to ensure that business associate contracts sufficiently address the security of ePHI. The auditor will review the documentation of the process of establishing business associate contracts, and will also determine that these documents are sufficiently reviewed. The auditor will also review whether the business associate contract process differentiates between private sector and public sector business associates in compliance with section §164.314.

This implementation specification is required.

Changes in the 2013 HIPAA Update

Several major changes were implemented to the business associate contract requirement in the 2013 HIPAA Omnibus Rule.  First, in the previous version of HIPAA, this requirement presented several exceptions to the business associate contract requirement. These exceptions have been removed, and instead the definition of “business associate” has been updated to remove those exceptions from qualifying as business associates.

Second, the language of the rule has been modified to clarify that a covered entity does not need to enter into business associate relationships with subcontractors of a business associate. It is the responsibility of the business associate to secure the proper agreement with the subcontractor. This is not a change in the law, but a clarification of an existing rule.

Finally, the update removes the provision that a covered entity would be in violation of the rule if the assurances provided in in a business associate contract with another covered entity were not upheld. This is due to a change in the law that now holds the covered entity (which is also a business associate) directly responsible for compliance with the security rule.

For example, say Company A and Company B are both considered covered entities, and Company B acts as business associate with Company A. Under the old law, if Company B did not uphold the assurances it gave Company A in the business associate contract, it would be considered in violation of this rule. Under the new law, this is no longer the case, as Company B will be directly responsible for compliance with the HIPAA security rule outside of the context of the business associate contract.


The 2013 HIPAA Omnibus Rule simplifies the business associate contract requirement by removing the exceptions and making many business associates directly responsible for compliance with the security rule. Covered entities are still responsible for formalizing contracts with business associates who are not covered entities, though. These contracts must sufficiently protect the confidentiality, integrity and availability of ePHI that is shared with the business associate.


HIPAA Policy Evaluation      Posted May 15, 2013

This article explores section §164.308(a)(8) of HIPAA, which deals with HIPAA policy evaluation and periodic examination of security requirements. Policies must be re-evaluated to ensure they are sufficient and appropriate for HIPAA compliance. This is required for changes in the general security climate as well as changes in a covered entity’s use of electronic protected health information (ePHI).

HIPAA Policy Evaluation

Bound papers representing HIPAA Policy Evaluation“Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart.”

There is no implementation specification provided for this requirement. However, there are several audit procedures that will determine compliance. First, an auditor will meet with management to determine whether periodic evaluations are conducted internally or by hired consultants. The auditor will view copies of the HIPAA policy evaluation and determine who performed the assessment. If the evaluations were performed by a third party, the auditor will then determine whether an agreement between the covered entity and the third party exists and if it includes verification of the consultants’ qualifications.

Second, there are several policy requirements that the auditor must examine. The auditor will determine if the covered entity has policies and procedures in place to ensure the following:

  • Periodic evaluations consider all elements of the HIPAA Security Rule
  • Preparation of materials and documents takes place in advance of a HIPAA policy evaluation
  • The results of evaluations are documented, including remediation recommendations and plans
  • Evaluations are repeated whenever there are changes within the organization that affect the security of ePHI.

Finally, the auditor will determine from management whether all of the above policies are reviewed and approved on a periodic basis.

Changes in the 2013 HIPAA Update

No changes to the HIPAA contingency planning requirements were included in the 2013 HIPAA Omnibus Rule. However, as described in this article, business associates of covered entities are also liable for complying with the Security Rule. Therefore, these requirements also apply to business associates.


Periodic HIPAA policy evaluation is important for ensuring continued legal compliance. As a covered entity’s business environment and business relationships evolve, policies and procedures must be re-examined to ensure the continued security of ePHI used by the covered entity.