How to read a BAA: A brief guide on HIPAA for SaaS Product and Engineering Teams

An exercise in using my keyboard's shift key.

This isn’t legal advice or the opinion of my employer. I’m not a lawyer. It’s a free blog on the internet. But I’ve been on the end of quite a few of these of negotiations and lived through a few close call incidents. This is my advice.

Recently, there was a debate on HTN regarding HIPAA compliance. The question was relatively simple: can you have a default BAA in an MSA/T&C in the event that a buyer/user would potentially put PHI in your software?

The very short answer to this is yes, you can. The longer answer involves some clarification.

When does a business become a Business Associate?

If a business:

1. Sells things to Covered Entities or Business Associates.

2. Tells the Covered Entity or upstream Business Associate that they can put PHI into the product (or, put another way, doesn’t tell the Covered Entity not to put PHI into the software).

3. Delivers the software to the customer who puts PHI in it.

At this point the business is explicitly a Business Associate or Business Associate Subcontractor. If only #1 and #2 are true, the business is tacitly close becoming a Business Associate or Business Associate Subcontractor.¹ This was clarified via the HITECH act; before HITECH in 2013 a vendor could argue that since a Business Associate’s Agreement was not in place that their company was not a Business Associate and therefore had no obligation to HHS or covered entities via HIPAA. For example, imagine a business that sold managed hosting to a hospital to host their EHR. Prior to 2013 if there was a data breach, the hosting vendor could have argued that it had no obligations under HIPAA without a BAA, even if they knew they had PHI. This was bad and it is good it is less ambiguous. So, if PHI ends up in a vendor’s product it is either:

1. Data protected by a Business Associate.

2. A Covered Entity made an impermissible disclosure.

Of course, there is some gray area to this. But in most cases this is straightforward. This indicates that a Business Associate must function as such through a legal agreement known as the “Business Associate’s Agreement”. However, it does not indicate the “quality” of that BAA. This was the core of the question “can I have a standard BAA?”. How would you draft such an agreement?

I believe that many people don’t get into the details of BAAs because they are scared off of BAAs by experts. Experts certainly have an important place and I’ve loved working with every compliance expert at my companies in my travels. But non-experts can still understand a ton about BAAs. And as a PM, I’ve had to weigh in on the business and product implications of BAAs at most of my employers, even the big ones. Knowing how they work will make you better at anticipating compliance needs, which are universal in healthcare. But to understand it, it involves diving into the components of the BAA.

Sometimes (a lack of) quantity is a quality all of its own

Most BAAs look roughly the same, following the template by HHS. You can follow along here with shared enumeration with the HHS template. If you want to read the sections side by side, I have a Google Doc that makes it more readable here.² If my annotation is shorter for a section it’s because the wording in the BAA template is understandable at face value (IMHO) or doesn’t require additional context. Let’s begin:

1. Definitions/Legal Setup → All terms defined.

2. Disclosures of PHI → The Business Associate agrees to only disclose the Covered Entity’s or another Business Associate’s data as directed by the Covered Entity except for the exceptions allowed by HIPAA (e.g. a legal investigation).

3. Safeguards of PHI → The Business Associate agrees to protect PHI as required by law and agrees to train their staff on protecting PHI.

4. Reporting Disclosure of PHI and Security Incidents → In the event that there is an impermissible use or disclosure or a security incident, what are the obligations on reporting and notification timelines? Remember not all impermissible use/disclosure or security incidents are necessarily breaches. For example, a business could find out that an employee laptop with PHI on it was lost at the airport.³ Good news, the laptop was recovered from the airport and it was validated that no one had logged into the laptop while missing. This would likely be determined to be a low risk incident when doing a breach risk assessment and would not be escalated by either the Business Associate or Covered Entity. However, based on the wording on this section of the agreement, the Business Associate may need to inform the Covered Entity that the laptop was stolen, recovered and what had occurred. Most BAAs indicate that the Business Associate will make best efforts to report incidents to the Covered Entity, then also indicates an upper time limit to which the Business Associate must inform the Covered Entity upon being aware of the event. What are some sample time limits? I pulled some BAAs that were publicly accessible from previous employers, like our open source policies at Datica and the standard terms of use of Butterfly Network which included a BAA.⁴

   

   The biggest thing of note is that a timeline here that is too short is not necessarily empirically better for everyone, including the Covered Entity. We’ll cover why next.

5. Reporting Breaches of Unsecured PHI → If there is a breach, the Business Associate’s obligations differ than in suspected incidents or impermissible uses. Per HHS, the Business Associate must inform the Covered Entity within 60 days of the discovery of the breach. If the breach impacted more than 500 people, the Covered Entity must then inform any people impacted by the breach within 60 days of discovery or when it would have been known in performing “reasonable diligence”.⁵ Reviewing the differences:

   

   There are some major variations in BAA terms between these BAAs. The difference between 4 hours and 60 days is significant. A major breach to a Covered Entity bears immense risk for reputation damage. Most covered entities want the maximum amount of time possible to prepare for responding to patient concerns, ensuring access to services, and getting in front of the incident as much as possible.

   This section also introduces other acknowledgements and provisions regarding what is reportable. It’s not unusual for a BAA to refer to other contractual provisions regarding costs of service, liability, indemnification, and contract termination provisions. When folks say things like, “The BAA is a construct of HIPAA itself and therefore is standard or uniform”, these types of clauses make that assertion somewhat less true. For example, the HHS sample BAA indicates “Business Associate will reimburse Covered Entity for any costs incurred by it in complying with the requirements of Subpart D of 45 CFR §164 that are imposed on Covered Entity as a result of a Breach committed by Business Associate.” That could be complicated! What if the breach was due to shared responsibility; say, a tool provided access to a certain subset of patients to doctors but it was because the Covered Entity was not using the software as instructed? Being fully responsible for costs here may not be merited and it’s why this is not offered in any of the standard vendor BAAs.

   
   The BAAs also indicate that the Business Associate has no obligation to inform the Covered Entity of a variety of things. The Sample Major Cloud Vendor BAA and the Butterfly BAAs indicate that failed incidents do not need to be reported to the Covered Entity and other BAAs may indicate that breaches that impact other covered entities may not be reported to all Covered Entity customers of a Business Associate.
   
   Costs and notification content notwithstanding, some of the negotiation of this clause is just the vagaries of contracting. The initial contract timeline proposes 8 days, customer proposes 4 days, both parties land on 6 days and feel like they’ve won. From a product and engineering standpoint, however, a company has an ethical obligation to ensure that they can run through either impermissible use or breach notification scenarios to ensure that they can contain an incident, identify which patients were affected and then inform the Covered Entity within the stated timelines. Let’s use one of the classic examples:

   ---

   Imagine that you work for BreachSoft, a company who provides a managed service for care coordination for a Covered Entity. Their impermissible use notification timeline is 4 hours. A clinician at BreachSoft shows their operations supervisor they have been exporting a list of patients for the last month and giving it to an unauthorized 3rd party AI bot to make phone calls to those patients.⁶ The compliance and engineering teams at BreachSoft now must comb through their systems to figure out what happened. The clinician is probably telling the truth regarding scope, but the Business Associate must verify this. Depending on the auditing capabilities of the software, that could be a lot of work! And it’s hard to tell if the AI Bot company would cooperate with an internal investigation. There’s a lot that needs to happen, especially facing a breach of contract at the 4-hour mark. It may be preferable to all parties to gather more data to present to the Covered Entity first, especially as the situation is controlled. The Covered Entity may respond differently to knowing that the clinician only offloaded 74 patients worth of work over a few weeks vs. thousands of patients over years.

   ---

   As a product person, I understand why a business wouldn’t necessarily want to put work into this. It’s non-accretive to clinical care. But it’s something a business needs a plan for. Any Business Associate will get evaluated on this in security questionnaires or 3rd party assessments. There’s plenty of valid reasons why Business Associates want these timelines to be as long as possible and why health systems want the timelines to be as short as possible.

6. Mitigation of Disclosures of PHI → This in writ is usually pretty boiler plate. The Business Associate agrees that if they know ways to mitigate inappropriate exposures of PHI that they need to take action towards that. In practice this usually means that the Business Associate has a plan to identify threats in software, patch software and monitor employee access to data.

7. Agreements with Agents or Subcontractors → This section generally effectively indicates that a subcontractor can’t have a worse BAA with the Business Associate than the upstream parties have with the Business Associate and ensures that the terms in this agreement also apply to the subcontractor. It wouldn’t make sense for the breach notification timeline with the Business Associate to be 7 hours and then for the BAA with the cloud provider to be 60 days. The ramifications for this as a product person is that the business must align vendors to the standards of their own contracts. If you work for a business with very stringent BAAs, the vendors available to your business may be limited.

   
   This section also generally indicates what responsibilities the Business Associate must inform the Covered Entity that they are onboarding new subcontractors. The HHS template indicates that the Business Associate must inform the Covered Entity within 30 days that they are adding or changing subcontractors. It’s also not uncommon for this BAA section (or other similar contractual language) to instruct the Business Associate that all personnel that have access to PHI must be located in the United States. This also means that PHI should not be accessed by US-based personnel while in other countries. This is a good example of HIPAA as it’s spoken not HIPAA in writ; HHS indicates that PHI access and storage outside the US is permissible, but that certain situations may increase risk of an either an incident or could prevent enforceability of HIPAA itself. Some covered entities have decided that their risk tolerance for this is zero and will act accordingly.

8. Audit Report → This indicates that the upstream signer can at any time request proof that an audit has occurred. While at a minimum a Covered Entity or Business Associate needs to perform a risk analysis and implement security measures to protect data, this can be done vis-a-vis self-attestation. However, any organization bearing any major amount of risk will want to ensure that anything that is promised in a self-attestation is true. As such, it is usually a good idea to begin down the path of SOC 2 Type II, HITRUST or at a minimum a HIPAA audit for a product that introduces significant risk to an organization. There’s a difference in risk between a product that only expects to be exposed to PHI rarely vs. a product that has one in four Americans in it. Some organizations are keen to this variance; others treat all Business Associates like they could potentially consume every patient record in their organization.

9. Access to PHI by Individuals →

10. and Amendment of PHI → Most SaaS vendors are not often by impacted by these types of clauses. This is the part of HIPAA where the “P” standing for portability matters. Patients have access to their data and rights to ensure the data in their medical records are correct. These clauses ensure the timeline by which a patient could expect data from the Business Associate, the format of that data and who makes decisions on the topic. In most situations, the Business Associate should enable the Covered Entity to do this work. This means either pushing data from the product into an EHR or PACS where Designated Record Sets and EHI are commonly managed or allowing the organization to export data for a patient in totality if the data cannot be easily integrated with those systems. This is usually rare; generally the sales process reveals where a Covered Entity wants the type of data the product generates to reside and any one-offs can be handled with agile R&D.

11. Account of Disclosures → Similarly to Access to PHI and Amendment of PHI, patients also have rights regarding understanding how a Covered Entity and their Business Associates disclosed their data. If a patient requests this, the Covered Entity will need to provide information about the disclosure and call upon their Business Associates and sub-contractors about their disclosures. The Covered Entity must respond to the patient’s request within 60 days (longer in the event of some exceptions) so generally speaking a Business Associate will be required to guarantee some timelines on providing information about disclosures. Comparing our BAAs again:

    

    There is some variance here. Based on the role of the Business Associate and their access to data these variances are understandable; cloud vendors should never need to access individual PHI. Like before, some covered entities will want more time than 60 days to coordinate all of their efforts.

12. Availability of Books and Records → The Business Associate agrees to participate in any investigations by HHS into the Covered Entity. If the Covered Entity is accused an inappropriate disclosure, while the Business Associate may not be at fault for the actions of the Covered Entity they may need to help assist in the investigation. This could occur if the evidence of the incident, like our BreachSoft scenario, resided in the Business Associate’s software. The Covered Entity could be uncooperative and HHS might rely on the Business Associate directly for help.⁷

13. Responsibilities of the Covered Entity → Pretty much all the language in the BAA at this point has been pointed towards the Business Associate. The HHS Model BAA is pretty light on Covered Entity responsibilities; the Covered Entity must let the Business Associate know if their privacy policy would change how the BAA would work. They must inform the Business Associate of any changes as to who should access and disclose PHI and what PHI should be disclosed. Finally, the Covered Entity cannot instruct the Business Associate to violate HIPAA.⁸

    Most other vendor BAAs have instructions for the Covered Entity. Some indicate that the BAA must only send PHI through specific encrypted methods to ensure that the Business Associate does not take fault for any PHI sent inappropriately. Other BAAs may reference another document that is updated more frequently and may indicate that the configuration of the software must always keep in line with the recommendations of the document. For example, the “Architecting for HIPAA Security and Compliance on Amazon Web Services” document indicates that you cannot put PHI into the names of files or folders in AWS WorkDocs or the whole book about using AWS Comprehend in accordance with policies.

14. Data Ownership → BAA may have some wording around data ownership or specifications around de-identification in addition to the MSA.

15. Terms and Termination → This first section indicates that the BAA takes place immediately. Hypothetically speaking it could be time-boxed by project phase, milestone or a date but most SaaS BAAs begin immediately.

    
    Second, the HHS sample indicates that the Business Associate will have breached the contract if they do not remedy a material breach of the BAA within 30 days. These type of clauses are why the timelines matter. Remember, this isn’t a “HIPAA” data breach. If the Covered Entity alleged that the agreement was in breach with vague requirements to cure said breach, that would be bad for the Business Associate, especially if they did not agree with the allegations of the Covered Entity.

    
    Third, the BAA indicates the timelines and procedures by which the Business Associate must either return or destroy the PHI given to them by the Covered Entity. Since upon termination the Business Associate is no longer a permissible party for disclosure, the Business Associate has responsibilities to ensure that data is removed responsibly. This is another sticking point of many BAA negotiations. The minimum requirements of the Business Associate are to either return or destroy the data, or, if that is impossible for the Business Associate to protect the data into perpetuity. However, most Covered Entities will not be satisfied with the idea that a SaaS Business Associate could not manage this process on a timely basis. The Covered Entities will likely push for maximum timelines for deletion and or transfer of data and certification of this action. Conversely, Business Associates should ensure that if the Covered Entity wants the data returned that there is a mechanism for that to occur as agreed upon. This is especially true if the reason for churn is that the customer termed due to non-payment or other terms in the MSA.⁹
    
    The best way to manage this is to provide these tools via self-service to the customer. Give them the tools to export and move the data as needed. If the customer wants to delete data, give them the ability to do this carefully. Also, reduce the places PHI is stored within the organization permanently. It’s complicated if you need to also remove it from support tickets, slacks, JIRA tickets, secure emails, logging solutions, etc.

16. Effect of the BAA → The BAA does not favor either party and if the MSA and BAA conflict each other the BAA takes precedence.

    
    As purists will note, “BAAs govern agreements under HIPAA and HIPAA is the law”. However, due to some of the nuances of healthcare contract negotiation it’s not uncommon for non-HIPAA clauses to be included. It’s also not uncommon for BAAs to not be signed until after the main MSA is signed, providing an opportunity for either party to shift the favor of negotiation once the tides have changed. As such, this is how you find things like indemnification being entirely dictated, not only for breaches but for the entirety of the agreement, in the BAA.

17. 18. 19. 20. Regulatory references, where to send notices and how, Amendments and Waiver, and HITECH notes. As stated.

Summarize it for me

Generally when negotiating a BAA, the timelines and nuances of meeting these provisions matter. It’ll dictate everything, even who your partners and customers can be. If you are trying to level up at this, I would recommend reading a ton of BAAs. Find some online, read your own subcontractor BAAs, and see what differences there are and try to understand their intent in those decisions. Then work with your own lawyers and compliance on the right answers for your business.

But how do I know what is right for my business? How do I make sense of these timelines? Can I have BAAs and PLG? How does this work on a billion dollar deal? Why does some other vendor want to charge me $100K for signing a BAA? There is some nuance to this topic which I will cover in Part 2. Stay tuned.

1. For the sake of brevity, we’ll refer to Business Associates and Business Associate Subcontractors as “Business Associates” throughout this blog post. First, writing Business Associate fully is already pretty heavy. Writing BA felt like referring to Mr. T on the A-Team. Second, many Business Associate Subcontractors also serve as Business Associates depending on their business relationships (e.g. Microsoft/Google/AWS sells hosting to vendors and also to hospitals) so it’s really just a matter of who is holding who accountable and the responsibilities of the Covered Entity. The HITECH act codified that covered entities could trust Business Associates to trust subcontractors without covered entities having to enter agreements with each subcontractor down the chain individually. That doesn’t stop some health systems and Compliance and Security offices from trying though.

2. If a blog post is too long, you can’t email it to people and this is my current repository for all of my writing. I may make tweaks to this in the future which I will not update in the Google Doc.

3. Don’t do this.

4. Accessing the BAA for the Cloud Vendor in question requires an NDA. But there are only 3 major cloud vendors and it’s free to see all of their BAAs. You can figure it out. Also, I know Datica has been dead and gone for awhile. I feel like Erlich Bachman talking about Aviato when I bring it back up. But the open-source policies are good and they survive on as intended.

5. The applicable document here: https://www.federalregister.gov/documents/2019/04/30/2019-08530/notification-of-enforcement-discretion-regarding-hipaa-civil-money-penalties

6. This may sound unfeasible, but honestly most near misses I have been a part of all were semi-farcical. If they weren’t, you would have been anticipating them.

7. This probably would not end well for the Covered Entity.

8. A very non-zero number of times a customer would ask my company to disable encryption in their environment for some reason, usually boiling down to bad programming. We always said no.

9. The Datica BAA had pretty pragmatic terms on this. Basically, if you kept paying us we’d protect the data but if not we’d basically just dump your database and courier the encrypted disk to the address on file at cost if deletion was not acceptable. The latter never happened.