How Anpheros compares with other FHIR servers
Self-hosted FHIR servers, cloud FHIR stores, open-source healthcare platforms and Anpheros side by side: who authorises access, consent, provenance, residency, pricing, and when each is the right choice.
Teams choosing a FHIR backend usually weigh four kinds of option: an open-source server they host themselves, a managed FHIR store from a cloud provider, an open-source healthcare platform with a hosted edition, or a managed healthcare database like Anpheros. This guide describes what each kind is good at and where Anpheros sits, based on public documentation as of October 2026. For any product named here, check its own documentation; features change.
The four kinds
| Self-hosted FHIR server (e.g. HAPI FHIR) | Cloud FHIR store (e.g. Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake) | Healthcare platform (e.g. Medplum) | Anpheros | |
|---|---|---|---|---|
| What it is | a FHIR server you run | a FHIR data store inside a cloud account | a FHIR-native application platform with auth, workflows and a hosted edition | a managed healthcare database: FHIR R4 record per patient, consent, API, audit |
| Who authorises access | whatever you build around it | the cloud's IAM, per project or dataset | the platform's access policies, configured by you | the patient (OAuth 2.1 consent) or the organisation (API key) |
| Patient-facing consent and audit | no | no | buildable with its policy model | built in, visible to the patient |
| Provenance on every write | if you add it | if you add it | supported by FHIR; you enforce it | required and automatic |
| Identifier isolation between applications | no | no | no | pairwise ids per application |
| Lab import (HL7 v2) | separate tooling | partial (v2 to FHIR mapping in some stores) | integrations you write | built in, one request |
| Data residency | wherever you host it | the regions the provider offers | depends on hosting | European Union only |
| Pricing | your infrastructure and time | usage-based (requests, storage) | per plan or self-hosted | per organisation, by stored patients |
| Best for | learning, full control, unusual data models | teams already in that cloud who will build the healthcare layer themselves | teams who want to build on an open codebase and own the full stack | teams who want the healthcare layer done and the product as their work |
Where Anpheros is the right choice
- You are building a product for patients, clinics, laboratories or AI, and you want to write the product, not the record.
- Patient consent and an audit the patient can read are requirements, not nice-to-haves (GDPR Article 9, EHDS).
- Your data must stay in the European Union.
- You want FHIR R4 but also a simpler REST view, SDKs and webhooks, from one vendor.
- You want to start free, in a sandbox with realistic synthetic patients, and move to production without rewriting.
Where another option is better
- You need FHIR resource types, profiles or extensions outside the 26 that Anpheros supports, or a fully custom data model: a self-hosted server gives you that freedom.
- Your organisation requires everything inside one cloud account for compliance reasons: a cloud FHIR store fits that policy.
- You want to own and modify the entire stack, including the authorisation server and UI components: an open-source platform is designed for it.
- You need EHR launch, Bulk Data export or
system/scopes today: Anpheros does not offer them yet (see SMART on FHIR backend).
A fair way to decide
Count the parts of the healthcare layer your product needs, consent, provenance, audit, identifiers, lab import, document storage, residency, and estimate the months to build and maintain each one on the option you prefer. Then compare that with the product work those months could have gone to. Anpheros is the right answer when the second number is larger.