At Aptible, we get a lot of questions about HIPAA business associate agreements, or "BAAs." This post will explain some of the essential concepts that cloud-hosted software development organizations should know about BAAs.
For a broader overview of HIPAA, see our post on common HIPAA questions.
One caveat, as always: This post is for informational purposes only. Aptible is not a law firm, and this post is not legal advice. You should contact an attorney to obtain advice with respect to particular issues or problems, including contracts and BAAs.
"BAA" is an acronym for "business associate agreement," which is an industry term for what the HIPAA regulations call a "business associate contract." Same thing.
BAAs are hybrid contractual and regulatory instruments, meaning they both satisfy HIPAA regulatory requirements and create liability between the parties.
Like most contracts, if one party violates the agreement, the other party may have remedies. Unlike most contracts, if a BAA isn't in place, isn't complete, or is violated, both parties may be in trouble with the federal government.
Check out that post on common HIPAA questions. The most common type of business associate is a person or organization that creates, receives, transmits, or maintains protected health information (PHI) "on behalf of" a covered entity or another business associate.
The regulations are more nuanced, but in the real world, if you handle identifiable patient data for any reason, most covered entities (healthcare providers, insurance companies, pharmacies, self-ensured employers, etc.) will consider you to be a business associate and make you sign a BAA.
Good question. HHS hasn't actually told us directly. It probably means the other entity (a covered entity or another business associate) either pays you or directs you in handling PHI.
For two examples of HHS interpreting what it means to handle PHI "on behalf of" an entity for purposes of determining whether a business associate relationship exists, see page 5572 of the final HIPAA Omnibus rule and HHS's recent guidance on when digital health app developers may be business associates.
No, members of your workforce are not your business associates, but you are responsible for supervising their access to PHI and training them on security and privacy practices. Your "workforce" includes paid employees, but also volunteers, trainees, temporary staff, and anyone else under your direct control.
Probably. Most of the time independent contractors and consultants will not be under your direct control and should be treated as business associates, meaning they need to be prepared to comply fully with HIPAA, including signing a BAA and accepting liability for compliance.
Any time a business associate relationship exists between two parties, they are required to execute a BAA. (Note that a BAA doesn't need to be a standalone agreement. The required provisions be can incorporated into terms of service, master service agreements, data security agreements, etc.)
There are two kinds of business associate relationships:
BAAs work like a chain: A covered entity customer of yours is not required to have a BAA with your subcontractor.
For example, if you sell SaaS that handles PHI to a large self-insured employer (a covered entity) and host your services on Aptible:
In addition to Aptible or another hosting provider, you probably use a range of third-party app and workflow services to build your products and run your business. For example, you might want to use Twilio for sending SMS, Mailgun for transactional email, Mixpanel for analytics, AWS RDS for your database, Papertrail for logging, Slack for internal communication, Gmail for email, etc. Some of those providers will sign BAAs, others will not.
Be careful to not have any vendor create, receive, transmit, or maintain PHI on your behalf without a BAA in place.
If they don't sign a BAA, keep PHI out of their service.
You might be tempted to use a service with PHI anyways, or look the other way. Don't do that. HHS just hit a healthcare system with a $1.55 million fine settlement for failure to execute a BAA with a vendor. Last year, HHS fined another covered entity $218,400, in part for using an Internet-based document sharing application (think Dropbox or Google Drive) for PHI without a BAA.
So if you want to use service with PHI but can't find a vendor who will sign a BAA, you may have to build that service yourself. Ugh.
In that case, self-hosting an open-source service on a private stack using Docker containers is becoming a popular choice. Among Aptible customers, Sentry for error monitoring and Elasticsearch + Kibana for logging are two common setups. All of our open-source Docker images are designed for portability to private environments.
Tell them to GTFO.
Some version of the following conversation happens on a fairly regular basis:
> Customer: I want to spend $MONEY on your service. Are you HIPAA-compliant? > > Shady Vendor: Yes! Of course! We have all the HIPAAs. > > Customer: Will you sign a BAA? > > SV: Yes! Of course! > > Customer: [amazed at how easy that was] > > SV: ... so, what's a BAA?
If you know that a business associate of yours has materially breached a BAA, the HIPAA regulations say you must correct it or terminate the BAA. If you don't, you could be on the hook for the vendor's non-compliance. And it makes HHS very angry when entities ignore the HIPAA rules on purpose.
That said, HIPAA does not require that you police your vendors. When they handle PHI for you, they become directly liable for compliance and are subject to penalties and enforcement on their own.
The full requirements are in the text of the regulations. HHS publishes an "Administrative Simplification" that presents all the HIPAA regulatory standards in one document. Look at §§ 164.314 (p. 67) and 164.504 (p. 81) in particular.
HHS also publishes summary BAA guidance with a list of the 10 topics that BAAs must address and sample provisions - definitely recommended reading.
In very brief summary, the main requirements for a BAA are to:
Remember that signing a BAA and complying with HIPAA are different. The majority of HIPAA requirements are not memorialized in BAAs, but they still apply.
Part of the Privacy Rule says that subcontractors business associates must "agree to the same restrictions and conditions that apply to the business associate with respect to such information."
Some entities misunderstand this to mean that all provisions of all BAAs down the chain must be identical, including custom security controls. This is wrong and unnecessary.
The intent of the rule is to make sure a business associate can't end-run privacy restrictions by contracting out to a third party. If the business associate isn't allowed to perform a use or disclosure, their subcontractors aren't either.
Security is a separate matter. The Security Rule has its own set of organizational requirements, which do not include strict inheritance of controls. That makes sense in light of the Security Rule's emphasis on flexibility and application of controls that are "reasonable and appropriate" to each entity.
It is fairly common for covered entities to push for very short breach reporting triggers and timelines. Sometimes this is driven by the mistaken belief that the covered entity has 60 days from the time of the first discovery of the breach _by anyone_ to complete its Breach Notification Rule obligations.
Breach reporting runs in serial, not parallel. (See page 5655 of the final HIPAA Omnibus rule).
Don't agree to report breaches "within $X days" of the breach. You can't - odds are you may not even know there was a breach by then. Use the "known or should have known" threshold in the Breach Notification Rule.
An "agent," in the legal sense, is someone who acts as you. For the purposes of breach notification, an agent's discovery of a breach is imputed to you, as are the legal consequences of their actions. Almost every subcontractor or vendor agreement expressly disclaims an agency relationship between the parties. A BAA that requires all of your subcontractors to be your agents is unnecessary, dangerous, and probably impossible to comply with.
Always talk with an attorney to understand your potential liability. Liability and indemnification provisions may appear both in your underlying contract and your BAA - make sure you understand how they work together, and which terms control in the event of a conflict. For startups, contracts with no limitations on liability will make you toxic to potential acquirers.
Liability has both breadth and depth. Breadth, or scope, means the types of damages that you might be liable for. In general, you should only accept certain types of liability. Unlimited liability means that, in addition to any breach indemnification, your customers could also potentially sue you for loss of business, loss of reputation, and other consequential damages. It is common to exclude those types of liability.
Depth refers to how much you might potentially be liable for. Another way to limit liability is through a total dollar cap. This is common for general liability (i.e., if you don't hold up your end of the underlying contract), but uncommon for breaches, where the normal practice is uncapped indemnification. This isn't as bad as it sounds because the types and amounts of costs involved in breach response are somewhat predictable and insurable.
Feel free to incorporate parts of these examples into your own BAAs, but always consult an attorney for specific legal advice.
If you have any questions about this post, or you'd like to chat about how to design and scale a HIPAA-compliant engineering organization in the cloud, feel free to contact us.
Update - March 29, 2016: Added a table of contents.
Update - October 29, 2016: Formatting edits.