Is AJ Commons software free to use?

Yes. All AJ Commons components are licensed under the Apache License 2.0 — free to use, modify, and distribute with no usage fees, no call-home telemetry, and no proprietary lock-in. You can self-host on your own infrastructure or air-gapped government cloud.

AJBridge is an open-source HL7v2 to FHIR R4/R5 integration gateway. It receives ADT, ORU, ORM, OML, and MDM messages via MLLP and converts them to FHIR resources. It includes ATNA audit, consent enforcement, and SMART token validation. It is a drop-in OpenHIM-compatible replacement.

What is a Master Patient Index and does AJ Commons have one?

A Master Patient Index (MPI) is a system that uniquely identifies patients across multiple healthcare facilities, eliminating duplicate records. AJMPI is AJ Commons' open-source MPI with probabilistic matching, golden record management, and IHE PDQm, PIXm, and PMIR conformance.

Are AJ Commons projects Digital Public Goods?

AJ Commons components are being submitted to the Digital Public Goods Alliance (DPGA) as Digital Public Goods under SDG 3 — Good Health and Well-Being. All components are Apache 2.0 licensed. Owned by Akhester Technologies LLP, transferring to AJ Health Commons upon Section 8 foundation registration.

Which programming language and runtime does AJ Commons use?

All AJ Commons components are built on Java 21 (OpenJDK) and Spring Boot 3, using HAPI FHIR JPA v7.4.5 as the FHIR server. All dependencies are open source under Apache 2.0 or compatible licences. Components can be deployed via Docker Compose on any POSIX OS or cloud environment.

Does AJ Commons support ABDM — Ayushman Bharat Digital Mission?

Yes. AJ Commons components align with ABDM Health Data Management Policy and ABDM FHIR profiles. AJConsent implements the consent framework required by ABDM. AJBridge supports HL7v2 to FHIR conversion aligned with ABDM's interoperability requirements. AJMPI supports the patient identity resolution patterns used in ABDM's Health ID system.

AJ Commons — Open Source FHIR Health Infrastructure Foundation

Components

Nine independently deployable components

Use what you need. Replace what you have. Every component works alone or as part of the full AJ Commons stack.

Component

Function

Status

Links

AJBridgeHL7v2 → FHIR Gateway

Connects your hospital HIS to the FHIR ecosystemMLLP reception for ADT, ORU, ORM, OML, MDM messages. Converts HL7v2 to FHIR R4/R5. ATNA audit, consent enforcement, SMART token validation. Drop-in OpenHIM-compatible replacement.

Coming soon

GitHub

AJMPIMaster Patient Index

Resolves patient identity across every connected facilityProbabilistic matching, golden record management, IHE PDQm / PIXm / PMIR conformant. Eliminates duplicate patient records at national scale.

Coming soon

GitHub

AJConsentConsent Manager

Patient-controlled data access with GDPR · HIPAA · DISHA complianceFHIR R4/R5 Consent resource lifecycle. Patient self-service portal. Deny-by-default enforcement. IHE ATNA audit trail. 181 tests.

Stable v1.0.0

Docs GitHub

AJHFRHealth Facility Registry

The authoritative directory of every hospital and clinic in your networkmCSD-conformant IHE ITI-90 search. Admin portal. Auto-provisioning from HL7v2 MSH-4 facility codes. Used to route HL7 messages and resolve facility identifiers across the HIE.

Coming soon

GitHub

AJGuardCross-Facility Safety

Catches what no single hospital can see aloneDrug interaction and allergy checks across all connected facilities. CDS Hooks integration fires at point of prescribing. Cross-facility medication history. Population safety surveillance for MoH reporting.

Coming soon

GitHub

AJAuthSMART Auth Server

Complete SMART App Launch v2.2 authorisation serverPKCE S256 enforced. Atomic launch tokens. RS256 JWT with JWKS. Azure AD · Okta · Epic IdP federation. 90 tests. Production-ready alternative to Keycloak SMART extensions.

Stable v0.2.3

Docs GitHub

AJConnectCDS Hooks Engine

Clinical decision support at the moment of careCDS Hooks 2.0 service orchestrator. Aggregates hooks from multiple CDS providers. Feeds AJGuard safety alerts to any SMART-enabled EHR at point of prescribing or ordering.

Coming soon

GitHub

AJImmuniseVaccination App

WHO-schedule vaccination management with digital certificatesSMART on FHIR vaccination history. WHO schedule forecasting. Printable WHO VDS-NC digital certificates with QR codes. Aligned with GAVI and NIP reporting requirements. 28 tests.

Stable v1.0.0

Docs GitHub

AJReferralCross-Facility Referral

Tracks patients across facility boundaries, from referral to receiptFHIR R4/R5 ServiceRequest + Task state machine. IHE MHD document exchange. Real-time status notifications. Prevents patients from being lost between facilities.

Stable v1.0.0

Docs GitHub

Full technical documentation at docs.ajcommons.org · All components Java 21 · Spring Boot 3 · Apache 2.0

National HIE — how data flows through AJ Commons From hospital HIS to population health

AJImmunise and AJReferral operate independently or alongside the full stack. Technical documentation: docs.ajcommons.org/architecture

Standards alignment

Built on open standards, not proprietary protocols

Every component implements published international standards. No vendor lock-in. Interoperable with any conformant system.

HL7 International

FHIR® · SMART® · CDS Hooks · HL7v2 · IPS

FHIR® R4 FHIR® R5 SMART® App Launch v2.2 CDS Hooks 2.0 IPS — Patient/$summary FHIR Bulk Data $export FHIR Subscriptions (rest-hook) HL7v2 ADT · ORU · ORM · OML · MDM · RDE · SIU MLLP — 7 ports / 7 message types QBP Q22 / RSP K22 (PDQ v2)

FHIR R4 and R5 resource types across all components. SMART App Launch v2.2 with PKCE S256 enforced. CDS Hooks 2.0 for real-time clinical decision support (AJGuard fires on medication-prescribe, patient-view, encounter-discharge, order-sign). IPS Patient/$summary with 10-section parallel assembly and Redis cache. FHIR Bulk Data $export for population-level reporting. Full FHIR rest-hook subscription engine (13 criteria types). HL7v2 MLLP on 7 dedicated ports — ADT A01-A40, ORU R01, ORM O01/OML O21, MDM T02, QBP Q22, RDE O11, SIU S12-S17.

IHE — Integrating the Healthcare Enterprise

ITI · RAD · BALP — 16 transactions

ITI · ATNA (ITI-8, ITI-20) ITI · BALP (FHIR AuditEvent) ITI · PDQm (ITI-78) ITI · PIXm (ITI-83) ITI · PMIR (ITI-93, ITI-94) ITI · MHD (ITI-65, 66, 67, 68) ITI · MHD (ITI-105, ITI-106) ITI · mCSD (ITI-90) ITI · IUA (Internet User Auth) ITI · XDS.b RAD · DICOM DIMSE

Full IHE ITI profile implementation. ATNA audit on 138 sites across all services — RFC 5425 TLS syslog (ITI-20) to syslog-ng plus FHIR R4 AuditEvent POST (IHE BALP) to HAPI. MHD v4.2.3 complete — all six transactions including ITI-105 Simplified Publish and ITI-106 Generate Metadata from CDA. PMIR ITI-93/94 with async fan-out to downstream subscribers. IUA wraps SMART on FHIR token validation. mCSD ITI-90 with 6-hour facility cache. XDS.b document sharing. DICOM DIMSE for radiology. OpenHIM mediator-compatible via self-registration protocol.

Clinical Terminology

SNOMED CT · LOINC · ICD · RxNorm

SNOMED CT (Snowstorm) LOINC ICD-10 / ICD-11 RxNorm (NLM API) UCUM FHIR $expand · $translate · $validate-code

Snowstorm SNOMED CT server with ECL queries and subsumption. LOINC code binding on FHIR ValueSets with local lab code overlay (28 Sri Lanka codes). ICD-10 ↔ SNOMED CT cross-maps. RxNorm NDC normalisation via NLM API — used by AJGuard for cross-facility drug-drug interaction checking. UCUM units on all Observation resources. Federated terminology federation: local → Snowstorm → NLM.

Infrastructure · openEHR · Security

Apache Camel · openEHR · mTLS · Redis

Apache Camel (routing) openEHR RM / EHRBase / AQL DICOM DIMSE + STOW-RS mTLS (client cert) OAuth 2.0 / PKCE S256 RS256 JWT / JWKS rotation Redis (IPS cache) Prometheus · Grafana

Apache Camel drives all 7 MLLP routes and FHIR gateway routing in AJBridge. openEHR archetypes and operational templates via EHRBase with AQL. DICOM DIMSE for PACS and STOW-RS for web-based imaging. mTLS for high-security hospital integrations. Redis-backed IPS cache (<100ms warm). 20+ Prometheus counters per service, 4 Grafana dashboards, 11 Alertmanager rules.

National · WHO · DPG · Observability

NDHB · WHO · DHIS2 · Apache 2.0

India NDHB 2019 WHO SMART Guidelines WHO VDS-NC (vaccination) DHIS2 direct integration ONC HTI-1 / Inferno PEPFAR reporting DPG Standard v1.1.6 Country-agnostic OID config Apache 2.0

India NDHB 2019 aligned. WHO SMART Guidelines for computable clinical guidance. WHO VDS-NC vaccination certificates with QR codes. DHIS2 direct integration via Dhis2SurveillanceMediator — 5 notifiable diseases configured, LOINC→DHIS2 data element mapping. Country-agnostic deployment: all OIDs, MRN systems, national ID systems, and clinical thresholds configured via deployment.yml — same binary, different config for Sri Lanka, Kenya, Nepal, Bangladesh.

Digital Public Goods — Evidence Page

DPG Standard compliance — all 9 indicators

This page serves as the official ownership and compliance evidence for AJ Commons DPG applications submitted to the Digital Public Goods Alliance (DPGA). URL submitted: ajcommons.org/#dpg

Indicator 3 — Ownership statement (primary evidence)

All AJ Commons projects listed on this page are owned by Akhester Technologies LLP, registered in India. All components are released under the Apache License 2.0 (OSI-approved). Upon registration of AJ Health Commons as a Section 8 non-profit company in India, stewardship and trademark ownership will transfer permanently to the foundation. Source code: github.com/ajcommons. Copyright notices are present in every repository. Ownership enquiries: dpg@ajcommons.org

1 SDG Relevance ✓ Met

AJ Commons components directly advance SDG 3 — Good Health and Well-Being by providing open digital infrastructure that enables health data exchange, patient identity resolution, and clinical decision support in low- and middle-income country health systems.

SDG 3.8 — Universal Health Coverage SDG 3.4 — Non-Communicable Diseases SDG 3.b — Medicines & Vaccines access SDG 3.d — Health security & surveillance

Per-component SDG mapping AJBridge / AJMPI: SDG 3.8 — connects fragmented hospital HIS systems to a shared health record, directly enabling universal health coverage infrastructure.
AJConsent: SDG 3.8 — patient-controlled data access aligns with ABDM, GDPR, and DISHA consent requirements for national health systems.
AJHFR: SDG 3.8 — authoritative facility directory is a foundational requirement for any national health information exchange.
AJGuard: SDG 3.4 + 3.d — cross-facility drug safety reduces adverse drug events; population safety signals support national surveillance.
AJImmunise: SDG 3.b — WHO-schedule vaccination management and VDS-NC certificates support equitable vaccine access and tracking.

2 Open Licensing ✓ Met

All AJ Commons components are licensed under the Apache License 2.0, an OSI-approved open source licence that permits free use, modification, distribution, and commercial use with attribution. No component uses a licence more restrictive than Apache 2.0.

Evidence links (LICENSE file in each repo) Each repository contains a LICENSE file at the root level. Apache 2.0 SPDX identifier: Apache-2.0. Licence text: apache.org/licenses/LICENSE-2.0. All dependencies carry compatible open licences (see Indicator 4).

3 Clear Ownership ✓ Met

Owner: Akhester Technologies LLP, India. Copyright notices appear in all source files. This page (ajcommons.org/#dpg) is the publicly available ownership documentation submitted as evidence in each DPGA application.

Transition plan: upon Section 8 registration of AJ Health Commons (filing in progress), all AJ project trademarks and stewardship will transfer to the foundation entity. The Apache 2.0 licence remains unchanged and irrevocable regardless of ownership transfer.

Evidence Ownership statement above · Copyright headers in all source files · dpg@ajcommons.org for DPGA reviewer enquiries · GitHub organisation: github.com/ajcommons

4 Platform Independence ✓ Met

All AJ Commons components run on Java 21 (OpenJDK) — a free, open runtime. No mandatory dependency introduces licence restrictions beyond Apache 2.0. The full dependency stack is open source.

Dependency licence audit HAPI FHIR JPA Server — Apache 2.0 · Spring Boot 3 — Apache 2.0 · Spring Authorization Server — Apache 2.0 · PostgreSQL — PostgreSQL Licence (permissive, OSI-approved) · Flyway — Apache 2.0 · Docker / Kubernetes — Apache 2.0 · OpenJDK 21 — GPL v2 + Classpath Exception (fully open, no restriction on use). No proprietary dependencies. Components can be deployed on any POSIX OS, any cloud, or air-gapped government infrastructure.

5 Documentation ✓ Met

Each component has technical documentation sufficient for a developer unfamiliar with the project to deploy and run it. Documentation includes: quickstart guide, architecture overview, configuration reference, API reference, and Docker Compose deployment.

Documentation links Platform documentation: docs.ajcommons.org (Docusaurus, migrating from open.akhester.com) · Component-level docs: /docs/auth-server · /docs/consent-manager · /docs/smart-client · /docs/immunisation · /docs/referral · Architecture: docs.ajcommons.org/architecture · Quickstart: docs.ajcommons.org/getting-started/quickstart · All repositories include README.md with setup instructions. Components marked "Coming Soon" have README.md with planned architecture; full docs published at launch.

6 Non-PII Data Extraction ✓ Met

AJ Commons components that store health data support non-PII data extraction via standard open interfaces. Aggregate and anonymised data can be exported without exposing patient identity.

Extraction mechanisms per component AJBridge / AJMPI / AJHFR: FHIR Bulk Data Access ($export operation, NDJSON format) — extracts de-identified population-level records. FHIR Search API returns JSON/XML. Admin console CSV export for facility and provider lists.
AJConsent: Consent statistics and audit summaries exported as FHIR AuditEvent bundles (JSON/XML). No PII required for aggregate compliance reporting.
AJGuard: Population drug safety signal reports exported as FHIR MeasureReport resources (JSON). DHIS2 integration exports aggregate indicators via FHIR-to-DHIS2 bridge — no individual patient data in the export stream.
AJImmunise: WHO VDS-NC certificate data available as FHIR Immunization resources. Aggregate vaccination coverage exported as FHIR MeasureReport for NIP reporting.

7 Privacy & Applicable Laws ⚑ In progress

AJ Commons components are designed to comply with the following applicable privacy and data protection laws. Full privacy documentation is being completed as part of DPG submission preparation.

Applicable laws & frameworks India: Digital Personal Data Protection Act 2023 (DPDPA) · Information Technology Act 2000 (amended 2008) · ABDM Health Data Management Policy
International: GDPR (EU) 2016/679 — applicable for deployments in EU jurisdictions · HIPAA (US) — applicable for US deployments · WHO SMART Guidelines privacy framework

2025 DPGA privacy requirements (mandatory)
Data minimisation: Components collect only the minimum PII required for clinical function. AJAuth collects clinician identity for token issuance only. AJMPI collects demographic data required for probabilistic matching — no biometrics stored.
Consent mechanism: AJConsent implements FHIR R4/R5 Consent resource lifecycle with deny-by-default enforcement. Patients can view, grant, and revoke consent via self-service portal at any time.
Data use transparency: Every data access event is logged as a FHIR AuditEvent (IHE ATNA). Patients can query their own audit log via the consent portal.
Retention & deletion: Configurable retention policies per deployment. FHIR $delete and $purge operations supported. No data retained beyond implementer-configured period.
Access controls: PKCE S256 on every token request. RS256 JWT with JWKS rotation. Role-based scope enforcement via SmartScopeInterceptor. No bearer tokens in application logs.
Privacy policy: Contact dpg@ajcommons.org for full Privacy Policy document (being published at ajcommons.org/privacy).

8 Open Standards & Best Practices ✓ Met

All AJ Commons components are built exclusively on published, royalty-free international open standards. No proprietary protocols are used at any layer.

Standards implemented HL7 FHIR R4 / R5 · SMART App Launch v2.2 (HL7) · CDS Hooks 2.0 (HL7) · IHE ATNA (Audit Trail & Node Authentication) · IHE PDQm / PIXm / PMIR (Patient Identity) · IHE MHD (Mobile Document Exchange) · IHE mCSD (Care Services Discovery) · OpenID Connect Core 1.0 · OAuth 2.0 RFC 6749 · PKCE RFC 7636 · RS256 JWT RFC 7519 · JWKS RFC 7517 · WHO VDS-NC (vaccination certificates) · WHO SMART Guidelines · NDJSON (Bulk Data) · HL7v2.x (MLLP/ATNA)

9A Do No Harm — Data Privacy & Security ⚑ In progress

AJ Commons components that handle PII (AJBridge, AJMPI, AJConsent, AJHFR, AJGuard, AJImmunise) are designed with security and privacy controls at the architecture level, not as add-ons.

Security model — per component Encryption: TLS 1.3 enforced on all inter-service communication. PostgreSQL data at rest encrypted via filesystem or cloud-provider encryption (AES-256 recommended in deployment guide).
Authentication: All FHIR endpoints protected by SMART token validation. No unauthenticated access to patient data.
Authorisation: Least-privilege SMART scopes enforced at FHIR resource level via SmartScopeInterceptor. patient/*.read scopes limited to authenticated patient context.
Audit: 138 ATNA audit sites across components. Every authentication event, consent decision, and data access written as immutable FHIR AuditEvent. HIPAA §164.312(b) compliant.
PII in logs: Application logs contain zero patient identifiers. Token values are not logged. Audit events are written to a separate append-only store.
Vulnerability disclosure: Security issues reported to security@ajcommons.org. SECURITY.md present in each repository with responsible disclosure process.
Full Data Protection Impact Assessment (DPIA): Being prepared — available to DPGA reviewers on request at dpg@ajcommons.org.

9B Do No Harm — Inappropriate & Illegal Content N/A

AJ Commons components are developer infrastructure — FHIR servers, integration engines, identity registries, and clinical decision support APIs. They do not enable end-users to upload, store, or distribute user-generated content of any kind. There is no content upload surface, no social feature, no file sharing, and no mechanism by which inappropriate or illegal content could be submitted by users.

This indicator is not applicable to AJ Commons components. DPGA reviewers may confirm: no component provides a content submission interface, forum, media upload, or equivalent user-generated content pathway.

9C Do No Harm — Protection from Harassment ✓ Met

The AJ Commons contributor community is governed by a Code of Conduct based on the Contributor Covenant v2.1, present in every repository. Contributors and users have a clear process to report harassment and a designated point of contact for enforcement.

Evidence CODE_OF_CONDUCT.md present in all repositories · Enforcement contact: conduct@ajcommons.org · Reporting process: file a confidential report via email; maintainers respond within 72 hours · Escalation path to AJ Health Commons board · GitHub's built-in content moderation also applies to all public repositories in the ajcommons organisation.

SDG 3 target coverage by component

Component

SDG 3.8

Universal health coverage

SDG 3.4

Non-communicable diseases

SDG 3.b

Medicines & vaccines

SDG 3.d

Health security

AJBridge · AJMPI

HL7v2 gateway · patient identity

Primary · 3.8

—

AJConsent · AJHFR

Consent manager · facility registry

Primary · 3.8

—

AJGuard

Cross-facility drug safety

—

Primary · 3.4

—

Primary · 3.d

AJImmunise

Vaccination app · WHO VDS-NC

—

Primary · 3.b

—

AJAuth · AJReferral · AJConnect

SMART auth · referral · CDS orchestration

Supporting

—

Primary = direct SDG contribution

Supporting = enabler of SDG progress

DPGA review confirms SDG mapping at submission time

Application status by project

Project

Licence

DPG Status

AJBridgeHL7v2 → FHIR Gateway · SDG 3.8

Apache 2.0

Submitting

AJMPIMaster Patient Index · SDG 3.8

Apache 2.0

Submitting

AJConsentConsent Manager · SDG 3.8

Apache 2.0

In review

AJHFRFacility Registry · SDG 3.8

Apache 2.0

In review

AJGuardCross-Facility Safety · SDG 3.4 · 3.d

Apache 2.0

Preparing

AJAuthSMART Auth Server · SDG 3.8

Apache 2.0

Preparing

AJConnectCDS Hooks Engine · SDG 3.8

Apache 2.0

Preparing

AJImmuniseVaccination App · SDG 3.b

Apache 2.0

Preparing

AJReferralCross-Facility Referral · SDG 3.8

Apache 2.0

Preparing

DPG Standard v1.1.6 · Last reviewed: June 2026 · Review process: digitalpublicgoods.net · DPG reviewer enquiries: dpg@ajcommons.org

Open infrastructure for health systems that serve everyone

Built from the gaps a clinician sees every day

Nine independently deployable components

Built on open standards, not proprietary protocols

Open governance, not corporate control

Who stewards AJ Commons

Governance commitments

DPG Standard compliance — all 9 indicators

Indicator 3 — Ownership statement (primary evidence)

SDG 3 target coverage by component

Application status by project

We'd like to hear from you

Government & national health programmes

Developers & implementers

DPG, research & partnerships

Security vulnerabilities

Code of Conduct reports