AJ FHIR Platform — Open Source

Open source FHIR infrastructure
for the JVM

Nine independently deployable components — SMART on FHIR auth and client apps, consent management, HL7v2-to-FHIR gateway, master patient index, and facility registry. Apache 2.0 licensed. One command to deploy.

Get started →

Aligned withHL7 FHIR R4/R5SMART App Launch v2.2IHE ATNAIHE MHD · PDQm · PIXmHTI-1 / TEFCAGDPR · HIPAA

9Components

500+Tests

FHIR R4/R5Data standard

Apache 2Open source licence

Java 21Runtime

Discussed inHL7 FHIR Community Chat·HL7 SMART App Launch v2.2·Built on HAPI FHIR·WHO endorsed blueprint aligned

AJ FHIR Platform — Open Source Components

Everything you need. Nothing you don't.

Ready to deploy nowAuth Server v0.2.3 · SMART Client v0.1.0 · Consent Manager v1.0.0 · Immunisation App v1.0.0docker compose up →

Independently deployable. Use what you need. Replace what you have. SMART on FHIR · IHE · HL7v2 · Apache 2.0.

AJ FHIR Auth Server

v0.2.3

Stable

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

90 tests

Docs →GitHub ↗

AJ FHIR SMART Client

v0.1.0

Stable

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

206 tests

Docs →GitHub ↗

AJ FHIR HAPI Plugin

v1.0.0

Stable

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 ↗

AJ FHIR Consent Manager

v1.0.0

Stable

FHIR R4/R5 Consent resource lifecycle for HAPI FHIR servers. Patient self-service portal, deny-by-default enforcement, IHE ATNA audit trail. GDPR · HIPAA · HTI-1.

FHIR R4/R5 Consent resourcePatient portal — view & revokeDeny-by-default enforcementGDPR · HIPAA · HTI-1

181 tests

Docs →GitHub ↗

AJ FHIR Immunisation App

v1.0.0

Stable

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 ↗

AJ FHIR Referral Module

v1.0.0

Stable

FHIR R4/R5 ServiceRequest + Task cross-facility referral workflow. State machine, IHE MHD document exchange, and real-time notifications.

FHIR ServiceRequest + TaskState machine workflowIHE MHD documentsCross-facility

Docs →GitHub ↗

AJ Gateway

v1.0.0

Coming Soon

HL7v2-to-FHIR integration gateway. MLLP reception for ADT, ORU, ORM, OML, MDM. ATNA audit, consent enforcement, SMART token validation. OpenHIM-compatible replacement.

HL7v2 MLLP nativeFHIR R4/R5 outputIHE ATNA auditOpenHIM replacement

Docs →GitHub ↗

AJ MPI

v1.0.0

Coming Soon

Master Patient Index with probabilistic matching and golden record management. IHE PDQm, PIXm, and PMIR conformant. Native integration with AJ Gateway.

Probabilistic matchingGolden recordsIHE PDQm / PIXmPMIR conformant

Docs →GitHub ↗

AJ FR

v1.0.0

Coming Soon

Facility Registry for hospital and clinic directories. mCSD-conformant IHE ITI-90 search, admin portal, and auto-provisioning from HL7v2 MSH-4 facility codes.

mCSD ITI-90 conformantFacility admin portalAuto-provisioningHL7v2 MSH-4 mapping

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.

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.

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.

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.

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.

↓ Download architecture diagram (SVG)

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

Government enquiry ↗

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.

Read full comparison →

Commercial support

Open source software. Enterprise support.

Community

Free forever

GitHub Issues
Community forum
FHIR Chat
Full documentation

Standard

Email support
2-day SLA
All patch releases
7-day security patches

Recommended

Enterprise

Phone + email
4-hour SLA
24h security patches
Custom feature roadmap

Government

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.

Stay updated

Release announcements, new component updates, and FHIR ecosystem developments. No spam. Unsubscribe any time.

Open source FHIR infrastructurefor the JVM

Everything you need. Nothing you don't.

From clinician login to patient data — in four steps

The complete technical picture

Built on open standards

Designed for national scale

Open source. No vendor lock-in. Government-ready.

Open source software. Enterprise support.

Common questions from evaluators

Open source FHIR infrastructure
for the JVM