What do you have to know to successfully implement and negotiate a BAA and achieve HIPAA compliance?
With the mounting momentum for cloud adoption within the healthcare space, the topic of business associates agreements (BAA) isincreasingly fraught with competing perspectives on what one should entail.
However, the truth of the document is at once far simpler – which actually might make it seem more complex. The Department of Health & Human Services has some key information, but the path to compliance is going to be different for every business.
There are a few things to note that can be especially helpful in determining whether a specific vendor relationship and the BAA they will sign is best for your business.
What HIPAA requires
HIPAA regulations are extensive, exhaustive, and time consuming to implement. The HIPAA Omnibus rule clarified in January of 2013 that any organization touching ePHI, not just the “Covered Entity” and an outside vendor working with the Covered Entity’s data in some way (directly or indirectly), moreover if you yourself are that kind of Business Associate and work with a subcontractor, the subcontractor had to be defined as a Business Associate in order to meet HIPAA requirements.
Outside of how your business is understood within the construct of this chain of BAA relationships, the type of infrastructure strategy you have in place similarly impacts meeting HIPAA requirements. If you were doing everything internally, all aspects of the data and technology running your cloud and IT would be utterly covered by your internal processes.
However, this is rarely the case. Especially where your outsourced cloud infrastructure is concerned, developing a clear understanding of what you are and are not responsible for will frame how you need to approach negotiating a BAA (this requirement is also the foundation of why you would need one!). It should be noted that some vendors might not be willing to sign a BAA at all.
What a BAA entails
The BAA is meant to establish a clear delineation of responsibility around the security of the ePHI and liabilities including real civil and criminal penalties where achieving HIPAA compliance is concerned. In an ideal world, every aspect of HIPAA could be satisfied internally. However, the reality of the way businesses leverage outsourced infrastructure providers requires agreement of responsibility between a client and a cloud vendor be established.
So we come to the BAA. To be sure, there is no single standard for how a BAA should be structured; there are definite requirements for what needs to be there around disclosure, use of ePHI, or reporting of breaches, but they can also reflect additional limitations around the extent to which the business associate is to carry out a covered entity’s obligation under the Privacy Rule.
One BAA could simply provide a guarantee for compliance for what a vendor does – cheap and easy IaaS for example. That same BAA, however, might also make clear that the customer would still be responsible for the rest. The truth is that some BAA’s could limit the business associate’s responsibility to carry out the covered entities obligation to only 3% of a compliance audit. Others will go further and cover 91%. What determines that difference really comes down to whether the vendor is willing to go further and what the marketplace accommodates.
What’s happening in the market is that many businesses are beginning to ask what a provider can do to help them be compliant. It’s no longer good enough to simply have a BAA. Where cloud and its interaction with ePHI are concerned, there are things that have to be covered, and it is more and more the vendor that needs to show a potential customer that they have the capabilities to do it. But where you have the breakdown of responsibilities is also important, whether that’s in the MSA, service orders, or is implied in the services that are and are not provided.
But let’s explore an example of the BAA in action with disaster recovery (DR):
If you’re going to pass a risk assessment, you need some sort of DR strategy. Even when utilizing a cloud provider, some businesses will say that they have a plan, but are running it through a third party other than their cloud provider. In that case the BAA is fairly standard, but the cloud vendor is clearly not responsible for that third party’s service, and will carve out liabilities in the BAA around the services not being provided by them.
However, if the covered entity were using the cloud providers’ service for DR, you would want as much of that service as possible covered under the BAA. This will vary from some larger cloud providers who will say that individual services are available for you to deploy but that puts all the responsibility for replication, testing, making sure DR works, documentation, etc., back on the covered entity (the client). Putting the liability for usage and data interaction back on the covered entity choosing to use the service effectively limits the cloud provider, due to what was agreed to in the BAA, though this might not reflect what the covered entity wants.
Just a Checkbox?
After getting a better handle on what’s involved with a BAA, it’s important to realize what level of effort remains for you when working with your vendors to achieving compliance. It could be a lot or a little depending on what the Business Associate has agreed to be responsible for. While this might seem counter intuitive (the BAA is for compliance after all, right?), depending on the provider you choose, you may have to face this choice. If having a BAA just for the sake of having one (even if it doesn’t appeal to any of the services or data structures that you need it to address) is all that’s required for you to feel comfortable, then there are options to choose from.
However, a thorough audit can quickly challenge the simple BAA. If your company is undergoing a risk assessment, auditors will be asking many more questions regarding who is interacting with and is responsible for ePHI and where liability falls, than you have answers for. Citing the DR example above, having a clear delineation of responsibility and liability is key to easing this process and helping you focus your efforts internally toward the parts of the infrastructure you will be directly responsible for keeping compliant.
There’s always a limit for what an outside vendor can cover. While a cloud service provider can’t necessarily assure complete compliance themselves, they are positioned to be able to offer services that can bring you closer, through IDS, firewall change request documentation, and their own internal compliance processes. However, there is responsibility on the client-side regardless of whether they choose a provider that does everything soup to nuts from building the app, to infrastructure, to pure IaaS. It just depends on where that falls on the spectrum of what has to be covered internally.
Thoughts? Let us know on Twitter @CloudGathering.
By Jake Gardner