Stateless by design
Requests pass through to your FHIR servers. Nothing clinical is persisted here, so the proxy is never the system of record.
An authorization layer between SMART apps and FHIR servers that stores no clinical data.
Proxy Smart sits between SMART on FHIR applications and the FHIR servers that hold the records. It terminates the OAuth flow, validates and narrows scopes, enforces consent, and forwards what survives. Clinical data is never stored on the way through, which keeps the proxy out of the compliance surface that holding records would create.
Around that core sit a set of SMART apps built on a shared component library, an admin dashboard for the platform itself, and an MCP endpoint that exposes the admin API to AI clients.
┌─────────────────────────────────────────────────────────────┐
│ Frontend Apps │
│ Patient Portal │ Consent │ DTR │ Patient Picker │ Admin UI │
│ SMART DICOM Template │
│ │
│ All built with @proxy-smart/shared-ui (SmartAppShell) │
└──────────────────────────┬──────────────────────────────────┘
│ SMART App Launch 2.2.0
┌──────────────────────────▼──────────────────────────────────┐
│ Proxy Smart Backend │
│ Elysia/Bun │ OAuth Proxy │ FHIR Proxy │ MCP Server │
└──────────┬──────────┬──────────┬────────────────────────────┘
│ │ │
┌─────▼───┐ ┌────▼────┐ ┌──▼───────┐
│Keycloak │ │FHIR R4 │ │Orthanc │
│ (IdP) │ │Server(s)│ │(DICOMweb)│
└─────────┘ └─────────┘ └──────────┘Keycloak is the identity provider; the proxy never issues its own tokens. FHIR servers and DICOMweb endpoints are registered at runtime through the admin UI rather than baked into configuration.
Three apps ship from this repository:
| App | Port | Location | Purpose |
|---|---|---|---|
| Admin UI | 5173 | frontend/ui/ | Platform administration dashboard |
| Patient Picker | 5176 | packages/patient-picker/ | Patient selection during standalone SMART launch |
| SMART DICOM Template | 5180 | frontend/smart-dicom-template/ | Starter kit for imaging algorithm SMART apps |
Three more live in their own repositories and release on their own cadence:
| App | Port | Repository | Purpose |
|---|---|---|---|
| Patient Portal | 5173 | max-health-inc/patient-portal | Patient-facing health records, imaging, IPS |
| Consent Manager | 5174 | max-health-inc/consent-app | FHIR Consent resource management |
| DTR / Prior Auth | 5175 | max-health-inc/dtr-app | Da Vinci DTR questionnaires and PA workflow |
Each external app builds its static assets in its own CI and pushes them into a shared apps_static Docker volume mounted at /app/backend/public/apps. The backend serves them from /apps/{app-name}/. That decoupling is deliberate: an app can ship without a platform release.
If you are deploying the platform, read Deployment and then Environment Variables. If you are integrating an app against it, OAuth & Authentication and the FHIR Proxy describe the two surfaces you will talk to. If you are assessing spec conformance, the SMART 2.2.0 Checklist tracks implementation status and Compliance Reports publishes the Inferno results from each environment.
Everything else is in the sidebar.