Trusted infrastructure for national digital health platforms
The complete open source
SMART on FHIR platform
The only open source Java platform with full SMART App Launch v2.2 and national health platform alignment built in. Apache 2.0 licensed. One command to deploy.
Aligned withWHO Digital Health GuidelinesHL7 FHIR R4SMART App Launch v2.2IHE ATNAHTI-1 / TEFCAGDPR / EHDS
500+Tests
v2.2SMART App Launch
FHIR R4Data standard
Apache 2Open source licence
HAPI 7.4Upstream tracked
Platform components — each with its own documentation site
Everything you need. Nothing you don't.
Ready to deploy nowAuth Server v0.2.3 · SMART Client v0.1.0 · HAPI FHIR Plugin v1.0.0docker compose up →
Independently deployable components. Use what you need. Replace what you have.
Auth Server
v0.2.3
Complete SMART App Launch v2.2 authorization server. PKCE S256, EHR launch tokens, RS256 id_token, JPA app registry, IdP federation.
PKCE S256 enforcedAtomic launch tokensRS256 + JWKSAzure AD · Okta · Epic IdP
SMART Client
v0.1.0
Spring Boot 3 SMART App Launch v2.2 client. Dynamic discovery, full RS256 id_token verification, proactive token refresh, Thymeleaf clinical UI.
96-byte PKCE verifierFull RS256 verification120s proactive refreshClinical UI
HAPI FHIR Plugin
v1.0.0
Spring Boot autoconfiguration plugin that pre-wires SMART discovery proxy and scope enforcement interceptor onto any HAPI FHIR JPA server.
Discovery proxy filterSmartScopeInterceptorRemoteJWKSet RS256.rs + .read scopes
12 tests
Docs →GitHub ↗
Consent Manager
v1.0.0
FHIR R4 Consent resource lifecycle for HAPI FHIR servers. Patient self-service portal, SMART v2.2 scope enforcement, IHE ATNA audit trail. GDPR · HIPAA · HTI-1 compliant.
FHIR R4 Consent resourcePatient portal — grant, edit, revokeDeny-by-default enforcementGDPR · HIPAA · HTI-1
Immunisation App
v1.0.0
Dedicated SMART on FHIR vaccination management. Vaccination history, WHO schedule forecasting, and printable WHO VDS-NC digital certificates with QR codes.
Vaccination historyWHO schedule forecastVDS-NC QR certificateSMART v2.2
28 tests
Docs →GitHub ↗
How it works
From clinician login to patient data — in four steps
No proprietary protocols. No vendor lock-in. Just open standards working together.
01
Clinician opens an app
A clinician clicks a SMART app inside their EHR — Epic, Cerner, or any standard system. The EHR passes a secure launch token identifying the patient and encounter context.
02
Identity is verified
The Auth Server validates the launch token, authenticates the clinician via your existing identity provider (Azure AD, Okta, Epic IdP), and issues a signed access token using RS256.
03
App accesses patient data
The SMART Client uses the access token to query HAPI FHIR for exactly the patient data the app needs — and nothing more. Scopes enforce least-privilege access at the resource level.
04
Every access is audited
Every authentication event, consent decision, and FHIR data access is written as a FHIR AuditEvent to a queryable audit log. HIPAA, GDPR, and IHE ATNA requirements met automatically.
FHIR + SMART on FHIR ecosystem
The complete technical picture
Every component, protocol, resource type, and integration point — from browser to database. Built to the SMART App Launch v2.2 spec, FHIR R4, and IHE profiles.
Standards alignment
Built on open standards
HL7Planned
SMART App Launch v2.2
Lets clinical apps securely access patient data from any EHR with patient context. Mandated by ONC HTI-1 from July 2026.
HL7Planned
FHIR R4
The international standard for exchanging healthcare information electronically. Used by every major EHR vendor.
IETFPlanned
PKCE RFC 7636
Proof Key for Code Exchange — prevents auth code interception attacks. S256 enforced on every client, no opt-out.
OIDCPlanned
OpenID Connect
Identity layer on top of OAuth 2.0. Delivers verified clinician identity and patient context in a signed id_token.
IHEIn progress
IHE ATNA
Audit Trail and Node Authentication. Every access event written as a FHIR AuditEvent — required for HIPAA and GDPR.
HL7In progress
FHIR Consent
Patient-controlled access consent using the FHIR Consent resource. Covers GDPR, DISHA, and ABDM consent frameworks.
IHEPlanned
IHE MHD
Mobile access to Health Documents — lightweight document sharing profile used by national patient record systems.
HL7Planned
SMART Backend Services
Server-to-server auth for bulk data and population health apps — no user present, uses client credentials flow.
National health platforms
Designed for national scale
Purpose-built for the requirements of national digital health deployments — open standards, patient consent, federated identity, and a complete audit trail.
Open standards throughout
Built entirely on FHIR R4, SMART App Launch v2.2, IHE ATNA, and OpenID Connect. No proprietary protocols. Interoperable with any standards-compliant EHR or national health record system.
FHIR R4SMART v2.2IHE ATNAOIDC
Patient consent at scale
FHIR Consent resource lifecycle with deny-by-default enforcement. Patients control who can access their data and for how long. Revocation takes effect immediately across all connected applications.
GDPR Art.9HIPAA §164.508HTI-1 / TEFCA
National identity federation
Federates with any OpenID Connect identity provider — hospital directories, national identity systems, or enterprise IdPs. No single point of identity failure across a distributed health network.
OIDC federationPKCE S256RS256 JWT
Immutable audit trail
Every authentication event, consent decision, and FHIR resource access is written as a FHIR AuditEvent using IHE ATNA codes. Queryable, exportable, and designed for regulatory inspection.
IHE ATNAFHIR AuditEventDICOM 110110
Horizontal scalability
Stateless JWT enforcement means consent checks add no round-trip to the auth server on each FHIR request. The JPA consent cache is the hot path — scales horizontally with your HAPI FHIR cluster.
Stateless JWTHAPI FHIR 7.4PostgreSQL
Open source and self-hostable
Apache 2.0 licensed. No usage fees, no call-home telemetry, no vendor lock-in. Deploy on your own infrastructure, air-gapped networks, or government cloud. Full source code available.
Apache 2.0Self-hostableNo telemetry
Why AJ FHIR Platform
Open source. No vendor lock-in. Government-ready.
Why not Smile CDR?
Smile CDR is the most complete commercial SMART platform — and costs $150K–500K+ per year. Beyond most national health budgets. We deliver the same core SMART infrastructure under Apache 2.0 with commercial support priced for government scale.
Why not Keycloak?
Keycloak requires complex custom extensions for SMART on FHIR EHR launch, launch tokens, and SMART v2.2 — and every Keycloak major version breaks those extensions. We implement SMART natively in Spring Authorization Server with no third-party extensions.
Why not Medplum?
Medplum is TypeScript/Node.js — a monolith not designed for JVM environments. Most national health platforms run Java. We are Spring Boot on Java 21, the same stack as HAPI FHIR, which most government systems already run.
Security model?
PKCE S256 enforced on every client. Atomic single-use launch tokens. RS256 JWT with RemoteJWKSet key rotation. Session fixation protection. CSRF tokens. No bearer token in logs. Full ATNA audit trail. See our security documentation.
Commercial support
Open source software. Enterprise support.
Community
Free forever
- GitHub Issues
- Community forum
- FHIR Chat
- Full documentation
Standard
Contact us
- Email support
- 2-day SLA
- All patch releases
- 7-day security patches
Recommended
Enterprise
Contact us
- Phone + email
- 4-hour SLA
- 24h security patches
- Custom feature roadmap
Government
Contact us
- Custom SLA · 24/7 coverage
- On-premises deployment support
- HIPAA BAA · GDPR DPA · compliance docs
- National FHIR IG alignment
- Technical team training
- Procurement documentation pack
support@ajfhir.org · ajfhir.org/support
Typically responds within 24 hours · Mon–Fri
Frequently asked questions
Common questions from evaluators
Is there a live demo I can try?
Yes. The FHIR metadata endpoint is live at fhir.demo.ajfhir.org/fhir/metadata. A full EHR launch demo with patient context requires a short setup — email us and we will walk you through it on a call.
Who maintains this platform?
AJ Smart Technologies maintains the platform with active development. The upstream dependency, HAPI FHIR, is maintained by Smile Digital Health and has been in production since 2014. We track HAPI stable releases within 2–4 weeks.
What is the upgrade path when HAPI FHIR releases a new version?
Our versioning scheme tracks HAPI directly — major.minor.platform-patch. When HAPI releases a new minor version, we validate and release a matching platform version within 2–4 weeks. Breaking changes are documented in release notes.
Is this HIPAA compliant?
The platform implements the technical safeguards required by HIPAA — access controls, audit logging, transmission encryption, and minimum necessary scope enforcement. HIPAA Business Associate Agreements are available to Enterprise and Government support customers.
How does this integrate with our existing Hospital Information System?
Any HIS that supports SMART App Launch v2.2 or FHIR R4 can integrate directly. For HIS systems using older protocols, the IdP Federation layer (Azure AD, Okta, Epic IdP, ADFS) bridges existing identity providers. Contact us with your HIS details for a specific integration assessment.