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. MIT licensed. One command to deploy.
Aligned withWHO Digital Health GuidelinesHL7 FHIR R4SMART App Launch v2.2IHE ATNAHTI-1 / TEFCAGDPR / EHDS
296+Tests
v2.2SMART App Launch
FHIR R4Data standard
6National frameworks
MITOpen source licence
HAPIUpstream 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 Nimbus 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
Consent Manager
v1.1.0 planned
FHIR Consent resource lifecycle. Patient self-service portal, consent enforcement interceptor, full audit trail. GDPR · HIPAA · TEFCA compliant.
FHIR Consent resourcePatient portalEnforcement interceptorGDPR · HIPAA · TEFCA
Referral Module
v1.2.0 planned
FHIR-native inter-facility referral using ServiceRequest and Task resources. Closes the digital information gap between hospitals.
FHIR ServiceRequestFHIR Task workflowCross-facilityStatus tracking
ATNA Audit
v1.1.0 planned
IHE ATNA-compliant audit trail. Every consent decision, FHIR access, and auth event written as FHIR AuditEvent. Queryable, exportable.
IHE ATNA compliantFHIR AuditEventAsync loggingQueryable trail
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
Directly aligned with national Digital Health Blueprint requirements across six countries.
🇱🇰 Sri Lanka
Digital Health Blueprint (2023)
§6.2.7 Auth · §6.2.8 Authorisation · §6.2.10 Consent · §6.2.9 Audit
Auth Server · Consent Manager · ATNA Audit · Referral Module
WHO + Global Fund endorsed blueprint
🇳🇵 Nepal
National eHealth Strategy
FHIR-based data exchange · National patient registry
HAPI FHIR JPA · Auth Server · SMART Client
MoHP Nepal aligned
🇮🇳 India
DISHA / Ayushman Bharat Digital Mission
Patient data principal rights · Consent framework
Consent Manager · FHIR Consent resource · Audit trail
NHA India aligned
🇦🇺 Australia
My Health Record / ADHA Strategy
Patient-controlled access · SMART auth
Consent Manager · Auth Server · SMART Client
ADHA framework aligned
🇪🇺 EU / EHDS
European Health Data Space
GDPR Art.9 · Right to access · Data portability
Consent Manager · FHIR AuditEvent · ATNA
GDPR + EHDS aligned
🇺🇸 US / ONC
HTI-1 Final Rule / TEFCA
SMART App Launch v2.2 mandated by July 2026
Auth Server v2.2 · Consent · SMART Client
ONC HTI-1 compliant
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 MIT licence 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
Enterprise
Contact us
- Phone + email
- 4-hour SLA
- 24h security patches
- Custom feature roadmap
Recommended
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@ajsmart.com · ajsmart.com/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.ajsmart.com/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.