A lot of community and critical-access hospitals are in an awkward middle. They still run an older MEDITECH platform, MAGIC or Client/Server, and they are partway through moving to Expanse, MEDITECH's modern web-based EHR. The integration team is caught between two worlds: legacy HL7 v2 interfaces that cannot be broken, and new FHIR endpoints that downstream systems want to use. This guide is about using Mirth Connect to bridge that gap so modernization happens without a risky big-bang cutover.
We have built EHR integrations and modernization layers for 30+ healthtech startups and health systems, and the pattern below, an engine in the middle that hides which era the data came from, is the one that consistently de-risks these projects.
What MEDITECH looks like in 2026
There are effectively two MEDITECHs in the field. The legacy platforms, MAGIC and Client/Server, are MUMPS-based and integrate primarily through HL7 v2 messaging, ADT, ORM, ORU, and the rest, over MLLP. They are reliable and deeply embedded, which is exactly why hospitals are cautious about ripping them out.
Expanse is the modern evolution: web-based, cloud-friendly, and built around HL7 FHIR and SMART on FHIR, with a growing set of FHIR R4 endpoints covering core resources like Patient, Encounter, Observation, AllergyIntolerance, and Medication. MEDITECH also publishes a developer sandbox, the Greenfield Workspace, where teams can test FHIR calls and OAuth flows against sample data before touching a live system. If the standards underneath are unfamiliar, our guide to HL7 and the broader FHIR R4 specification is a good reference.
The catch during a migration is that both run at once. Some data lives in the legacy system, some in Expanse, and your downstream systems should not have to care which.
Why Mirth Connect is the right modernization layer
The temptation during an EHR migration is to point each downstream system directly at whichever MEDITECH platform currently holds the data, then re-point everything on cutover day. That is how migrations turn into white-knuckle weekends. A better approach puts Mirth Connect in the middle as an abstraction layer.
With Mirth between MEDITECH and everything else, downstream systems talk to Mirth, not to MEDITECH directly. During the migration, Mirth decides whether a given message or query is served from the legacy interfaces or from Expanse FHIR, and it presents a consistent output either way. This is the classic strangler pattern applied to healthcare integration: you move capabilities to Expanse one at a time, and the engine keeps the outside world stable. We wrote about the underlying technique in building a FHIR facade over legacy HL7v2 systems.
If Mirth is new to your team, our complete guide to Mirth Connect and the architecture and deployment guide cover the fundamentals. The same engine pattern applies to other vendors, too, as our Cerner integration guide shows.
Two eras, one engine
The two sides have genuinely different shapes. Legacy MEDITECH speaks HL7 v2 over MLLP and pushes events as they happen. Expanse speaks FHIR R4 over REST and is something you query or subscribe to. Mirth's role differs on each: on the legacy side, it keeps existing interfaces flowing and reshapes them; on the Expanse side, it adapts FHIR responses and routes them to the same destinations. For the migration strategy itself, our HL7 v2 to FHIR migration framework lays out how to decide what moves when.
The architecture during migration
The shape is a single Mirth channel, or a small set of them, sitting between MEDITECH and your modern stack. The source connector receives either a legacy HL7 v2 message or the result of an Expanse FHIR call. The filter drops what is not needed. The transformer does the heavy lifting: mapping MEDITECH's internal dictionaries and mnemonics to standard codes, and reshaping everything into one consistent model. The destination connector writes to your FHIR store, your application database, or a downstream service.
That dictionary mapping is the part that teams underestimate. Legacy MEDITECH carries local codes that mean nothing to an outside system, so you need a maintained lookup that translates them to LOINC, SNOMED, and ICD. Our HL7 v2 to FHIR R4 mapping guide covers building these tables, and the broader job of turning HL7 v2 streams into modern FHIR APIs is exactly this pattern at scale.
A migration that does not require a big-bang weekend
The reason this setup matters is that it changes the risk profile of the whole project. Instead of one terrifying cutover, you get an incremental move. You stand up Mirth and route current downstream traffic through it, so nothing changes for consumers yet. You connect the Expanse FHIR endpoints in the Greenfield sandbox and validate them. You move one data domain at a time, for example, lab results, from the legacy feed to Expanse, while Mirth keeps the output identical for downstream systems. You run both in parallel and reconcile until the numbers match. Only then do you retire the legacy interface for that domain.
Because the engine hides the source, a problem with one domain never forces a rollback of the entire migration. This is the same zero-downtime thinking we described in modernizing 52 healthcare interfaces with zero downtime. To keep a growing set of channels manageable, use consistent channel design patterns and give each one a dead-letter and replay path so a failed message during migration is recoverable, not lost.
What flows, and what to watch
On the legacy side, you will be handling the familiar HL7 v2 traffic: ADT for patient movement, ORM for orders, ORU for results, and SIU for scheduling. On the Expanse side, you will pull FHIR resources such as Patient, Encounter, Observation, Condition, and Medication. The two will not always agree perfectly during the transition, which is the whole reason for the reconciliation step.
Watch for mismatched identifiers between the old and new systems, codes that map cleanly in one platform but not the other, and timing differences where an event arrives on the legacy feed before the FHIR resource is queryable. None of these are blockers; they are simply things the transformer and your reconciliation checks need to account for.
Where MEDITECH modernization projects stall
A few realities slow these projects down, and naming them early saves weeks. First, Expanse FHIR coverage is real but not infinite: the resource set is growing, and the data element you need may be available through a FHIR resource, a legacy interface, or both, with subtle differences. Confirm coverage for your specific use case in the Greenfield sandbox before you design around it. Second, MEDITECH dictionaries are deep and hospital-specific, so two sites running the same MEDITECH version can still code the same concept differently, which means your mapping tables are partly bespoke per site. Third, the hospital's own interface team has finite capacity, and during a migration, they are busy; the more your Mirth layer can absorb without asking them for changes, the faster you move.
The phrase to be skeptical of is "supports FHIR." Supporting a standard is not the same as delivering every data element you need, with consistent coding and predictable search behavior. Treat vendor capability claims as a starting point to verify, not a guarantee, and budget time for the gaps you find.
Choosing what to move first
Not every domain should migrate on day one. The pattern that works is to sequence by value and safety. Start with read-heavy, high-traffic data that benefits most from modern access. Results and patient demographics are common first moves, because they are well covered by FHIR and easy to reconcile against the legacy feed. Defer anything that writes back into MEDITECH, since write operations are more constrained and carry more risk, and treat them as a later, carefully scoped phase.
Within each domain, prove the Expanse path in parallel before you trust it. Let the legacy interface and the FHIR path both run, compare outputs for a defined period, and only retire the legacy feed once the two agree. This domain-by-domain rhythm is slower on paper than a single cutover, but it is far faster in practice because you are never recovering from a failed weekend. It also gives clinical and operational stakeholders visible, low-risk progress, which keeps a multi-month modernization funded and supported.
Security and compliance
Both paths handle Protected Health Information, so a Business Associate Agreement is required regardless of which MEDITECH platform the data comes from. Expanse FHIR uses OAuth 2.0 and SMART on FHIR scopes; legacy interfaces rely on network-level trust arranged with the hospital. We sign BAAs with US health systems and digital health customers, and we build on HIPAA-compliant, SOC 2 Type II, and ISO 27001 certified infrastructure with FHIR R4 native architecture. For the SMART authorization model specifically, the SMART on FHIR documentation is the canonical reference.
This content describes engineering patterns. It does not include actual Protected Health Information. All data examples are synthetic.
How Nirmitee.io approaches MEDITECH modernization
Healthcare is the only industry we serve, and legacy-to-modern bridging is a recurring part of the work. Our architecture is FHIR R4 native, so the Expanse side of a bridge is home ground rather than a bolt-on. We have also open-sourced a Headless EHR covering 28 clinical domains and more than 70 FHIR R4 resources, which is the same modeling discipline a MEDITECH modernization needs on the destination side. The pattern we see succeed is always the same: no rip-and-replace, an engine in the middle, and a domain-by-domain move rather than a single cutover.
If you are bridging legacy MEDITECH to Expanse and want a second set of eyes on the plan, or want the integration layer built, share your situation at nirmitee.io, and we will tell you what we have shipped for similar modernization work.
