MEDITECH Integration Guide: Expanse, MAGIC, FHIR & HL7 in 2026

MEDITECH is the quiet giant of the US community-hospital EHR market. More than 2,300 hospitals and healthcare facilities run some flavor of MEDITECH — Expanse in newer deployments, MAGIC and C/S in long-standing installs, and MEDITECH-as-a-Service (MaaS) for those that prefer MEDITECH to host the platform. If you are building a healthcare product or a hospital-side integration in the United States, you will meet MEDITECH sooner than later.

This guide is written for integration engineers, product teams, and health-IT leaders who need to plan a MEDITECH project accurately. It covers the platform landscape, the real integration surfaces (Greenfield FHIR, HL7 v2, M-AT, NPR reports), deployment patterns we see repeatedly in community hospitals, and the role Mirth Connect plays as the translation and routing layer between MEDITECH and everything else.

If you want a broader starting point, see our EHR integration guide, HL7 integration guide, and FHIR integration guide.

1. MEDITECH in the EHR Landscape

MEDITECH (Medical Information Technology, Inc.), founded in 1969 and headquartered in Westwood, Massachusetts, is the third-largest US inpatient EHR vendor by hospital count. While Epic and Oracle Health dominate large academic and IDN segments, MEDITECH holds a dominant position in community hospitals, critical-access hospitals, and regional health systems.

That positioning matters for integration work. MEDITECH customers are often smaller IT organizations with lean integration teams, tight budgets, and a strong preference for stable, proven patterns. They rarely have the in-house Mirth or Rhapsody expertise of an academic medical center. They need integration partners who understand the MEDITECH idiosyncrasies and can deliver without a six-month consulting engagement.

A few key facts to keep in mind as you plan:

MEDITECH is currently shipping Expanse, a web-based platform with modern FHIR R4 APIs under the Greenfield program.
A significant share of MEDITECH customers still run MAGIC or C/S (6.x). These installs lean on HL7 v2 interfaces and M-AT reporting.
MEDITECH-as-a-Service (MaaS) is growing — MEDITECH hosts the platform and provides operational services.
MEDITECH’s ONC-certified API set maps to the US Core FHIR profiles required by the 21st Century Cures Act.

For a competitive comparison across vendors, see our Epic integration overview and Cerner / Oracle Health integration overview.

2. Expanse, MAGIC, C/S, and MaaS — What You’re Integrating With

The single most important step in planning a MEDITECH integration is confirming which MEDITECH platform the hospital is actually running. Ask early and confirm in writing. Integration patterns, APIs, and even error behaviors differ substantially.

2.1 Expanse

Expanse is MEDITECH’s current flagship, launched in 2018 and continuously modernized. It’s web-based (no more thick-client hospital workstations), has a responsive UI tuned for mobile, and exposes modern integration surfaces:

Greenfield FHIR R4 APIs — patient, encounter, observation, condition, medication, allergy, immunization, document, and a growing set of US Core resources.
HL7 v2 interfaces for ADT, ORM, ORU, MDM, SIU, and DFT with near-real-time delivery via MLLP.
SMART on FHIR launch and authorization for provider- and patient-facing apps.
Webhooks and event notifications for subscription-style integration patterns (varies by customer config).

2.2 MAGIC

MAGIC is the original MEDITECH platform, dating back to the 1980s and built on MEDITECH’s own programming language. Hospitals still running MAGIC tend to be long-established community hospitals with heavily customized workflows. Integration options are narrower:

HL7 v2 interfaces (well-supported but often with older v2.3 or v2.4 message structures).
NPR reports and M-AT access transformations for read-only data extraction.
Limited or no FHIR support unless a newer MEDITECH module has been added alongside.

If your target hospital is on MAGIC, plan for HL7 v2 as the primary surface and M-AT for reporting gaps. FHIR is usually not an option here.

2.3 Client/Server (C/S, also 6.x)

C/S is the intermediate generation: a client-server architecture running on Windows servers with Windows client applications. It supports richer HL7 v2 interfaces, some web services, and — in newer revisions — a subset of FHIR. Many hospitals used C/S as a bridge toward Expanse. Integration-wise, C/S behaves closer to MAGIC than to Expanse for most use cases.

2.4 MEDITECH-as-a-Service (MaaS)

MaaS is MEDITECH’s hosted Expanse offering. The hospital doesn’t run the MEDITECH servers; MEDITECH does. Integration patterns are identical to on-prem Expanse in terms of protocols, but network access, firewall rules, and VPN connectivity are negotiated with MEDITECH, not the hospital’s on-prem network team. Expect extra lead time for security review and network setup.

3. Interface and API Options — A Menu

The practical integration surfaces you will actually use on a MEDITECH project:

Greenfield FHIR R4 (Expanse) — REST/JSON APIs for US Core resources with OAuth 2.0 authorization.
HL7 v2 MLLP interfaces — the bread and butter for near-real-time messaging across all three platforms.
M-AT access transformations — SQL-like views for legacy reporting and analytics extraction.
NPR reports — MEDITECH’s native reporting tool, sometimes used as a batch extraction source when nothing else works.
Webhook/subscription events (Expanse) — event-driven push to subscribers.
Inbound HL7 v2 for orders and results — outside systems push ORM/ORU into MEDITECH.

Most production integrations combine two or three of these. A typical lab integration, for example, might use HL7 v2 ORM outbound to the lab, HL7 v2 ORU inbound from the lab, and FHIR Patient lookups for demographic reconciliation.

Comparison matrix

Surface              | Platform         | Latency      | Use case
---------------------|------------------|--------------|---------------------------
Greenfield FHIR R4   | Expanse / MaaS   | Sync (ms)    | App integration, read APIs
HL7 v2 MLLP          | Expanse/MAGIC/CS | Near-RT      | ADT, orders, results
M-AT                 | MAGIC / C/S      | Batch        | Reporting, analytics
NPR reports          | All              | Batch        | Legacy extraction
Webhooks (sub)       | Expanse          | Event-driven | Change notifications

4. Greenfield FHIR APIs — The Modern Path

MEDITECH Greenfield is the FHIR API program. If you are building a new application and the hospital runs Expanse, this is where you start.

4.1 Resource coverage

Current Greenfield FHIR R4 endpoints broadly cover the US Core profile set, including:

Patient, Practitioner, PractitionerRole, Organization, Location
Encounter, Appointment, Schedule, Slot
Observation (labs, vitals, social history), DiagnosticReport
Condition, AllergyIntolerance, Immunization, Procedure
MedicationRequest, MedicationStatement, MedicationAdministration
DocumentReference, Binary (for CDA/PDF retrieval)
CarePlan, Goal, CareTeam

Scope and depth vary slightly by hospital configuration and MEDITECH release train. Validate early with the actual target hospital — not just the Greenfield sandbox.

4.2 OAuth 2.0 and SMART on FHIR

Greenfield uses OAuth 2.0 with SMART on FHIR launch context. For provider-facing apps launched from within MEDITECH Expanse:

# Typical SMART on FHIR launch sequence
1. User launches your app from Expanse
2. Expanse redirects to your launch URL with launch and iss params
3. Your app fetches the FHIR server's smart-configuration
4. Your app redirects user to the authorize endpoint
5. User approves (SSO from Expanse in most cases)
6. Authorization server redirects back with code
7. Your app exchanges code for access token
8. Your app calls FHIR APIs with Bearer token

For backend / system-level integrations (no user in the loop), use SMART Backend Services with JWT client assertion. Scopes and supported grant types are documented per endpoint in Greenfield’s developer portal.

4.3 Write-back support

Read operations (GET) are broadly available. Write operations (POST/PUT) are narrower — the resource and hospital configuration both matter. Assume read-first, and where write is needed, clarify exactly which resources support create/update on the target hospital’s production endpoint. For many real write-back needs (e.g., lab orders), HL7 v2 ORM remains the practical option even when FHIR is in place.

5. M-AT (MEDITECH Access Transformations)

M-AT is MEDITECH’s framework for exposing data as SQL-queryable views. It’s especially important on MAGIC and C/S where FHIR doesn’t cover the gaps. Common uses:

Nightly population-health extracts (claims, labs, demographics).
Quality reporting feeds into registries and analytics platforms.
Custom reports where HL7 v2 doesn’t carry enough data.
Data warehouse hydration for enterprise BI.

M-AT access is configured by the hospital’s MEDITECH administrator. You typically request the specific views you need, get read-only database credentials (or an ODBC/JDBC endpoint), and schedule extracts. Treat M-AT data with the same PHI handling rigor as any other MEDITECH data surface.

A Mirth Connect channel is often the cleanest way to run M-AT extracts: use the Database Reader source connector, schedule a nightly poll, transform into FHIR or a downstream schema, and route into your destination system.

6. HL7 v2 Interfaces on MEDITECH

HL7 v2 remains the workhorse of MEDITECH integrations across every platform. The typical MEDITECH hospital has 30–100 active HL7 v2 interfaces running.

6.1 Common message types

ADT (admission, discharge, transfer) — the fundamental demographics/encounter feed.
ORU (observation results) — lab and imaging results.
ORM (orders) — lab, imaging, and pharmacy orders.
MDM (document management) — clinical documents and transcriptions.
SIU (scheduling) — appointment scheduling events.
DFT (financial) — charge capture events.

6.2 Version and framing

Expect 2.3, 2.4, 2.5, or 2.5.1 depending on interface age. Framing is MLLP over TCP. For HIPAA-safe transport, MLLP over TLS (MLLPS) is strongly recommended.

For background on MLLP and when connections break, see our MLLP connection refused troubleshooting guide.

6.3 Sample ADT^A01 from MEDITECH

MSH|^~\&|MEDITECH|HOSP|DOWNSTREAM|VENDOR|20260421093000||ADT^A01|MSG12345|P|2.5
EVN|A01|20260421093000
PID|1||MRN1234567^^^HOSP^MR||DOE^JOHN^A||19780115|M||2106-3|123 MAIN ST^^ANYTOWN^MA^01234||(555)555-1234|||S||ACCT987654
PV1|1|I|3W^302^A|||ATT123^SMITH^JANE^L^^DR|CON456^ROE^ALEX^M^^DR|||MED||||A|||DIS1||V1||||||||||||||||||||||HOSP|||||20260421093000

7. Mirth Connect as the Integration Layer

MEDITECH ships with its own interface capabilities, and on Expanse those are capable. Still, most MEDITECH hospitals we work with adopt Mirth Connect as a dedicated integration layer for a few strong reasons:

Vendor neutrality. Mirth runs outside MEDITECH and can talk to any downstream system without touching the core EHR.
Transformation power. JavaScript transformers, code templates, and HL7 ↔ FHIR translation that MEDITECH’s native tooling can’t match.
Operational visibility. Centralized dashboards, alerting, and message history across dozens of interfaces in one console.
Cost. Open-source Mirth Connect (NextGen’s community edition) avoids per-interface licensing fees.
Upgrade decoupling. MEDITECH upgrades and Mirth upgrades happen on separate cadences, limiting risk.

A typical deployment puts Mirth between MEDITECH and the outside world: HL7 v2 MLLP listeners receive from MEDITECH, transformers translate, and destination connectors push to FHIR endpoints, REST APIs, SFTP destinations, or other HL7 v2 receivers. Outbound orders flow in reverse.

7.1 Example channel layout

Inbound from MEDITECH (MLLP listener)
      →  Preprocessor (normalize MSH, strip BOM)
      →  Filter (valid message types only)
      →  Transformer (HL7 v2 → internal JSON)
      →  Router
          ├─ Destination 1: FHIR POST to registry
          ├─ Destination 2: MLLP to downstream LIS
          └─ Destination 3: SFTP for nightly batch

8. Typical Community-Hospital Deployment Pattern

A representative MEDITECH community-hospital integration environment has:

1–2 MEDITECH production hosts (Expanse) plus test / non-prod.
Mirth Connect cluster (typically a primary + warm standby) running on-prem or in a private cloud.
Firewall segmentation between the clinical network and the integration engine DMZ.
20–80 active HL7 v2 interfaces (ADT, lab, radiology, pharmacy, scheduling, document routing).
A handful of FHIR integrations for newer apps (patient portal, telehealth, care-coordination vendors).
A data warehouse or analytics extract pipeline fed by M-AT or NPR reports.
An HIE connection (statewide or regional).

For broader reference architectures, see our healthcare interoperability guide.

9. Data Model Gotchas

MEDITECH’s data model is consistent once you learn it, but there are a handful of traps worth knowing upfront.

9.1 MRN vs account number

MEDITECH distinguishes the enterprise medical record number (MRN, relatively stable across visits) from the per-encounter account number. PID-3 typically carries the MRN; PID-18 (Patient Account Number) carries the encounter-level account. Downstream systems often conflate these, producing duplicate records. Confirm the identifier strategy before you build.

9.2 HCIS codes and multi-site installs

In multi-hospital MEDITECH installs, the HCIS site code distinguishes each facility inside the shared database. Demographics and encounter identifiers are not globally unique without the HCIS code. Your integrations must preserve this in HL7 v2 (often in PID-3 assigning authority) and in FHIR (via appropriate identifier systems).

9.3 Date/time formats

Expanse FHIR uses ISO 8601 with timezone. HL7 v2 interfaces use MEDITECH’s traditional YYYYMMDDHHMMSS (local time, no zone). Legacy M-AT exports may use further variants. Always normalize to UTC at the Mirth layer and preserve the original string for audit.

9.4 Order and result linkage

Lab orders (ORM) and results (ORU) are linked by placer order number (ORC-2) and filler order number (ORC-3). On MEDITECH, these can flip in unexpected ways across interfaces — a common bug is assuming consistent ordering of identifier pairs. Always test with real message samples.

10. Project Plan — A Realistic 12-Week Timeline

For a standard MEDITECH integration (ADT feed inbound, ORM orders outbound, ORU results inbound, plus a FHIR patient-lookup), here’s what the 12-week timeline looks like in practice:

Week 1–2  Discovery
          • Confirm platform (Expanse/MAGIC/C/S/MaaS)
          • Inventory message types, volumes, peak loads
          • Identify site codes, identifier strategy
          • Security & HIPAA review kickoff
          • Request Greenfield sandbox (if Expanse)

Week 3–4  Design
          • Target architecture (Mirth placement, failover)
          • Message specs, mappings, transformations
          • Sandbox credentials and firewall rules
          • Error-handling and alerting approach

Week 5–7  Build
          • Mirth channel development
          • HL7 v2 transformers and code templates
          • FHIR client code and OAuth handling
          • Unit test harness with synthetic messages

Week 8–9  UAT in test
          • Mirror of production volumes
          • Clinical SME sign-off
          • Error injection and recovery rehearsal
          • Performance test

Week 10   Staging / pre-prod
          • Production-like environment
          • Go/no-go checklist walkthrough
          • Runbook drafted

Week 11   Go-live
          • Cutover weekend
          • Dual-run with old path if feasible
          • Hypercare stand-by

Week 12   Hypercare
          • Daily standups
          • Incident response
          • Fine-tune thresholds, alerts
          • Project closeout & knowledge transfer

For broader planning context, see our EHR integration project timeline and EHR integration cost guide.

11. Common Pitfalls (and How to Avoid Them)

11.1 Assuming FHIR everywhere

Greenfield FHIR is great on Expanse. It’s missing or limited on MAGIC/C/S. Don’t scope an integration around FHIR without confirming the target platform.

11.2 Treating sandbox = production

Greenfield’s developer sandbox shares schemas with production but not content, config, or scoping. Every hospital enables production access separately. Plan a per-site provisioning step in your go-to-market.

11.3 Under-investing in monitoring

Community hospitals often have small IT teams. If you build an integration that doesn’t monitor itself and page on failure, you will discover problems through angry clinicians rather than dashboards. Wire up alerts from day one — listener down, queue depth high, message error rate spike, certificate within 30 days of expiry.

11.4 Not sizing for volume

An average community hospital produces 10,000–100,000 HL7 messages per day. Bursty ADT load during morning admissions can triple baseline rates for 1–2 hours. Size your integration engine and downstream consumers for the bursty peak, not the daily average.

11.5 Skipping the identifier strategy conversation

Get clear early: what is the canonical patient identifier across the integration? MRN from MEDITECH? A global identifier from a master patient index? How are merges and duplicates handled? Put this on paper and get sign-off before building.

12. Frequently Asked Questions

What is the difference between MEDITECH Expanse and MAGIC / C/S?

Expanse is MEDITECH’s current web-based, cloud-native platform launched in 2018 and steadily modernized since. MAGIC (the original mainframe-era platform) and C/S (Client/Server, sometimes called 6.x) are legacy platforms still running in hundreds of US community hospitals. Expanse supports modern FHIR R4 APIs out of the box; MAGIC and C/S typically rely on HL7 v2 interfaces, NPR reports, and M-AT access transformations for integration.

Does MEDITECH support FHIR?

Yes. MEDITECH Greenfield is the FHIR API program, providing FHIR R4 endpoints for Patient, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, Immunization, DocumentReference, and a growing set of US Core resources. Availability and scope depend on platform (Expanse vs legacy) and on whether the hospital has enabled the Greenfield APIs for third-party access.

What is MEDITECH-as-a-Service (MaaS)?

MaaS is MEDITECH’s fully-hosted offering where MEDITECH hosts the Expanse platform for the hospital, including infrastructure, upgrades, and some operational functions. Integration patterns are similar to on-prem Expanse, but endpoints live in MEDITECH’s hosting environment and network access is negotiated through MEDITECH rather than the hospital’s on-prem network.

What is M-AT?

M-AT stands for MEDITECH Access Transformations. It is a framework used in legacy MEDITECH platforms (MAGIC and C/S) to expose data via SQL-like views and reports. When FHIR or HL7 v2 doesn’t cover a data need, M-AT is a common way to build read-only reporting pipelines from legacy MEDITECH into data warehouses, analytics platforms, or integration engines.

Why use Mirth Connect with MEDITECH?

MEDITECH’s native interface engine (often branded Transcription/Interface) handles HL7 v2 within the MEDITECH ecosystem, but outbound integrations to registries, payers, population-health platforms, specialty EHRs, and cloud analytics are usually easier in a standalone engine. Mirth Connect is a popular choice: it handles MLLP, HL7 v2, FHIR R4, X12, and custom APIs, with HIPAA-aware logging and alerting. It sits between MEDITECH and downstream systems as the translation and routing layer.

How long does a MEDITECH integration project typically take?

A straightforward ADT + ORU + ORM interface set into a third-party system typically runs 8–12 weeks including discovery, build, UAT, and go-live. FHIR-based integrations (using Greenfield APIs) can be faster for read-only use cases (4–8 weeks) but slower for write-back scenarios where permissions, access, and patient-matching rules add complexity. Legacy MAGIC / C/S integrations usually take longer because of the smaller pool of available engineers and the reporting-layer gymnastics required.

What sandbox access does MEDITECH offer?

MEDITECH Greenfield provides a developer sandbox with synthetic patient data and FHIR R4 endpoints. Access goes through MEDITECH’s Greenfield program (application and review). Each hospital’s production FHIR endpoint is separately enabled — developer sandbox credentials do not give you access to a live hospital. Expect a procurement and security review at every hospital where you want to enable production integration.

Can I write data back to MEDITECH via FHIR?

Partially. Read (GET) FHIR resources are broadly supported across US Core resources. Write capabilities (POST/PUT/PATCH) are narrower and vary by resource and by hospital configuration. For write-back workflows — creating observations, placing orders, updating conditions — expect to combine FHIR writes where supported with HL7 v2 ORM/ORU messages where FHIR isn’t yet practical. Plan for a hybrid architecture.

What are the biggest integration gotchas with MEDITECH?

Three recurring ones: (1) MRN and account-number handling — MEDITECH uses distinct identifiers, and getting patient matching right requires careful mapping, (2) date/time formats vary between platforms and between legacy reports vs modern APIs, and (3) the difference between HCIS site code and hospital code in multi-site MEDITECH installations often trips up integrations going across more than one MEDITECH-running facility.

Do I need MEDITECH’s approval to build an integration?

For most modern integrations — especially FHIR — yes: the hospital enables Greenfield access for your application, typically after MEDITECH’s review. For HL7 v2 interfaces, approval comes from the hospital’s IT team (not MEDITECH directly) since interfaces are point-to-point configurations. In practice, expect both MEDITECH and the hospital’s IT and security teams to be in the loop for a production integration.

MEDITECH Integration Guide:Expanse, FHIR, HL7 v2 & Mirth Connect

Table of Contents