A FHIR server stores and serves FHIR resources. A FHIR platform is what you actually need to ship a health product: the server, plus identity, consent, provenance, isolation between customers, webhooks, documents, terminology and someone who keeps it running under GDPR. This guide lays out the difference and describes how Anpheros Platform fills each gap, so you can decide whether to build on it or run your own.
Server versus platform
Open-source FHIR servers (HAPI, for example) are excellent at the FHIR part: resources, search, validation, history. What they leave to you is everything around it:
| Need | A FHIR server | A FHIR platform |
|---|---|---|
| Resource storage, search, history | yes | yes |
| Who may read which patient | your code | consent built in |
| Who wrote each value | your code | Provenance on every write |
| Several customers on one system | your code | project isolation, pairwise ids |
| Patient-facing consent screen | your code | OAuth 2.1 + SMART on FHIR |
| Notifications to your app | polling | signed webhooks |
| Realistic test data | your fixtures | 30 synthetic patients per sandbox |
| Hosting, backups, GDPR, DPA | your ops team | included |
If you have an ops team, a compliance officer and six months, running your own server is a fine choice. If you have a product to ship, a platform is faster.
How Anpheros Platform is built
One FHIR R4 record per patient. 26 resource types, coded with LOINC, ICD-10 and ATC, validated on write. The strict FHIR API lives at /fhir/R4, with a CapabilityStatement at /fhir/R4/metadata, and a plain REST API at /v1 serves the same data with the same ids.
Project isolation and pairwise ids. A project (an API key) sees only the patients it created. Each project receives its own id for the same person; internal ids never leave the platform. References to patients outside your scope are masked with an opaque, per-project token.
Consent decides reads, ownership decides writes. With the patient's consent an organisation sees the whole record, including what other clinics wrote, but can change or delete only what it wrote itself. Every version of every resource records the project that wrote it; a write by another project is refused with an explanation.
Provenance and audit on every write. Provenance.agent.onBehalfOf names the clinic or organisation at the time of writing; an audit row records who, what, when, under which grant, from which application. The patient can read their access log, also as FHIR AuditEvent resources.
Thin, signed webhooks. Events carry ids and versions, never clinical content; you read the resource through the API. Deliveries are signed with HMAC-SHA256 and retried with backoff for up to 24 hours.
Sandbox and production are separate databases. A sk_test_ key cannot reach a real patient. The sandbox is free and self-service.
EU residency. Cloud Run in europe-west4, with a data processing agreement for production organisations.
What is deliberately not there
- No clinical decision support. The platform stores, codes and shares; it does not diagnose or recommend treatment.
- No full drug database with interactions. Medications are coded with ATC, and a bundled ATC and LOINC subset is available for lookup, but interaction checking is your component or a licensed service.
- No hospital-grade HL7 v2 messaging bus. There is an HL7 v2 ORU^R01 import for lab reports; there is no ADT or order management.
Knowing these limits up front saves a week of discovery.
When to run your own server instead
- You must host inside your own hospital network, with no external processor.
- You need FHIR R5 or profiles the platform does not implement.
- Your product is the FHIR server itself.
In every other case, start on the sandbox, measure, and decide with data. The first hour is described at developers.anpheros.com/guides/first-hour; the full API reference is at platform.anpheros.com/docs.
Frequently asked questions
Is Anpheros a FHIR server?
It contains one: a FHIR R4 API with 26 resource types, search, history, $everything, $summary, $validate and terminology operations. Around it are consent, provenance, isolation, webhooks and hosting, which is what makes it a platform.
Which FHIR version?
FHIR R4 (4.0.1), the version required by EU and US regulation and implemented by most systems. Conformance was checked with Inferno; see the IPS conformance notes.
Can several clinics share one patient's record?
Yes, that is the point. With the patient's consent each clinic reads the whole record and writes its own resources, each marked with its provenance. No clinic can alter what another wrote.
Is there a free FHIR backend for development?
Yes. The sandbox is free, self-service, and comes with 30 synthetic patients per project. See Free FHIR server: the sandbox.
How do I migrate away if I need to?
Everything is FHIR R4 and exportable: Patient/{id}/$everything returns a patient's whole record as a Bundle. There is no proprietary format to unpick.
Keep your medical record with you
Anpheros Daily keeps symptoms, lab results, medications and documents in one place, in a standard format, under your control. The Basic plan is free.