Do not "migrate" HL7 v2 to FHIR by rewriting interfaces that work. Keep stable v2 feeds (ADT, ORU, ORM, DFT) on an interface engine, convert them to FHIR at the edge where new consumers need it, run old and new paths side by side with automated diffing, and only retire a v2 feed when its last consumer has moved.
Two things made this a 2026 decision for many teams. NextGen moved Mirth Connect to a closed-source, paid license from version 4.6, so "free engine plus open source" is no longer the default. And Microsoft deprecated Azure API for FHIR on September 30, 2026, forcing anyone who used it as a conversion target to re-platform. Meanwhile, new consumers (AI agents, analytics, payer APIs under CMS-0057-F) want FHIR. This guide covers the patterns that work, the engines in play, and the parts you should leave alone.
Should you replace HL7 v2 with FHIR?
Usually not wholesale. HL7 v2 is still how most hospital systems move ADT events, orders and results, and those feeds are stable, monitored and understood by every analyst on site. Replace v2 only where a consumer needs something v2 does not give: query on demand, RESTful access, or standard APIs for patients, apps and payers.
A useful way to think about it: v2 is a push of events; FHIR is (mostly) a pull of state. They solve different problems. FHIR adds Subscriptions for push, but in production EHRs those are still uneven; athenahealth's FHIR subscription platform, for example, is documented as a limited alpha. Plan for both models to coexist for years.
| Keep on HL7 v2 | Expose as FHIR | Rebuild on FHIR |
|---|---|---|
| ADT feeds to downstream systems that already work | Patient, Encounter, Observation views for new apps and AI agents | Point-to-point custom feeds nobody can maintain |
| Lab and radiology orders/results with external partners | Data for payer APIs (CMS-0057-F) and patient access | Batch file drops that should be queries |
| Charge (DFT) feeds into billing | Analytics extracts via Bulk FHIR or flattened views | Interfaces being replaced anyway by an EHR change |
| Device and instrument interfaces with vendor certification | Read models for portals and dashboards | New integrations with no v2 history |
What changed with Mirth Connect licensing?
Starting with version 4.6, NextGen moved Mirth Connect to "a single, closed-source, proprietary license," and "the source code for new releases will no longer be publicly available." To upgrade to 4.6 and beyond you must buy a license from NextGen. The last open-source release on NextGen's GitHub is 4.5.2, from September 2024.
NextGen's Mirth Connect downloads page lists Enterprise, Gold and Platinum tiers with "Speak with Sales" and no public prices. Your options:
- Buy the commercial license. Sensible if you want vendor support and a supported upgrade path. Get the price and tier limits in writing.
- Stay on 4.5.2. Short-term only. You inherit every unpatched issue from now on, which is hard to defend in a security review.
- Move to a community fork. Open Integration Engine describes itself as "an open source fork of the now closed-source Mirth Connect," is MPL-2.0 licensed, and shipped v4.6.0 in July 2026 and v4.7.0 in October 2026. Check its release cadence and contributor base against your risk appetite.
- Move to another commercial engine such as Rhapsody, InterSystems HealthShare / IRIS for Health, or iNTERFACEWARE Iguana. Get each vendor's licensing model in writing, and compare on channel migration effort, not just license cost.
Whatever you choose, inventory first: channel count, message types, custom JavaScript transformers, code tables, and which channels carry PHI to external parties. That inventory is the real size of the job.
How do you map HL7 v2 messages to FHIR resources?
Start from the HL7 V2-to-FHIR implementation guide, then write explicit, tested mappings for your local variants. The HL7 Version 2 to FHIR IG (v1.0.0, STU 1, trial use) maps v2 messages, segments, data types and vocabulary to FHIR R4, as a cumulative mapping starting from v2.9.
The IG gives you the standard mapping. Production messages are never standard. What breaks mappings in practice:
- Z-segments carrying local data that matters (for example, a custom insurance or consent segment). Map them to extensions deliberately or drop them knowingly.
- Repurposed fields: a site that puts the MRN in PID-2 instead of PID-3, or a free-text code in a coded field.
- Local codes for labs, locations and visit types that need ConceptMaps to LOINC, SNOMED CT or your own value sets.
- Identity events: merges (ADT^A40), moves and link/unlink. These change which Patient a resource belongs to and are where most data-quality incidents start.
- Event versus state: an A08 update may carry the full patient or only what changed, depending on the sender. Your FHIR upsert logic must know which.
Converter options
Template-based converters help with the first 80%. Microsoft's $convert-data uses Liquid templates for HL7v2, C-CDA, JSON and FHIR STU3 to R4, with HL7v2 root templates for message types such as ADT_A01, ORU_R01, ORM_O01, VXU_V04 and SIU_S12. Microsoft warns that its default templates "aren't intended for production" and are unsupported, and tells you to host and register your own copies so behavior does not change between releases. That advice applies to any converter: version your mappings like code.
What is the safest migration pattern?
A facade with dual running. Leave the v2 feed untouched, tap it into a conversion pipeline that writes FHIR, point new consumers at FHIR, and compare outputs automatically until the numbers match. Then move existing consumers one at a time.
- Tap, do not cut. Duplicate the v2 stream in the engine (a second destination), so the original path is unchanged.
- Convert and persist. Map to FHIR, validate against your profiles (US Core where it applies), and upsert into a FHIR server with idempotency keyed on the message control ID (MSH-10) plus sender.
- Diff continuously. For every message, compare the FHIR result with what the legacy consumer stored. Track mismatch rate by message type and field.
- Move consumers one by one, starting with the lowest-risk read-only consumer.
- Retire a feed only when nothing reads it. Keep the ability to replay v2 messages into the new path for at least one full business cycle.
This is slower than a cutover weekend, and much cheaper than a patient-identity incident.
What should you not rewrite?
Do not rewrite stable external interfaces with labs, imaging, pharmacies and billing partners unless the partner asks. Do not rewrite device interfaces that carry vendor or regulatory validation. And do not rewrite a feed into a system that is being retired within 18 months anyway.
Each of those carries testing and contract work with another organization that your FHIR roadmap does not pay for. Put the FHIR layer behind them instead. The same logic applies to vendor-certified EHR interfaces: Epic, for example, still provides HL7 v2 and X12 specifications through Vendor Services alongside FHIR, because both remain in use. Our guide to integrating with Epic in 2026 covers when each path fits.
What did the Azure API for FHIR deprecation change?
Microsoft deprecated Azure API for FHIR on September 30, 2026; new deployments had been blocked since April 1, 2025. Teams must move to the Azure Health Data Services FHIR service or another FHIR server, and re-test every pipeline that wrote to the old endpoint.
Microsoft's migration FAQ points to a migration tool and lists benefits of the newer service, including incremental $import and FHIR events. The lesson for anyone designing a v2-to-FHIR pipeline: keep the FHIR server behind an interface you control, and keep conversions and validation in your own versioned code, so a platform change is a re-point and a re-test rather than a rebuild.
How do AI agents change HL7 v2 integration?
Agents need queryable, current, well-coded data with clear provenance. That usually means a FHIR read model fed by v2 events, not an agent parsing raw HL7 pipes. The agent reads FHIR through narrow tools; the interface engine keeps doing what it does well.
Three design rules: give the agent read access to the FHIR model, not to the engine; route any write the agent proposes through a human approval step and then through the normal interface path, so downstream systems see a normal message; and keep provenance (which v2 message produced which FHIR resource) so you can explain any answer. For auth on that read model, see SMART on FHIR backend services; for controls, HIPAA-compliant AI agents.
How do you test a v2-to-FHIR pipeline?
Use real (de-identified) message samples per sender and message type, a regression suite that runs on every mapping change, profile validation on every output, and production diffing during dual running. Test identity events and out-of-order messages explicitly.
- Golden files: input message, expected FHIR bundle, checked in next to the mapping.
- Edge cases: merges, cancellations (A11, A13), corrected results, repeated segments, empty required fields, non-ASCII names.
- Ordering: send updates before creates and confirm the pipeline queues or rejects correctly.
- Replay: re-run a day of traffic and confirm the FHIR store converges to the same state.
- Monitoring: mismatch rate, dead-letter queue size and lag, all with alerts.
For the security side of the pipeline, our HIPAA-compliant software development guide covers logging, encryption and access control.
How BeevR builds this
We start with an inventory of channels, message types, custom code and consumers, then design the facade, mappings and diffing before touching a production feed. We build converters as versioned, tested code, run dual paths until mismatch rates are acceptable, and leave stable v2 interfaces alone. We will tell you when a commercial engine license is cheaper than a rebuild. BeevR signs a BAA as a business associate, models used for any AI layer can run inside your own AWS account under the AWS BAA, and you own the source code and IP from day one.
Our senior, founder-led team in Hanoi runs a multi-tenant EHR live across four US clinics at about 300 patients a day, with a working demo every Friday and fixed-scope, fixed-price phases from $10K per phase. See our EHR integration services and healthcare AI agent development.
Facing a Mirth renewal or a FHIR platform move? Book a 30-minute call and we will help you size the migration and decide what to leave on v2.