skip to Main Content
Talk to a Security Expert Now: (800) 721-9177

Business Associates: The HITECH Act requires BAs to be compliant with the HIPAA Security Rule – that’s a good thing.

Managing vendors and business partners is hard in any industry, but when the data is sensitive ePHI, you are trying to achieve EHR meaningful use and there are penalties like the HITECH Act’s breach notification requirements, it can be even more daunting.

Fortunately, one aspect of the HITECH Act can minimize security risk and facilitate managing Business Associates (BAs). Under the HITECH Act Business Associates need to be compliant with the HIPAA Security Rule. According to the HITECH Act Section 13401(a):

Sections 164.308, 164.310, 164.312, and 164.316 of title 45, Code of Federal Regulations, shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity.

This means that a Business Associate is required to comply with the administrative, physical and technical requirements of the HIPAA Security Rule as well as with the HIPAA policy, procedure and documentation requirements. This is a good thing because it provides a defined set of standards for BAs to follow. This also provides better criteria for a covered entity to evaluate if the BA is effectively protecting ePHI. Prior to the HITECH Act managing security of ePHI fell upon the covered entity in the form of a Business Associate agreement. The HHS sample template for Business Associate agreements shows how ill-defined this could be

Business Associate agrees to use appropriate safeguards to prevent use or disclosure of the Protected Health Information.

The problem with this approach is that, while it sets some contractual expectations of protecting PHI, it does not:

  • set standards as to how that data is protected, and it does not
  • provide a baseline for validating if Business Associate are actually following the standards.

In our experience as security auditors doing health IT security assessments and risk analysis, we understand that both setting standards and validating to ensure these standards are met, are necessary. The reason is that, while it is easy to specify minimum control standards, actually living up to these standards is much harder. Here are some practical examples of how the documented security standard within an organization can be quite different than the actual security provided, even for the most basic controls:

Example 1: encryption of ePHI

If you poll your Business Associates and ask: are you using full-disk encryption for all laptops? Most likely, they’ll answer yes. However, during an assessment, if you dig a little deeper, you will find, for example, that many laptops are in sleep mode, rather than turned off, so the disks are not necessarily encrypted during travel. Furthermore many laptops will use directory level encryption instead of full-disk, which is just fine in theory, however, when you analyze them, you will find that ePHI is stored outside of the encrypted directory.

Example 2: virus protection

Ask a Business Associate – are you using virus protection? – and they’ll all say yes – because of course they are… everybody is these days. However, if you dig a little deeper, you will find many workstations that are not using up to date virus signatures because the user inadvertently turned off the auto-updating or the anti-virus client is not synced to the correct update server.

Example 3: patch management

Ask any health IT professional that works at a Business Associate about system patching? – and they’ll say yes of course we patch everything so all of our software is up to date. However, some in depth analysis will often show that, while operating system patching is fairly consistent, there is a significant lack of patching for 3rd-party applications on servers, workstations and laptops alike.

Other common examples of controls that exist but are not as effective as intended include: wireless networks, mobile devices, and network segmentation (such as attempts to partition ePHI via DMZs and internal firewalls). Now the discrepancy between the existence of these controls and the effectiveness of the controls does not imply some malicious intent by the Business Associates. To the contrary, they most likely have implemented these controls with the best of intentions. However, as anyone who works in a health IT environment knows, there are limited IT resources and too many things to do, and sometimes there is not enough resource cycles left to verify that controls are working as intended. So the upside of the HITECH Act requiring Business Associates to comply with the HIPAA Security Rule is that it will provide a more defined set of standards by which covered entities can evaluate Business Associates, and also for Business Associates to evaluate their own internal security.

In the end this could mean:

  • better protection of ePHI,
  • improved compliance with the “protecting electronic health information” core objective of meaningful use, and
  • reduced chance of a breach notification event under the HITECH Act.

These are good objectives for everyone!

Download a Business Associate Questionnaire to insure your BAs are effectively protection ePHI

This Post Has One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top