The best digital health backend for a European startup is the one that keeps patient data in an EU region, gives you a standard FHIR API, and lets a small team ship a first app without running servers. In practice the shortlist is a managed FHIR platform (Ovok, Medplum, Aidbox), a hyperscaler FHIR store (Google Cloud Healthcare API, AWS HealthLake, Azure Health Data Services), or self-hosting HAPI FHIR. This guide compares them on the criteria that matter for an EU team and ends with a "which to choose if…" verdict for each.

Key takeaways

Start with data residency: confirm an EU hosting region for the exact service you will use, not just for the vendor's cloud.
A FHIR backend for Europe still needs a GDPR Article 28 data processing agreement, an audit trail and clear sub-processor terms. Ask for all three before you write code.
Hyperscaler FHIR stores give you a standards-compliant data layer; you still build identity, app-level access rules, device ingestion and SDK glue yourself.
Developer platforms (Ovok, Medplum, Aidbox) add authentication, access policies and SDKs on top of FHIR, which shortens time to a first app.
Medical-device regulation (MDR) follows your product's intended purpose. Choosing a backend does not make your app certified or uncertified.
Compare pricing on the unit you actually grow by: per patient, per request, per hour or per GB.

How we compared the options

Every vendor below is a reasonable choice for someone. To keep this fair, we checked each product's official site and documentation in October 2026 and only list what we could verify. Where a vendor page did not state something (for example a hosting region), we say so instead of guessing. Pricing and regions change, so treat every number here as "as of October 2026" and follow the links.

These are the criteria a European digital-health startup usually cares about:

EU data residency: can the data live in an EU region, and which one?
GDPR posture: data processing agreement (DPA), audit logging, where the operator is based.
Managed vs self-hosted: who patches, scales and backs up the FHIR server?
FHIR version and compliance: R4 is the production default; some servers add R4B, R5 or older versions.
Auth and access control: patient and practitioner sign-in, SMART on FHIR, fine-grained policies, multi-tenancy.
SDKs and developer experience: client libraries, UI components, example apps, sandbox.
Device and remote-monitoring support: Bluetooth devices, HealthKit and Health Connect, ingestion of connected-device data.
Regulatory scope (MDR): which parts, if any, carry a medical-device status.
Pricing transparency: is there a public price, and what is the billing unit?
Time to first app: how quickly a two-person team can show a working patient flow.

If you are new to the standard itself, read What is FHIR? first, and our FHIR API search guide once you start querying data.

The options at a glance

Ovok

Ovok is a FHIR R4 backend for digital health apps, an Actimi product. It is aimed at teams building remote-monitoring and connected-device products.

EU residency: the pricing page lists AWS Frankfurt hosting on every plan, from the free Developer plan to Enterprise. A dedicated single-tenant deployment can run in Ovok's AWS Frankfurt account or in your own AWS account.
GDPR: every paid plan includes a data processing agreement under GDPR Article 28, and pricing lists a FHIR audit trail on every plan.
FHIR and APIs: FHIR R4 over REST and GraphQL, plus higher-level care APIs.
Auth and access: tenant authentication for patients and practitioners (PKCE, optional multi-factor sign-in) and Access Policies for resource-level authorization. Projects and sub-tenants support multi-tenant products.
SDKs: a React SDK (@ovok/core) and a React Native SDK (@ovok/native), plus public example RPM repositories for a patient app, clinician dashboard and clinic EHR.
Devices: 50+ supported devices through the Native SDK, including blood-pressure monitors, sleep radars, SpO₂ monitors, urine analysers and wearables, and documented HealthKit and Health Connect imports.
Regulatory scope: Signals, an optional alert-evaluation component for enrolled patients, is MDR Class IIa. Ovok itself is not a certified medical-device product, and an app built on Ovok does not inherit Signals' status.
Pricing: priced per monitored patient, in EUR excluding VAT. Developer is €0 with 50 test monitored patients and 10,000 API requests per month; Growth is €2,000 per month billed annually (250 monitored patients); Scale is €6,000 per month billed annually (1,000 monitored patients). Eligible startups get 50% off Growth for the first 12 months.

Strong for: EU startups building monitoring products who want hosting, devices and FHIR in one place. Trade-off: it is opinionated toward remote monitoring and patient apps; if you only need a raw FHIR store for analytics, a hyperscaler may be simpler.

Medplum

Medplum is an open-source healthcare developer platform under the Apache 2.0 license, written in full-stack TypeScript, with a client SDK and React component library.

Managed vs self-hosted: both. The pricing page lists cloud plans (Free at $0, Production at $2,000 per month, Premium at $6,000 per month, Enterprise on request) and a free self-hosted Community option, as of October 2026.
EU residency: the pricing page does not state a hosting region for the cloud plans. Self-hosting lets you choose your own EU region.
Compliance: the pricing page lists a standard BAA, MSA and SOC 2 on several tiers; it does not mention GDPR.
Auth and access: access policies are included (the number depends on the tier); Bots for server-side logic are available on paid cloud plans.

Strong for: TypeScript teams who want an open-source platform they can self-host in the EU or run on a managed US-style compliance stack. Trade-off: confirm the cloud region and EU contract terms directly before storing EU patient data in the hosted service.

Aidbox (Health Samurai)

Aidbox is a FHIR server and platform from Health Samurai. Its product page lists FHIR R4 and R5 support, SMART on FHIR and OAuth2/OpenID Connect, Subscriptions, SQL on FHIR, bulk data and terminology services.

Deployment: the Aidbox documentation covers running it in a sandbox, locally, on AWS, on Kubernetes (with Helm), on Azure Container Apps and on GCP Cloud Run, on PostgreSQL. That makes it straightforward to place in an EU region you control.
Access control: Access Policies are a documented, first-class feature.
Pricing: the price page lists a free Development license, pay-as-you-go Production and custom Enterprise pricing, without public numbers, as of October 2026.

Strong for: teams with infrastructure skills who want a feature-rich FHIR server with R5 support and full control over where it runs. Trade-off: you own operations, and pricing requires a sales conversation.

Google Cloud Healthcare API

Google's managed FHIR store supports DSTU2, STU3 and R4 and can publish changes to Pub/Sub.

EU residency: the regions page lists europe-north1 (Finland), europe-west2 (London), europe-west3 (Frankfurt), europe-west4 (Netherlands), europe-west6 (Zurich) and an eu multi-region, as of October 2026.
Pricing: usage-based; see the pricing page.

Strong for: teams already on Google Cloud who need a scalable FHIR data layer feeding analytics (BigQuery, ML). Trade-off: patient sign-in, app-level authorization, device ingestion and SDKs are yours to build.

AWS HealthLake

AWS HealthLake is a HIPAA-eligible FHIR R4 data store with SMART on FHIR authorization, bulk export, integrated medical NLP and SQL access through Athena.

EU residency: the HealthLake FAQ lists London and Ireland among its regions, as of October 2026. Frankfurt is not on that list.
Pricing: the pricing page charges per data-store hour while the store runs ($0.27 per hour, including the first 10 GB), plus storage and queries above the included amounts, as of October 2026.

Strong for: analytics-heavy and data-conversion use cases on AWS, especially if you have unstructured clinical text. Trade-off: an always-on hourly charge from day one, and the application layer is still yours.

Microsoft Azure Health Data Services

The FHIR service in Azure Health Data Services is a managed PaaS with SMART on FHIR, Microsoft Entra ID role-based access control and audit logging. It supports FHIR 4.0.1 and 3.0.2.

EU residency: the regional availability page lists France Central, Germany West Central, North Europe, Sweden Central, Switzerland North, West Europe, UK South and UK West for the FHIR service, as of October 2026.
Note: Microsoft deprecated the older Azure API for FHIR on September 30, 2026, so new projects should use the FHIR service.
Pricing: usage-based on storage and API requests, with a monthly free allotment.

Strong for: organisations standardised on Microsoft identity and Azure, and the widest choice of EU regions among the hyperscalers. Trade-off: Entra ID is built for workforce identity; patient-facing sign-in and app logic need extra work.

HAPI FHIR and self-hosting (the DIY option)

HAPI FHIR is an Apache 2.0 Java implementation of FHIR, with a JPA server you can deploy against your own database. It covers DSTU2 through R5.

Strong for: teams with Java and DevOps capacity who need total control, custom extensions or on-premise deployment for a hospital partner. Trade-off: you own uptime, security patching, backups, scaling, authentication and audit. That is real, ongoing work for a startup.

Criteria deep dive: what actually changes your decision

1. EU data residency is per service, not per cloud

Every hyperscaler has EU data centres, but not every healthcare service runs in all of them. HealthLake's listed EU regions are London and Ireland; Google's include Frankfurt and an EU multi-region; Azure's FHIR service lists eight European regions. If your hospital customer insists on Germany, check that the specific FHIR service runs there. Ovok lists AWS Frankfurt for every plan.

You will be the controller (or a processor for a clinic) and your backend vendor will be your processor. Before production, ask for:

A GDPR Article 28 data processing agreement.
The list of sub-processors and where they are located.
An audit trail of who read or changed which resource.
Your own legal review of international transfers, especially if the provider is headquartered outside the EU.

None of the vendors above removes the need for your own data protection impact assessment.

3. Managed vs self-hosted changes your headcount

Self-hosting HAPI FHIR or Aidbox gives you control and can be cheap in infrastructure, but it adds on-call duty, patching and backup testing. A managed platform moves that work to the vendor. For a team of two to five engineers, operational load is usually the deciding factor.

4. A FHIR API is not an application backend

Hyperscaler FHIR stores are excellent data layers. What they leave to you is everything around the data: patient registration and sign-in, per-patient authorization, sub-tenants for each clinic customer, file storage, email, push notifications and device ingestion. Platforms like Ovok, Medplum and Aidbox bundle more of this. Make a list of the services your first release needs and check which ones each option covers.

5. Devices and remote monitoring

If your product reads blood pressure, SpO₂ or weight from patients at home, device support is often more work than the FHIR store. Ovok's Native SDK documents 50+ supported devices and HealthKit/Health Connect imports that save records as FHIR Observations. With a hyperscaler or HAPI FHIR, plan for your own Bluetooth layer or a separate device-data vendor. Our guide to the best remote patient monitoring platform covers this in more depth.

6. MDR scope follows intended purpose

Under the EU Medical Device Regulation, software that drives clinical decisions or monitors physiological processes can be a medical device. The classification depends on what your product claims to do, not which database it uses. Ovok's Signals component is MDR Class IIa; Ovok itself is not certified, and your app's regulatory status depends on its own intended purpose. Get regulatory advice early.

7. Real-time features

Clinician dashboards and patient apps often need live updates. FHIR Subscriptions over WebSockets or rest-hooks avoid constant polling. Support varies: Google publishes changes to Pub/Sub, Aidbox and Medplum document Subscriptions, and Ovok supports WebSocket Subscriptions as a project feature. See our guide to real-time FHIR subscriptions.

8. Pricing units decide your unit economics

Per monitored patient (Ovok): costs scale with the revenue-generating unit in most RPM business models.
Flat monthly tiers (Medplum cloud): predictable, independent of volume within a tier.
Per hour, GB and request (hyperscalers): cheap at tiny scale, harder to forecast, and HealthLake charges while the data store runs.
Self-hosting: infrastructure plus the engineering time to run it.

Model twelve months of growth on each before you commit.

Which to choose if…

You are an EU startup building a remote-monitoring or connected-device product and want to ship fast: Ovok. Frankfurt hosting, a DPA on paid plans, devices, SDKs and FHIR R4 in one place, with a free Developer sandbox.
You want open source you can self-host in your own EU region, in TypeScript: Medplum Community, or Medplum cloud once you have confirmed region and contract terms.
You need R5 features or want maximum control of a feature-rich FHIR server on your own infrastructure: Aidbox.
You are already on Google Cloud and need a FHIR data layer for analytics: Google Cloud Healthcare API in europe-west3 or the eu multi-region.
You process large volumes of unstructured clinical text on AWS: AWS HealthLake in London or Ireland.
Your customers are Microsoft shops or you need a specific EU country region: Azure Health Data Services FHIR service.
You have strong Java and DevOps skills, or a hospital requires on-premise: HAPI FHIR, self-hosted.

A practical evaluation plan for a two-week spike

Write down your first release: users, data types, devices, integrations.
Shortlist two options from the verdicts above.
On each, create a patient, write an Observation, search it back and enforce one access rule. Our FHIR API search guide helps with the queries.
Connect one real device or HealthKit/Health Connect source if your product needs it.
Request the DPA, sub-processor list and region confirmation in writing.
Model costs at 100, 1,000 and 10,000 patients.

FAQ

What is a FHIR backend?

A FHIR backend is a server that stores healthcare data as FHIR resources and exposes the standard FHIR REST API (and sometimes GraphQL). Apps read and write Patients, Observations and other resources through it instead of a custom schema.

Which FHIR backends can host data in Germany?

As of October 2026, Ovok lists AWS Frankfurt on every plan, Google Cloud Healthcare API lists europe-west3 (Frankfurt), and Azure Health Data Services lists Germany West Central. Self-hosted HAPI FHIR, Aidbox or Medplum can run in any German region you choose.

GDPR compliance depends on your contracts, configuration and processes, not on a product alone. All major clouds offer EU regions and data processing terms; you still need your own legal review, especially on international transfers.

Do I need FHIR R5?

Most production systems and national profiles still use R4. Choose R5 support only if you need specific R5 features, such as topic-based subscriptions without the backport. Many R4 servers support those through the subscriptions backport.

Does using Ovok make my app a certified medical device?

No. Signals, an optional component for enrolled patients, is MDR Class IIa. Ovok itself is not a certified medical-device product, and your app's regulatory status depends on its own intended purpose.

How long does it take to build a first app?

With a managed platform, SDKs and a sandbox, a small team can usually show a working patient sign-in and data flow within days. Self-hosting adds infrastructure work before you write any product code.

Conclusion

There is no single best digital health backend for every European startup. There is a best fit for your product, team and region. If your product is about patients, devices and remote monitoring, and you want EU hosting without running a FHIR server, try the free Developer sandbox, read the Ovok docs, and compare the startup program and pricing against the alternatives above.