JamBridge vs OpenHIM
OpenHIM (Open Health Information Mediator) is the most widely deployed open source health interoperability middleware in low- and middle-income country deployments. It was built by the Health Architecture Lab at the University of Cape Town and is the reference mediator platform for OpenHIE.
JamBridge was built to replace it in contexts where clinical depth, FHIR R4 nativity, and a commercial SLA are required.
Quick verdict
Your integration needs are primarily routing HL7v2 messages between existing systems without FHIR transformation, you have developer capacity to build and maintain custom mediators, and your budget is zero. OpenHIM is a solid, free tool with a large community and is well-established in African national health programme deployments.
You need real-time FHIR R4 transformation with identity enrichment, consent enforcement, terminology translation, and clinical safety checks — without building and maintaining a custom mediator stack for every message type and every deployment site.
Side by side
| Capability | OpenHIM | JamBridge |
|---|---|---|
| HL7v2 MLLP reception | ✓ via MLLP mediator | ✓ native, 8 typed ports |
| HL7v2 → FHIR R4 transform | Custom mediator per message type | ✓ built-in, all 8 types |
| Patient identity resolution | External OpenCR, manual config | ✓ JamMPI $match, automatic |
| Consent enforcement | Custom mediator; no standard model | ✓ FHIR R4 Consent, fail-closed |
| FHIR R4 persistence | Route to external server; no circuit breaker | ✓ HAPI integration + Resilience4j |
| Terminology translation | None built-in | ✓ JamTS, LOINC/SNOMED/ICD-10 |
| Drug safety (DDI) | Not provided | ✓ JamGuard, cross-branch, NLM RxNorm |
| DHIS2 surveillance push | Custom mediator; no LOINC mapping | ✓ built-in, LOINC→DHIS2 mapping |
| FHIR subscriptions / fan-out | HTTP routing only | ✓ 17 seeded subscriptions |
| SMART App Launch v2.2 | Not provided | ✓ AJ Auth Server, PKCE S256 |
| IHE ATNA audit | ✓ transaction logging | ✓ RFC 5425 TLS + BALP AuditEvent |
| MSH-10 deduplication | Transaction log only | ✓ 24h window, automatic |
| Admin portal | ✓ full web UI | ✓ Thymeleaf + HTMX |
| Cross-facility IPS summary | Not provided | ✓ JamSHR $summary, real-time |
| Commercial SLA | Community only | ✓ Standard / Enterprise / Government |
| Kubernetes Helm chart | Community charts | ✓ included |
| Licence | MPL 2.0 — free | AJ FHIR core Apache 2.0; JamBridge commercial |
The architectural difference
OpenHIM is a general-purpose middleware bus. It routes messages through a mediator chain but has no inherent understanding of clinical content. Each mediator must implement its own parsing, transformation, and consent logic. OpenHIM does not know what an ADT A01 means clinically, or that an OBX-8 = H requires a different downstream action than OBX-8 = N.
JamBridge is a clinical integration engine. The pipeline is not configurable precisely because clinical workflows have a correct order. Consent must happen before persistence. Identity must happen before transformation. A configurable pipeline is a pipeline where someone can make a clinically unsafe configuration.
What this means in practice
A typical OpenHIM deployment for one message type (ADT^A01) requires:
- An MLLP mediator to receive the message
- A transformation mediator to convert PID/PV1 to FHIR JSON
- A consent mediator to check whether the patient has consented
- An outbound mediator to write to a FHIR server
That is four mediators, each written in JavaScript or another language, each tested and maintained separately, each potentially deployed in a different order by different team members.
JamBridge does all of this in a single service with a fixed, auditable pipeline. Adding a second message type (ORU) requires zero new mediators — the same pipeline handles it with message-type-specific mapping in Stage 3.
Migration path from OpenHIM
Migration can be incremental. OpenHIM and JamBridge run side by side during migration — OpenHIM handles the message types not yet migrated, JamBridge handles the migrated types.
Week 1–2: Deploy JamBridge alongside OpenHIM on new MLLP port numbers. Begin mirroring ADT traffic.
Week 3–4: Validate FHIR R4 output from JamBridge against expected Patient and Encounter resources. Resolve HL7v2 segment edge cases from your HIS vendor.
Week 5–6: Redirect production ADT MLLP traffic to JamBridge :2575. Decommission the OpenHIM ADT mediator chain.
Week 8+: Full cutover. Remaining message types migrated. OpenHIM decommissioned.
The sending HIS never needs to change its configuration — traffic is redirected at the network layer by port number.