A stateless proxy that adds OAuth 2.0 and SMART App Launch authorization to the FHIR servers you already run. Your clinical data stays exactly where it is.
Proxy Smart sits between SMART apps and FHIR servers and handles authentication and authorization. Requests pass through to your existing servers while the proxy manages OAuth flows and access control. PostgreSQL only stores users and configuration.
Every FHIR proxy request runs through a layered security pipeline. Each layer can be tuned on its own, so you can roll out a stricter policy in audit mode first and switch it to enforce once the logs look clean.
Verifies the token's signature, expiry and issuer.
Always onEnforces patient consent policies and the required identity assurance level. Off until you enable it.
CONSENT_ENABLED + CONSENT_MODEThe token's scope must permit the resource type and operation, in SMART v1 or v2 syntax.
SCOPE_ENFORCEMENT_MODENarrows results by fhirUser: patients see their own data, practitioners their assigned patients.
ROLE_BASED_FILTERING_MODEenforceBlocks the request with HTTP 403.audit-onlyLogs the violation and lets the request through.disabledSkips the check entirely.Consent, scope enforcement and role-based filtering each run in one of these modes. The highlighted mode is the default; change it through the environment or at runtime from the admin API. Configuration reference
Register, manage, and launch SMART on FHIR apps through a single admin interface. Every app gets OAuth 2.0 + PKCE, scope-based access control, and FHIR server routing out of the box.
Browse the App Store →Medical imaging viewer for DICOM studies
Launch →Patient health portal — view IPS summary, conditions, medications, immunizations, lab results and allergies
Launch →AI-native electronic health record — a clinical assistant over the FHIR record, with charting, orders and care plans through conversation.
Launch →SMART on FHIR consent management — review and grant the permissions an app is asking for over your record.
Launch →The hardest part of building a healthcare app is the authentication, authorization and interoperability around the clinical logic. We handle that part.
The proxy layer is stateless, so it scales out horizontally and inherits Keycloak's proven high-availability setup. These are Keycloak's official benchmark figures.
Sources: Keycloak benchmarks · CPU and memory sizing
The dev stack brings up Keycloak, PostgreSQL, Orthanc and the backend. Requires Bun 1.0 or later and Docker.
$ git clone https://github.com/proxy-smart/proxy-smart.git $ cd proxy-smart $ bun install $ bun run docker:dev # or run the backend locally against that stack $ bun run dev # production, separate containers $ bun run docker:prod
| Service | URL |
|---|---|
| Backend API | http://localhost:8445 |
| Admin UI | http://localhost:8445/webapp/ |
| Keycloak | http://localhost:8080 |
| Orthanc (DICOMweb) | http://localhost:8042 |
Until you register your own FHIR server in the admin UI, the dev stack talks to the public test servers hapi.fhir.org and server.fire.ly.
/.well-known/smart-configuration.fhirUser, so patients only see their own data and practitioners only their assigned patients. It starts in audit-only mode; set ROLE_BASED_FILTERING_MODE=enforce or switch it at runtime through the admin API once the audit logs look right./mcp. Its tools are derived from the admin API and protected by the same OAuth flows, so an agent can only do what its token allows./dicomweb forwards QIDO-RS and WADO-RS requests to Orthanc or any other PACS. The same SMART token authorizes imaging and FHIR access, and every DICOM UID is validated before forwarding.