JamBridge & the Jam ecosystem — how it works in large hospital chains

What is JamBridge?

JamBridge is the HL7v2-to-FHIR R4 integration gateway at the centre of the Jam clinical data platform. It sits between your existing hospital information systems — Epic, Cerner, MEDITECH, or any HIS that speaks HL7v2 — and a FHIR R4 data store, translating decades of HL7v2 message traffic into modern, queryable, consent-governed FHIR resources in real time.

It is not a middleware bus or an iPaaS. It is a purpose-built clinical integration engine that understands the semantics of HL7v2 messages — why a PID segment means a patient identity event, why an OBX with a LOINC code means a lab result, why an RDE means a prescription that needs a drug safety check before it is written. That clinical understanding is baked into the 7-stage pipeline and cannot be bolted on after the fact.

Open source foundation. JamBridge is built on the AJ FHIR Platform — Apache 2.0. The HAPI FHIR server, Auth Server, Consent Manager, MPI, and Facility Registry are all open source. JamBridge is the commercial integration engine that connects them into a working clinical pipeline. You can audit every byte of the underlying infrastructure.

Core responsibilities

JamBridge does seven things, in order, for every HL7v2 message it receives:

1. Receive — raw HL7v2 bytes over MLLP, parse with HAPI HL7v2 Terser, stamp a transaction ID.
2. Deduplicate — check MSH-10 control ID against a 24-hour window in hie_transaction_log. Replayed messages are ACK’d without re-processing.
3. Enrich — resolve sending facility to a FHIR Organization via JamFR (ITI-90) and resolve patient to a golden record ID via JamMPI (ITI-119 $match).
4. Transform — PID → Patient, PV1 → Encounter, OBX → Observation with LOINC codes validated by JamTS.
5. Govern — call AJ Consent Manager via JamConnect. If consent is withheld, generate an HL7v2 NACK and stop. Fail-closed: NACK if consent service is unreachable.
6. Persist — conditional create/update to HAPI FHIR. Resilience4j circuit breaker protects HAPI from thundering-herd failures.
7. Dispatch — FHIR subscription fan-out, outbound MLLP, JamConnect POST_WRITE events, DHIS2 surveillance pushes, ATNA audit.

The 7-stage clinical pipeline

Every message enters the same pipeline. The stages are sequential and non-configurable — this is deliberate. Consent must be checked before data is written. Identity must be resolved before transformation. A general-purpose bus cannot enforce this ordering without custom mediators that re-implement clinical logic for every deployment.

Stage 1 — RECEIVE

Raw HL7v2 bytes arrive on a Camel MLLP consumer. MSH-10 is checked against hie_transaction_log. The Hl7v2Parser extracts typed objects using the HAPI HL7v2 Terser. Duration: ~3ms.

Stage 2 — ENRICH

FacilityCodeResolver calls JamFR on a 5-minute cache to resolve the MSH-4 facility code to a FHIR Organization reference. MpiClientService sends Patient/$match to JamMPI — Jaro-Winkler name scoring, date-of-birth similarity, and exact national ID matching. The golden record ID is stamped on the FHIR resource via Patient.link[refer].

Stage 3 — TRANSFORM

Hl7v2ToFhirMapper converts parsed HL7v2 to FHIR R4. PID fields become Patient demographics. PV1 becomes an Encounter. OBX segments become Observations — JamTS validates LOINC codes via ConceptMap/$translate and federates to Snowstorm for SNOMED CT diagnosis codes.

Stage 4 — GOVERN

JamConnectClient.checkConsent() calls AJ Consent Manager. Patient reference, actor, resource type, action (read/write), and purpose (TREAT/RESEARCH/PUBLIC-HEALTH) are checked. "permitted": false generates a NACK and stops the pipeline. Unreachable consent service also NACKs — fail-closed by design.

Stage 5 — PERSIST

FhirClientService.conditionalUpdate() sends PUT /fhir/Patient?identifier=... to HAPI. A circuit breaker protects against HAPI downtime — open-circuit messages queue in SecondaryRetryQueue with exponential backoff, up to 10 attempts. ConsentEnforcementInterceptor on HAPI provides a second consent check for any SMART app queries.

Stage 6 — DISPATCH

SubscriptionEventDispatcher evaluates 17 seeded FHIR subscriptions asynchronously. Matched channels fire outbound MLLP, FHIR REST, or SMS deliveries. JamConnect’s POST_WRITE event triggers IPS cache invalidation in JamSHR, CDS Hooks dispatch, and clinical alert escalation.

Stage 7 — ACK

MSA|AA is returned to the sending system on the same MLLP connection. Transaction log is finalised. An IHE ATNA AuditEvent is written asynchronously via RFC 5425 TLS syslog and as a BALP FHIR AuditEvent to HAPI. Audit writing never blocks the ACK path.

MLLP route configuration

JamBridge opens eight MLLP listeners, one per message type, each with its own Camel route and retry configuration.

The Jam ecosystem

JamBridge is one component in a coordinated platform of 10+ products. The integration points between components are all standard FHIR R4 operations — nothing proprietary.

Integration & coordination

JamBridge — HL7v2-to-FHIR R4 integration engine. The OpenHIM replacement with a clinical-grade pipeline. Port :8443.

JamConnect — Clinical intelligence facade. Single API coordinating JamMPI, AJ Consent, JamFR, CDS Hooks dispatch, and clinical event routing. Port :8091.

Identity & registry

JamMPI — Master Patient Index. Probabilistic matching across branches. CERTAIN/PROBABLE/POSSIBLE grades. Golden records unify a patient across all connected facilities. IHE PDQm (ITI-78), PIXm (ITI-83), PMIR. Port :8081.

JamFR — Facility Registry. mCSD-conformant ITI-90 hospital and clinic directory. Auto-provisioning from HL7v2 MSH-4 facility codes on first message from an unknown facility. Port :8089.

AJ Consent Manager — FHIR R4/R5 Consent lifecycle with patient portal. ConsentEnforcementInterceptor fires before every HAPI FHIR read/write. Deny-by-default. GDPR Art. 17 and HIPAA minimum necessary mapped to provision.class and provision.period. Port :8082.

AJ Auth Server — Complete SMART App Launch v2.2. Spring AS 1.3. PKCE S256 (96-byte verifier, 768-bit entropy — 3× spec minimum). RS256 id_token. Azure AD / Okta / Epic IdP federation. Port :9000.

Clinical services

JamSHR — Shared Health Record. Patient/$summary returns an IPS assembled in real time from all connected facilities. IHE MHD document store (ITI-65/66/67/68). Port :8084.

JamTS — Terminology Service. LOINC, SNOMED CT, ICD-10, and local lab code system mappings. $translate, $lookup, $validate-code. Snowstorm federation for full SNOMED CT. Port :8085.

JamReferral — Cross-branch referral state machine. FHIR ServiceRequest + Task. Five states: DRAFT → SENT → ACCEPTED → IN_PROGRESS → COMPLETED. 48-hour accept timeout with auto-escalation. Port :8093.

JamGuard — Cross-branch clinical safety. Drug-drug interaction (NLM RxNorm API), drug-allergy, missed follow-up, polypharmacy, duplicate prescription. Fires before every MedicationRequest write. Port :8094.

JamDHIW — Analytics warehouse. FHIR $export piped to DHIS2. Real-time notifiable disease surveillance: dengue (LOINC 80823-7), malaria (32700-2), TB (11545-1). Port :8086.

JamBridge vs OpenHIM

OpenHIM is the most widely deployed open source health interoperability middleware in low- and middle-income country deployments. JamBridge was built specifically to replace it in contexts where clinical depth, FHIR R4 nativity, and commercial-grade reliability are required.

Philosophy and architecture

The fundamental difference is architectural philosophy. 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.

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.

When OpenHIM is still the right choice. If your integration needs are primarily routing HL7v2 messages between systems without FHIR transformation, and you have the developer capacity to build and maintain custom mediators, OpenHIM remains a solid, free option. JamBridge is the right choice when you need real-time FHIR R4 transformation, cross-facility patient identity, consent enforcement, clinical safety rules, and a production-grade commercial SLA.

Feature comparison

Migration path from OpenHIM

1. Weeks 1–2: Deploy JamBridge alongside OpenHIM on new MLLP ports. Begin mirroring a subset of traffic.
2. Weeks 3–4: Validate FHIR output. Resolve any HL7v2 segment edge cases from your HIS vendor.
3. Weeks 5–6: Redirect production MLLP traffic to JamBridge. Decommission OpenHIM mediators for migrated message types.
4. Week 8+: Full cutover. OpenHIM decommissioned.

Hospital chain deployment

The hospital chain deployment is where JamBridge’s cross-facility architecture shows its value most clearly. A single patient attends multiple branches. Their medication is prescribed at one branch, their lab results are at another, their imaging is at a third. Without a unified golden record and a cross-facility FHIR store, safety events like drug-drug interactions across branches are invisible.

Cross-branch patient identity — the golden record

JamMPI resolves patient identity on every message using three strategies:

• National ID exact match — earns CERTAIN grade (score ≥ 0.95)
• Jaro-Winkler name + date-of-birth similarity — earns PROBABLE above the configurable threshold
• Blocking strategy — pre-filters candidates by first-3-chars of family name and birth year

The golden record ID is stamped on every FHIR Patient resource via Patient.link[type=refer] and a custom extension. Every downstream system that queries HAPI for this patient by golden ID gets all records from all branches.

Full data flow walkthrough

Here is what happens when Branch 01’s MEDITECH HIS admits a patient previously seen at Branch 03:

1. MEDITECH sends ADT^A01 to JamBridge on MLLP :2575. MSH-10 BR01-001 is checked — not a duplicate.
2. JamFR resolves MSH-4 BRANCH-01 to Organization/org-br01-001 (cached 5 min).
3. JamMPI runs Patient/$match. Finds CERTAIN match to GOLDEN-00441 — the same patient seen at Branch 03 under a different local MRN.
4. JamTS translates local lab codes to LOINC and SNOMED CT diagnosis codes via Snowstorm.
5. AJ Consent Manager: patient GOLDEN-00441, actor org-br01-001, resource Patient, action write, purpose TREAT. "permitted": true.
6. HAPI FHIR: PUT /fhir/Patient?identifier=MRN12345. ConsentEnforcementInterceptor fires. Patient written.
7. JamConnect POST_WRITE invalidates JamSHR IPS cache for GOLDEN-00441.
8. Dr. Smith opens JamPHR. GET /fhir/Patient/GOLDEN-00441/$summary returns an IPS from Branch 01, Branch 03, and the central lab — medications from both branches, allergies recorded at Branch 03, imaging from Branch 02’s PACS.
9. Dr. Smith orders Warfarin 5mg. RDE^O11 arrives on :2580. JamGuard finds Aspirin 100mg at Branch 03. NLM RxNorm: MAJOR interaction. Alert fires before the prescription is written.

Cross-branch safety rules

DRUG_DRUG_INTERACTION — On every MedicationRequest write, fetches all active medications for the golden patient across all branches and queries the NLM RxNorm Interaction API. MAJOR interactions block; MODERATE create a warning without blocking.

DRUG_ALLERGY — Checks new MedicationRequest against all AllergyIntolerance resources for the golden patient across all branches.

MISSED_FOLLOWUP — Hourly scan for Observations with OBX-8 = H or L from the last 72 hours for which no follow-up Encounter has been created.

DUPLICATE_PRESCRIPTION — Checks whether a new MedicationRequest is in the same ATC drug class as a medication already active from another branch within 30 days.

Go-live timeline for a 5-branch chain

IHE profiles and compliance

IHE profiles implemented across JamBridge and the Jam platform:

ITI-8 ITI-20 ATNA ITI-65/66 MHD ITI-67/68 MHD ITI-78 PDQm ITI-83 PIXm ITI-90 mCSD ITI-93/94 PMIR ITI-119 PIXm $match IPS $summary SMART v2.2 BALP AuditEvent WHO VDS-NC

Regulatory compliance: GDPR (Art. 17 erasure, Art. 30 audit trail), HIPAA (§164.312 audit, BAA available), HTI-1 (SMART on FHIR API certification), DISHA (consent artefact model).