Skip to main content

ADR 0048: Coexistence with third-party EMRs (e.g. OpenMRS) via FHIR and integration layer

Status​

Accepted — documentation baseline 2026-04-11.

Context​

National rollouts may include heterogeneous facility EMRs (e.g. OpenMRS at some sites) while the Ghasi platform serves as the interoperability, analytics, or national HIE backbone. A single “rip-and-replace” strategy is often infeasible; coexistence must be explicit.

Decision​

  1. Treat third-party EMRs as integration peers, not second-class data sources—subject to the same security, tenant/national scope, and audit rules as native Ghasi clients.
  2. Primary integration contract for structured clinical data: HL7 FHIR R4 through fhir-gateway and documented national profiles (see STANDARDS_ALIGNMENT.md).
  3. Legacy systems where FHIR is unavailable: HL7 v2 via hl7v2-interop with adapters mapping to canonical FHIR per interop/SOLUTION_DESIGN.md.
  4. Identity resolution (patient matching) follows ADR-0042 and national MPI policy—no automatic merge without explicit rules.
  5. Population health (health-population) and HMIS aggregates consume canonical platform events/projections; third-party feeds must normalize through the integration layer first.

Consequences​

  • Positive: Phased national adoption; reuse of existing OpenMRS investments; clear architecture story for donors.
  • Negative: Duplicate data entry risk if workflows are not unified—mitigate with integration depth milestones and change management.
  • Operational: Each peer system needs a supported integration profile (test harness, conformance checklist).

Non-goals​

  • Running OpenMRS inside Ghasi services.
  • Guaranteeing feature parity between OpenMRS UI and Ghasi ehr-web—only data interoperability is in scope for this ADR.