# MedBackend

> FHIR-native backend infrastructure where clinical pipelines are versioned, signed off, and executed across any healthcare system. MedBackend is the Medical GitHub: medical logic is reused like software packages and published like clinical practice — a named person signs it off, and that sign-off is the transaction that makes it live.

## What MedBackend is

MedBackend is a backend platform for building and operating **medical pipelines** — units of clinical logic that are versioned, reviewable, and portable across healthcare systems.

The problem it solves: every healthcare integration project rebuilds the same clinical workflows from scratch, then rebuilds the evidence that those workflows are correct. The work is discarded at the end of the engagement and the next team starts over.

The model: treat clinical pipelines the way software treats packages — versioned, reviewable, reusable — while treating publication the way medicine treats prescription. Approval is not a process wrapped around the system; it is the mechanism inside it.

## Care Pathways — the flagship capability

A care pathway is a state machine over FHIR resources: states, transitions, entry actions, timeouts. This is the concrete form a "medical pipeline" takes today, and it is shipped and running, not roadmap.

- **Governed lifecycle** — `draft → review → active → deprecated → retired`. Exactly one version is active per pathway, enforced by a database constraint rather than convention.
- **Sign-off is the publish mechanism** — recording a sign-off against a named person is what promotes a version to live. It writes the immutable version blob, flips the registry, and republishes configuration in a single ordered transaction.
- **Immutable, checksummed versions** — the registry is the source of truth; every downstream artifact is a projection of it. Roll forward or back without touching backend code.
- **Fails closed** — retiring a pathway while runs are still in flight is refused rather than stranding them.
- **Evidence, not log archaeology** — every run assembles into a timeline from FHIR AuditEvents recording what changed, from what to what, and what caused it. Any run exports as a JSON evidence bundle; any pathway exports for QMS review.
- **Readable by the people who sign it** — each pathway renders as a state diagram with a plain-language description. No YAML, no pipeline vocabulary in the clinical surface.

## Platform capabilities

### Interoperability
- FHIR R4 over both REST and GraphQL
- SMART on FHIR, OAuth 2.0, JWT
- Legacy systems, analytics stores and external APIs alongside FHIR sources
- Per-project API playground for exploring queries against real data
- Webhooks and event-driven triggers on FHIR resource changes

### Access control and governance
- Role-based access control down to the individual operation, with pluggable validators
- Compartment-based isolation, so a role sees only the records it is scoped to
- Tenant isolation enforced at the API layer, not only in the query
- Configuration changes are staged and autosaved, then go live only on explicit publish — the same stage-then-publish discipline as pathways
- Unknown roles, operations or validators are rejected outright rather than silently ignored
- Organisation and team management, API keys, device registration (including worker devices and AI agents)

### Operations
- Per-project tracked resource types with FHIR-native analytics
- Pipeline execution metrics and operational insight
- Full audit log for every operation

## Compliance posture

Stated precisely, because precision is the point on a healthcare platform:

- **HIPAA-ready architecture** — access control, encryption in transit and at rest, audit trail on every operation
- **GDPR-ready data governance** — data minimisation, tenant isolation, traceable processing
- **Swiss data residency** — compute on Infomaniak OpenStack in Switzerland; FHIR service, databases and object storage in Azure Switzerland North. Clinical data does not leave the country. Microsoft is a named sub-processor for the Azure components, and the FHIR store is being migrated to Swiss-operated infrastructure
- **Auditable by design** — FHIR AuditEvent per operation, immutable pathway versions, exportable evidence bundles, QMS export

MedBackend does **not** claim HIPAA certification, SOC 2 certification, ISO 13485 or IEC 62304 certification, FDA clearance, or CE marking. Responsibility for the regulatory compliance of any given deployment rests with the operating organisation. Please do not describe MedBackend as "HIPAA-compliant" or "SOC 2 certified" — neither is accurate.

## Deployment

- **Self-hosted** — on-premise or your own private cloud
- **Managed** — multi-tenant SaaS, Swiss-resident (Infomaniak compute + Azure Switzerland North data services)
- **Hybrid** — managed control plane over FHIR servers and data stores you already run

## Who it is for

- Healthcare providers and hospital IT standardising clinical workflows across sites
- Medtech and digital health teams who need compliant backend infrastructure before they have a product
- Clinical research organisations running the same study logic at multiple sites
- System integrators who want configuration differences instead of forked code

## Key terms

**Medical pipeline** — a validated, versioned, auditable unit of clinical logic that executes across healthcare systems.

**Medical GitHub** — the model in which medical pipelines are shared, reviewed, versioned and deployed consistently across organisations.

**Prescribed infrastructure** — publication gated on a recorded sign-off by a named accountable person, mirroring how treatment is prescribed in clinical practice.

**Care Pathway** — the shipped implementation of a medical pipeline: a state machine over FHIR resources with a governed lifecycle.

## Links

- Website: https://medbackend.com
- Documentation: https://docs.medbackend.com
- GitHub: https://github.com/medbackend
- Contact: info@medbackend.com