Who this is for
Four kinds of team, four different starting problems, one backend underneath. Find the one that sounds like your week.
The four conversations we keep having
One of these usually sounds familiar.
Providers and hospital IT
Clinical workflows are encoded in a dozen places and no two departments run the same version.
Standardise a pathway once, sign it off, and roll it out across sites with a version history you can point at during review.
Medtech and digital health
The compliant backend is a year of work before the product is a product.
Start on FHIR-native infrastructure with access control, audit and tenant isolation already in place, and spend the year on what makes you different.
Clinical research
Study logic is reimplemented per site, and proving what ran is a manual reconstruction.
Run one versioned pipeline at every site and export an evidence bundle per run, so the record is never reconstructed afterwards.
System integrators
Every client is a bespoke integration that only you can maintain.
Build pathways once and deploy them across clients, with the differences held in configuration, not in forked code.
Three things you get on day one
Whichever way you arrive, the platform underneath does not change. These are the parts most teams are trying to avoid building.
A FHIR-native backend
FHIR R4 over REST and GraphQL, with adapters for the legacy sources a real deployment still has to read.
Secure by default
Tenant isolation at the API layer, encryption in transit and at rest, and a FHIR AuditEvent written for every operation.
Access control down to the operation
Per-operation roles and compartment isolation, configured before the first record is written rather than retrofitted after.
The four problems everyone solves twice
Almost nobody sets out to build healthcare infrastructure. They set out to build a product, then lose two quarters to four problems every other team in the sector has already solved in private, from scratch.
- Governance you have to design before you can write a line of clinical logic
- Integrations that drift the moment the other side ships a change
- FHIR mapping rebuilt per project because the last one was never reusable
- Authentication and permissions scattered across services that each guess
Where this sits against the alternatives
Categories, not named products, because the honest comparison is between approaches. Every row below is something you can verify in a trial.
| Capability | MedBackend | Traditional EHR | General-purpose backend |
|---|---|---|---|
| FHIR R4 as the native data model | Yes | No | No |
| Self-hosted, managed or hybrid | Yes | No | Partial |
| Per-operation roles and compartment isolation | Yes | Partial | No |
| Clinical pipelines versioned like packages | Yes | No | No |
| Publication gated by a recorded sign-off | Yes | Partial | No |
| Audit evidence exportable per run | Yes | Partial | No |
| Typed SDKs and a generated GraphQL schema | Yes | No | Yes |
| Data readable by anything speaking FHIR on exit | Yes | No | No |
Three rows from the previous version of this table are gone. “Open source” was inaccurate — the repositories are private. “100% FHIR compliant” overstated what anyone can attest to; the accurate claim is that FHIR R4 is the native model. And a cost comparison priced competitors we never benchmarked.
What every deployment starts with
These are in place on day one. You configure them; you do not build them.
A tenant boundary that holds
Each project carries its own FHIR endpoint, configuration and audit trail. Isolation is enforced at the API layer, not left to query discipline.
Permissions before data
Per-operation roles and compartments are configured first, so the first record written is already governed.
A record of what happened
Every operation writes a FHIR AuditEvent. When somebody asks what changed and who approved it, the answer is a query, not an archaeology project.
An exit that exists
Standard FHIR R4 throughout. Your data stays readable by anything that speaks FHIR — including after us.
Creating a patient, two ways
The first thing every integration does, in both interfaces you get: GraphQL over FHIR R4, and the typed Python client.
Create a patient
Generated schema across all FHIR R4 resources
mutation CreatePatient($input: PatientCreateInput!) {
createPatient(resource: $input) {
id
name {
given
family
}
meta {
lastUpdated
}
}
}The equivalent, typed
Async client with token refresh
import asyncio
from medbackend.auth import get_access_token
from medbackend.client import MedBackendClient
from medbackend.resources import Patient
client = MedBackendClient(token_provider=get_access_token)
async def create_patient():
patient = (
Patient.builder()
.name(given=["Anna"], family="Muller")
.birth_date("1985-03-14")
.build()
)
return await client.create(patient)
asyncio.run(create_patient())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.