Self-hosted or managed is the second-most-important question a US hospital IT team has to answer when picking a FHIR server, right after which vendor they shortlist. The choice changes operational burden, cost structure, vendor lock-in posture, and how fast new use cases can ship. Neither answer is universally right. The honest analysis depends on staffing, on existing infrastructure, and on how core FHIR is to the hospital's plans for the next three years.
For broader context on the vendor side, the 2026 Buyer's Guide to FHIR Servers sets up this decision, and the FHIR learning path is the place to come back to for more.
What Self-Hosted Actually Costs
Self-hosted means your hospital IT team runs the FHIR server on infrastructure you control, whether that is bare metal, VMs, or a Kubernetes cluster. The license fee is either zero (open-source like HAPI or Medplum) or modest (self-hosted enterprise editions). The real cost is people. A self-hosted FHIR server needs someone who can keep it patched, scale it under load, debug obscure indexing problems, and respond to incidents. In a US hospital, that is rarely less than one full-time engineer, often two.
The benefit is control. Self-hosted gives you the ability to tune for your workload, integrate deeply with internal systems, and avoid the vendor cost curve that managed offerings tend to follow.
What Managed Actually Costs
Managed means the vendor runs the FHIR server for you. You pay a recurring fee, configure the server through an admin interface, and let the vendor handle patching, scaling, and the worst of the operations work. Aidbox, Smile Digital Health, Medplum, Microsoft Azure Health Data Services, and Google Cloud Healthcare API all sell managed offerings in 2026. The cost ranges widely, but in US hospital procurement budgets, managed is typically twice to four times the self-hosted alternative when you count people honestly.
The benefit is time saved. Managed offerings remove most of the late-night-page burden and let your engineering team focus on building applications instead of running the platform underneath them. For hospitals where FHIR is one of many priorities, managed pays off.
Hybrid: The Most Common Pattern in 2026
Many US hospitals in 2026 run a hybrid. They self-host the FHIR server for the cost savings and customization, but they use a managed terminology service for $expand and $validate-code because building a high-performance terminology cache is its own engineering project. This pattern works well with HAPI, Medplum, and several others. The Top 7 open-source FHIR servers for American hospital IT lays out the candidates for the self-hosted part, and the HAPI vs Aidbox vs Medplum comparison covers the head-to-head that comes up most.
Compliance Considerations
Both models can satisfy HIPAA and ONC requirements, but the work is different. Self-hosted means your compliance team has to verify your operational practices directly. Managed means your compliance team has to verify the vendor's BAA, SOC 2, and HITRUST status. Most managed vendors have these in place for US healthcare in 2026, which removes a chunk of effort. Some of the audit burden simply moves from your team to a vendor review process.
A Way to Decide
If your hospital has FHIR engineering depth and wants to own the stack, self-hosted is usually right. If FHIR is a means to an end and you would rather buy than build, managed is usually right. If you are in between, hybrid is the answer most teams converge on in 2026. The proof-of-concept stage is where this question gets settled, not the RFP stage, because the operational reality only shows up when you actually try to run the thing under your real workload.
Sources
Related Posts
