Getting from a legacy EHR to a FHIR-first integration model rarely happens in one release cycle. Four migration paths cover most 2026 deployments; picking wrong forces re-work.
Path 1: Sidecar FHIR facade. Keep the legacy EHR intact, run a FHIR facade in front that translates FHIR REST calls to the EHR's proprietary API. HAPI FHIR's server can be configured for this. Best for large EHRs that can't be replaced.
Path 2: Dual-write pattern. New writes land in both the legacy EHR and a FHIR store. Reads gradually migrate to FHIR store over months. Best when a migration horizon exists but incremental cutover is required.
Path 3: HL7v2-to-FHIR pipeline. Existing HL7v2 message flows continue; a converter pipeline (via HL7v2-to-FHIR IG) translates into FHIR resources landing in a new store. Legacy stays HL7v2; new FHIR store grows.
Path 4: Greenfield FHIR-first. New EHR built on FHIR from day one. No migration; just design decisions upfront.
Decision factors
| Situation | Path |
|---|---|
| Legacy Epic/Cerner, no replacement plan | 1 (sidecar) |
| Multi-year replacement plan | 2 (dual-write) |
| HL7v2 heavy, willing to invest in converter | 3 (v2 pipeline) |
| Greenfield opportunity | 4 (FHIR-first) |
Where teams get stuck. Choosing dual-write without a real migration horizon leaves you running two systems forever. Choosing v2 pipeline without a converter budget produces bad-quality FHIR data. Match the path to the actual constraint, not the aspiration.
Related Posts
