A problem we’re trying to solve is “how to make it easier to run healthcare apps on Fly.io”? Thus far, the clearest approach has been “Simplify the BAA process”. Doing that has proven challenging, but that’s not surprising.
To summarize for non-healthcare-ians as best I can, a “Business Associate Agreement” (“BAA”) is a legal agreement between a “covered entity” who collects “Protected Health Information” (“PHI”) and a vendor that process that information (the “business associate”). Basically, it says that the covered entity and the BAA recognize that PHI is changing hands and that the PHI will be protected, won’t be misused, and establishes guidelines and penalties in the event something goes wrong. Additionally, it requires that business associates to have “downstream” BAAs with their vendors as well if those vendors will handle the PHI. Makes sense, kind of like NDAs: if I tell you something secret, you can’t share it with someone else unless you have a good reason to AND they’re under NDA as well. So your doctor’s office (the covered entity) has a BAA with their appointment scheduling service and the appointment scheduling service, which is running on Fly.io, has a BAA with us. Easy, right?
Here’s where it gets tricky: at Fly.io we’re not looking to provide every possible solution for developers. Rather, we want to be one member among a consortium of specialized providers. We call those fellow consortium-members “extensions” but you know them as “Tigris” or “Supabase” or “Sentry”.
So let’s say you’re running that appointment scheduling service, you have a BAA with Fly.io, and you want to take advantage of Sentry’s application monitoring. Great, but do you need a BAA with Sentry now? You ran flyctl ext sentry create and agreed to the terms, you’re not sending any money to Sentry, so is the BAA with Fly.io enough? What happens if/when you exceed the plan limits and upgrade to the paid version? Do you need a BAA then?
To be safe, you decide to get a BAA with the extensions providers you use, so you reach out to Sentry…and Tigris…and Supabase…and on and on and on. Sounds like friction. We hate friction. So we’re working with our lawyers to see about if we can tailor our agreements with current (and upcoming!) extension providers so that you can have O(1) vs. O(n) BAAs.
We take on a bit more liability this way but that’s ok: we wouldn’t partner with a vendor we had even the slightest qualm about. Though something that does complicate matters is the flow of money varies depending on extension provider: maybe Fly.io pays a bit to the extension provider, maybe the customer does, maybe there’s a rev share, whatever. While there’s no hard-and-fast guidelines, if the Office for Civil Rights (who investigates HIPAA complaints) disagrees that a subcontractor relationship was formed between Fly.io and an extension provider, it would be a paperwork nightmare. So we’re moneygunning the lawyers to make sure that doesn’t happen.
Said lawyers are still trying to make it work, though they’re not 100% it’s doable, in which case we’ll explore other options such as “can we be allowed to execute a BAA on behalf of a provider” or “is it ok for downstream providers to automate signing of BAAs that we pre-populate”? Ultimately, it’s not a technical problem (we’re good at solving those) but rather a legal one and that’s harder for us to judge. It’s a work in process- stay tuned.
Until we get this sorted, you’ll likely need to get BAAs from the extension providers you want to use, in addition to a BAA from Fly.io. If you are on a BAA-eligible plan (Scale, Enterprise) and need help with BAAs just reach out to us using the dedicated support email address available in your console and I’ll help you get things sorted.