Why migrate?
OpenHIM routes messages. JamBridge transforms them — into FHIR R4, with identity enrichment, consent enforcement, terminology translation, and clinical safety checks baked into the pipeline. If your OpenHIM deployment consists of custom mediators that re-implement these concerns for every message type, you are carrying maintenance debt that grows with every new HIS integration.
The 8-week plan
Weeks 1–2: Deploy alongside OpenHIM
JamBridge listens on different ports to OpenHIM’s mediators. Deploy JamBridge in your environment — Kubernetes Helm chart or Docker Compose — without touching any existing OpenHIM configuration.
Configure BridgeConfig.yaml with your facility codes, MLLP port assignments, and the address of your HAPI FHIR server.
Weeks 3–4: Mirror and validate
Route a copy of your ADT A01 traffic to JamBridge using your network equipment or a simple MLLP forwarder. Compare the FHIR output from JamBridge against expected Patient and Encounter resources.
Common edge cases at this stage:
- Non-standard PID-3 identifier system URIs from your HIS vendor
- Missing MSH-4 facility codes that need mapping in JamFR
- Local lab codes in OBX-3 with no LOINC mapping in JamTS
Weeks 5–6: Production cutover for migrated types
Redirect the ADT MLLP stream from OpenHIM’s port to JamBridge’s :2575. Decommission the OpenHIM ADT mediator. Keep OpenHIM running for any message types not yet migrated.
Week 8+: Full cutover
All 8 MLLP streams redirected. OpenHIM decommissioned. JamBridge running in production with a 6-month parallel audit trail for comparison.