Managed vs self-hosted HIPAA hosting in 2026: FHIR servers and BAAs
TL;DR
Managed vs self-hosted HIPAA hosting in 2026 is a decision about who runs the servers and who signs which business associate agreement (BAA). Both routes can be compliant, and neither removes your own obligations. For FHIR, choose a managed platform, a cloud FHIR service in your account, or an open-source server you run.
- HHS treats a cloud provider that stores encrypted ePHI as a business associate even when it holds no decryption key.
- A developer hired to build or support software that handles PHI for a provider is a business associate, and its cloud vendor becomes its subcontractor.
- Microsoft retired Azure API for FHIR on September 30, 2026. A managed service ends when its vendor decides.
- The Security Rule update that would make you verify business associates' safeguards every 12 months is now projected for July 2027.
- Map your PHI data flow first, then sign BAAs along it.
Who counts as a business associate in a hosting stack
HHS's cloud computing guidance says a cloud provider that creates, receives, maintains or transmits ePHI for a covered entity is a business associate. That holds even if the provider stores only encrypted data and lacks the key, a setup HHS calls a no-view service. The same guidance says OCR does not endorse, certify or recommend specific products.
Developers sit in the same chain. HHS's health app scenarios make an app developer a business associate when a provider or health plan engages it to handle PHI on their behalf. A consumer app that a patient picks and fills on her own sits outside HIPAA. Once you are a business associate, every vendor that stores or moves that PHI for you is your subcontractor, and HHS's sample BAA provisions apply the same contract requirements to subcontractors.
OCR enforces this against software companies. On March 5, 2026 OCR settled with MMG Fusion, a business associate whose software communicates with patients of covered entities, over a breach affecting 15 million individuals. MMG paid $10,000 under a three-year corrective action plan; it was the twelfth action in OCR's risk analysis initiative.
2026 dates that change the hosting decision
September 30, 2026 is the date to remember. Microsoft retired Azure API for FHIR that day, after blocking new deployments from April 1, 2025, and told customers to move to the FHIR service in Azure Health Data Services. Teams that chose managed FHIR for zero operations got a migration project.
Three more dates frame the year. HHS raised HIPAA civil penalties on January 28, 2026, to a range of $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 for identical violations. The Security Rule rewrite proposed on January 6, 2025 would, as McDermott summarizes it, require written verification at least once every 12 months that business associates deploy certain technical safeguards. The firm reports that the 2026 Unified Agenda moved final action to July 2027. It is not law yet.
The CMS-0057-F fact sheet sets January 1, 2027 for impacted payers to implement the rule's API requirements.
How we put this comparison together
We read HHS guidance, the regulations and each vendor's BAA scope page in October 2026. Our patterns come from healthcare requirement records in our scoping notes. Any group with fewer than three data points is not published.
Mercury Development builds healthcare software, so read this as an interested engineering view. We are engineers, not lawyers: take contract terms to counsel.
Four hosting models at a glance
| Model | Example | Who runs servers and patches | BAA you sign for hosting | What stays yours |
|---|---|---|---|---|
| Managed HIPAA host | Single-tenant servers run by a specialist host | The host | The host's BAA | Application, users, risk analysis |
| Managed FHIR platform | Medplum hosted service | The platform vendor | The vendor's BAA | App logic, access policies, data model choices |
| Cloud FHIR service | AWS HealthLake, Azure Health Data Services, Google Cloud Healthcare API | The cloud provider for the service, you for the account | The cloud provider's BAA | Identity, network, logging, every service around the FHIR store |
| Self-hosted FHIR server | HAPI FHIR or Medplum on your cloud account | You | The cloud provider's BAA | Everything above the cloud's infrastructure |
What managed FHIR takes off your plate
A managed FHIR platform runs the server, the database, scaling, backups and patching, and signs a BAA for that layer. Medplum's pricing page is a useful public reference point: hosted production starts at $2,000 a month, premium at $6,000, with a standard BAA for hosted deployments.
You still own access rules, app logs and every service you call outside the platform. Microsoft's HIPAA page puts it bluntly: a BAA with Microsoft does not ensure your compliance, your program and your use of the services do.
The second risk is time: a managed service has a roadmap you do not control.
What self-hosting a FHIR server adds to your backlog
The software is the easy part. HAPI FHIR is open source under the Apache Software License 2.0, and Medplum releases its FHIR server under the same license, per its open source page. Medplum's own pricing page is honest about the rest: in enterprise self-hosting, your team handles ongoing operations, monitoring and on-call response.
That is your backlog: key management, audit logging, tested restores, tenant isolation for several clinics, and patching someone owns. Your only hosting BAA is with the cloud provider, so nothing sits between your configuration and the regulator.
Self-hosting pays off when control is the requirement, such as a hospital that wants the server in its own tenant.
The BAA chain for software developers
Draw the chain outward: provider or health plan, then you, then every vendor that touches PHI for you, from cloud and email to crash reporting. Each link needs its own agreement, signed before PHI moves.
The sample BAA provisions list the required terms: permitted uses and disclosures, safeguards, reporting of breaches and security incidents, flow-down to subcontractors, support for patient access and amendment, access for HHS, and return or destruction of PHI at termination. The breach clock is in 45 CFR 164.410: without unreasonable delay and no later than 60 calendar days after discovery.
Engineering has to make those clauses true. Return or destruction means a deletion path that reaches backups. Access support means you can find every copy of one patient's data.
How to check a vendor's own BAA chain before you sign is part of our guide on how to choose a healthcare software development company.
Where BAA coverage quietly ends
A cloud BAA covers named services, not your whole account. The AWS HIPAA Eligible Services Reference lets you use unlisted services in a HIPAA account only if they do not process or store ePHI. The AWS HealthLake FAQ adds that storing PHI on AWS requires a BAA, accepted through AWS Artifact.
Google is stricter in wording. Its HIPAA documentation lists Firestore, Identity Platform and the Cloud Healthcare API under the BAA, and tells you to disable unsupported services when working with PHI. No Firebase-branded product appears on that list. If your mobile app signs users in with Firebase Authentication, that sign-in path is outside the agreement even though Firestore is inside it.
The gaps are rarely the database. They are the logger and the crash reporter that receive a stack trace with a patient name in it.
What our healthcare requirement records show
We went through our healthcare requirement records that named HIPAA as a requirement. None of them mentioned a business associate agreement. HIPAA arrived as a requirement to meet, with no question attached about who signs what with whom.
Around 20% of them named the cloud or storage service the product would use at that stage. In the rest, hosting was still open while scope was priced.
HL7 FHIR did not appear as a stated requirement in any of our healthcare records. Where EHR integration came up, buyers named the system they already used or pushed integration past the first release; a medical device maker said going into an EHR was probably beyond the scope of an MVP.
One buyer wrote that HIPAA compliance "must be documented." In another project we flagged ambiguity in the HIPAA technical implementation as a delivery risk before the build, because nobody had decided where the boundary of PHI sat.
Why the EHR connection can wait past the first release is covered in our EHR integration MVP guide.
Which hosting model fits your product
- Early product, one cloud, no hospital buyers yet: a managed FHIR platform or a cloud FHIR service under your cloud BAA, with an export path tested in the first sprint.
- Product that already runs on AWS, Azure or Google Cloud: the cloud's own FHIR service in your account, with only listed services touching PHI.
- Health system buyers with strict security reviews: self-hosted or single-tenant, deployable into the customer's tenant.
- Small team, no one on call: a managed HIPAA host or managed FHIR platform, and keep the risk analysis in-house.
- Consumer app the patient chooses and fills herself: HIPAA may not apply, but check the FTC's Health Breach Notification Rule before you assume nothing does.
If EU patients or the VA are on the buyer list, regions and hosting limits are covered in our guide to healthcare data residency.
Rent the operations, keep the exit
Our view: rent the operations if your team cannot staff on-call, but never rent the exit. Keep your FHIR resources standard, test a bulk export and restore before launch, and keep a written map of every service that touches PHI with the BAA that covers it. Then the next retirement notice becomes a planned project.
Precision Practice Management started as a HIPAA compliant client-server system on MS SQL and C#.NET in secure data centers, and later releases moved its architecture to cloud and SaaS technologies; it is on its fourth major release since 2006. EyeIC moved a 510(k) cleared imaging application from the desktop to the web with HIPAA-compliant online access. Our AI agent work deploys inside a customer VPC or on premises when required. We build to HIPAA and GDPR requirements, and per our company page all work is work-for-hire, with the customer owning the code and all underlying IP.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The requirement records and architecture notes behind this article's hosting comparison come from scoping work in the practice he leads.
Send us your data flow and we will mark every BAA it needs
Tell us what your product stores, which cloud services it calls and who your buyers are. We will trace where PHI travels, mark each link that needs a business associate agreement, and show which parts of the stack a managed service would run for you and which stay yours.