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.
One app still ships from this repository:
| App | Port | Location | Purpose |
|---|---|---|---|
| Patient Picker | 5176 | packages/patient-picker/ | Patient selection during standalone SMART launch |
The rest live in their own repositories and release on their own cadence:
| App | Port | Repository | Purpose |
|---|---|---|---|
| Admin UI | 5173 | proxy-smart/proxy-smart-admin-ui (private) | Platform administration dashboard |
| SMART DICOM Template | 5180 | proxy-smart/smart-dicom-template | Starter kit for imaging algorithm SMART apps, Apache-2.0 and marked as a GitHub template |
| 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.
The admin UI is the one exception to that path: this repository's CI checks it out, builds it into webapp-dist/, and the backend serves it at /webapp. A deployment that skips it still works -- every admin surface is reachable over the API and, since each admin route is derived into an MCP tool, over /mcp as well.
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.