One backend for compliant medical pipelines
FHIR R4 over REST and GraphQL, access control that survives an audit, and a pathway engine with a governed lifecycle. Self-hosted, managed, or hybrid.
Versioned clinical pipelines with governed publication
A care pathway is a state machine over FHIR resources: states, transitions, entry actions, timeouts. Upload one as a draft, move it through review, and publish it by recording a sign-off. Every version is immutable and checksummed; the registry is the source of truth and everything downstream is a projection of it.
- Lifecycle: draft, review, active, deprecated, retired
- One active version per pathway, enforced by database constraint
- Sign-off recorded against a named person, with full history
- Retire fails closed while runs are in flight
- Server-rendered state diagram — no client-side rendering, no YAML shown
- Run timelines assembled from FHIR AuditEvents
- JSON evidence-bundle export per run, QMS export per pathway
FHIR R4, and the systems that are not FHIR yet
Native FHIR R4 over REST and GraphQL, SMART on FHIR and OAuth 2.0 for access, and adapters for the legacy sources every real deployment still has. Your pipeline runs unchanged against any conformant server.
- FHIR R4 REST and GraphQL APIs
- SMART on FHIR and OAuth 2.0 with JWT
- Legacy systems, analytics stores and external APIs alongside FHIR
- A per-project API playground for exploring queries against real data
- Webhooks and event-driven triggers on FHIR resource changes
Access control you can explain to an auditor
Role-based access control down to the individual operation, with compartment-based isolation so a role sees only the records it is scoped to. Configuration changes are staged and autosaved as you work, then go live only when you publish — the stage-then-publish discipline the pathways use.
- Per-operation permissions with pluggable validators
- Compartment-based isolation between roles
- Tenant isolation enforced at the API, not just the query
- Changes staged and published deliberately, never silently
- Unknown role, operation or validator is rejected outright, not ignored
- Team and organisation management, API keys, and device registration
Know what your data is doing
Per-project dashboards over the resource types you choose to track, with FHIR-native analytics and execution metrics for every pipeline run.
- Per-project tracked resource types
- Pipeline execution metrics and operational insight
- Device registration, including worker devices and AI agents
- Full audit log for every operation
Ready to use, not ready to build
The connectors most healthcare products need on day one, already wired into the platform and covered by the access control and audit trail that govern everything else.
SMART on FHIR
Standards-based app launch and authorisation against any conformant server.
GraphQL API
A complete schema over all FHIR R4 resources, generated and never hand-maintained.
Python FHIRPY
Pythonic FHIR resource management for backend and data work.
File uploads
Pre-signed blob upload, referenced from Media or DocumentReference resources.
Elasticsearch
Full-text and faceted search across resources, beyond native FHIR search.
Twilio
SMS and voice for appointment reminders and patient messaging.
SendGrid
Transactional email for clinical and operational notifications.
Stripe
Billing and payment flows for products that charge patients or providers.
Maps and geocoding
Location lookup for facilities, catchment areas and field visits.
Bluetooth and wearables
Device data capture, including Apple HealthKit and registered worker devices.
Talk to it in your language
Typed clients for the two languages most healthcare integration work happens in. Both read the base URL from the environment, so no host is hardcoded, so one build runs against local, staging and production.
JavaScript SDK
Browser and Node.js
import { MedBackendClient } from '@medbackend/client';
const client = new MedBackendClient({
baseUrl: process.env.MEDBACKEND_URL,
token: process.env.MEDBACKEND_TOKEN,
});
// FHIR R4 resources, typed
const patients = await client.patients.search({
family: 'Muller',
_count: 20,
});Python SDK
Pythonic FHIR resource management
import os
from medbackend import MedBackendClient
client = MedBackendClient(
base_url=os.environ["MEDBACKEND_URL"],
token=os.environ["MEDBACKEND_TOKEN"],
)
# FHIR R4 resources, typed
patients = client.patients.search(family="Muller", _count=20)From project to running pathway
What the first afternoon looks like. Nothing to stand up on the managed plan; self-hosted follows these steps after deployment.
-
01
Create a project
A project is the tenant boundary. It carries its own FHIR endpoint, configuration and audit trail, isolated from every other project.
-
02
Connect your FHIR store
Point the project at a FHIR R4 server, or use the managed one. Existing data stays where it is — this is middleware, not a migration.
-
03
Define roles and permissions
Set per-operation permissions and compartment isolation. Changes are staged as you work and go live only when you publish.
-
04
Register your application
Create API keys or register a device — including worker devices and AI agents — and authorise via SMART on FHIR or OAuth 2.0.
-
05
Upload a care pathway
Upload a definition as a draft, move it through review, and publish it by recording a sign-off. The sign-off is the publish.
-
06
Watch it run
Runs assemble into timelines from FHIR AuditEvents. Export any run as an evidence bundle when someone asks what happened.
Deploy it where your data has to live
Self-hosted
On-premise or your own private cloud, under your control.
Managed
Multi-tenant SaaS, Swiss-resident end to end.
Hybrid
Managed control plane over FHIR servers and data stores you already run.
Pricing
Pricing depends on deployment shape, data volume and support level, so we quote per project rather than publish a tier list. Tell us what you are building and you get concrete numbers.
What we are building next
Planned work, not shipped capability. Listed so you can tell what exists today from what is coming — and tell us which of it matters to you.
AI-assisted configuration
Agents that propose project, role and pathway configuration from a high-level description, with a human sign-off before anything goes live.
Shared pathway library
Publish a pathway once and let another organisation adopt and version it — the Medical GitHub model across tenants, not just within one.
Deeper analytics
Population-level and cohort reporting over FHIR-native data, without exporting a copy first.
Broader terminology coverage
Expanded SNOMED CT and vaccine support through the terminology service.
Questions we get asked
Can I still call the FHIR REST API directly?
Yes. MedBackend is middleware, not a replacement. With valid credentials you can keep issuing standard REST queries against the underlying FHIR server, and existing integrations keep working.
Which FHIR version do you support?
FHIR R4, over both REST and GraphQL. Some logic is adapted from R5 resources where R4 has a gap.
Is it multi-tenant?
Yes. One deployment can host multiple organisations and sub-organisations, separated by roles and compartments. Tenant isolation is enforced at the API layer, not only in the query.
How does file storage work?
Files upload to blob storage through a pre-signed URL, then get referenced from Media or DocumentReference resources via a secure link. Large binaries never pass through the FHIR server itself.
How is a care pathway published?
By recording a sign-off against a named person. That sign-off is the transaction: it writes the immutable version, flips the registry and republishes configuration in one ordered operation.
What happens if I retire a pathway that is still running?
The retire is refused. Retiring a pathway with runs in flight would strand them, so it fails closed and tells you what is still active.
Can I self-host?
Yes — on-premise or in your own private cloud, at full parity with the managed platform. Hybrid works too: a managed control plane over FHIR servers you already run.
Where is data stored on the managed plan?
Switzerland. Compute runs on Infomaniak OpenStack; the FHIR store, databases and object storage run in Azure Switzerland North. Both are Swiss regions, so clinical data does not leave the country — and residency is a deployment property you can point at rather than a promise in a brochure.
Who processes data alongside you?
Infomaniak hosts the compute in Switzerland. Microsoft Azure provides the FHIR service, database and object storage, pinned to the Switzerland North region. Both are named in the data processing agreement, and the FHIR store is being moved onto Swiss-operated infrastructure — ask us for the current sub-processor list before you sign anything.
Ready to stop rebuilding clinical logic you have already written?
Walk through your integration surface with us and see what a versioned, signed-off pipeline would look like in your environment.