Nirmitee.io

For health tech products

MEDITECH Integration Services

We build MEDITECH integrations for health tech products: SMART on FHIR apps inside Expanse, backend and bulk FHIR data feeds, patient and scheduling apps, and HL7 v2 interfaces through Mirth Connect for Expanse, 6.x, Client/Server and MAGIC hospitals. We also run the access path with you, from Greenfield Workspace to go-live at each hospital. For the platform itself, read our MEDITECH Expanse guide.

Plan my MEDITECH integration

For digital health products, analytics and AI vendors, and health systems connecting software to MEDITECH hospitals. Updated September 2026.

What we build on MEDITECHSMART on FHIR apps in ExpanseBackend and bulk FHIRPatient and scheduling appsHL7 v2 via MirthData from MAGIC and Client/Server
Evidence you can check
  • ISO 27001:2022 certified
  • HIPAA-enabled: we sign BAAs
  • SMART on FHIR app run against the Epic and Oracle Health developer sandboxes in one session
  • Our team has built 350+ interfaces on Mirth Connect

What we build

Five things we build on MEDITECH.

MEDITECH hospitals run different platform generations, and the route depends on which one. Expanse exposes certified FHIR APIs; every generation still relies on licensed HL7 v2 interfaces for real-time feeds.

01

SMART on FHIR apps in Expanse

EHR launch and standalone launch

Clinician-facing apps that open from Expanse with patient context, or sign users in from your own app. Users log in through the hospital's own identity provider, such as Entra ID, Okta or Ping, and MFA is enforced there. Expanse 2.2 is certified on SMART App Launch 2.0.0 and US Core 6.1.0.

02

Backend and bulk FHIR data

Service-to-service, no user in the loop

Analytics, quality and AI feeds using SMART Backend Services with client credentials and a private key JWT. Expanse 2.2 is certified on Bulk Data Access 1.0.0 for population exports, and each hospital's FHIR base URL is published in MEDITECH's endpoint list.

03

Patient and scheduling apps

The patient-facing side of Expanse

Patient access apps read US Core FHIR R4 data after the patient authorizes the app. MEDITECH also offers FHIR Scheduling APIs for Expanse customers, with user and patient workflows, which we confirm with each hospital before building booking into scope.

04

HL7 v2 interfaces through Mirth Connect

Real-time feeds on every platform generation

MEDITECH's published outbound interfaces cover ADT with demographics and allergies, lab, microbiology and blood bank results, appointments and orders to lab and radiology vendors. We build and run the Mirth Connect channels, mapping, acknowledgements, alerting and replay against the hospital's interface specifications.

05

Data out of older MEDITECH platforms

MAGIC, Client/Server and 6.x

MEDITECH lists certified API versions for Expanse 2.2 and 2.1, 6.1 and 6.0, and MAGIC and Client/Server 5.67, and certifies EHI export. For hospitals still on older platforms, or moving to Expanse, we combine those exports with HL7 feeds to move and reconcile data.

Two kinds of access

Certified FHIR for reads. Licensed interfaces for real-time feeds.

Certified FHIR APIs

Where clinical data is read

Expanse 2.2 is certified under ONC (g)(10) on FHIR R4, US Core 6.1.0, USCDI v3, SMART App Launch 2.0.0 and Bulk Data 1.0.0. You build and test in Greenfield Workspace, then connect to each hospital's TEST and LIVE instances.

  • Patient, provider and backend authorization
  • Bulk export for population and analytics loads
  • Per-hospital base URLs from MEDITECH's endpoint list
Output: a resource and scope list tied to each screen and job in your product.
HL7 v2 interfaces

Where events flow in real time

Interfaces are licensed per hospital with a one-time implementation fee and monthly maintenance. MEDITECH says it does not charge per interface transaction. The hospital's interface team schedules the build.

  • ADT, results, scheduling and orders outbound
  • Inbound results and documents where the hospital licenses them
  • Mirth Connect for mapping, monitoring and replay
Output: an interface list per hospital, with the license each one needs and who owns it.

What MEDITECH enforces, and how we design for it

Registered by MEDITECH
Vendors do not self-register apps. MEDITECH registers each client on behalf of the hospital, so every go-live needs a hospital sponsor.
429 per instance
Quotas apply per hospital REST instance, TEST and LIVE separately, and return 429 with Retry-After. MEDITECH publishes no fixed numbers, so we throttle and back off per hospital.
Hospital sign-in
Clinician login runs through the hospital's identity provider, so we test launch flows against each hospital's IdP, not just Greenfield.
Platform generation
Expanse, 6.x, Client/Server and MAGIC hospitals expose different capabilities. We confirm the platform and version before scoping.
Licensed interfaces
Each HL7 v2 interface carries a one-time and a monthly fee to the hospital, so the interface list is agreed before the build.

From Greenfield to go-live

How an engagement runs.

Hospital sponsorship and interface scheduling decide the calendar more than code does, so we start them on day one.

01

Start in Greenfield Workspace

We register for Greenfield with you: the EULA, a Google ID for sign-in and a redirect URI for the OAuth client. We build against its synthetic patients first.

Working FHIR calls and launch flows in the sandbox.
02

Line up the hospital

Your hospital customer asks MEDITECH to register the app and, for feeds, licenses the interfaces. We prepare the scope, URLs and interface list with you.

A registration request and interface list per hospital.
03

Build against the hospital TEST instance

We connect to the hospital's TEST environment, check its platform version, identity provider and rate limits, and build the Mirth channels.

Tested workflows and a version matrix per hospital.
04

Go live and monitor

We move to LIVE with the hospital's interface team, then monitor API errors, 429s and interface queues with alerting and replay.

A repeatable go-live runbook and support handover.

Evidence

The engineering we bring to MEDITECH.

The engineering behind our MEDITECH delivery, with public code and test results you can inspect.

Multi-EHR SMART on FHIR app

One app run against the Epic and Oracle Health developer sandboxes in a single session, with the launch, PKCE and token handling a MEDITECH SMART app needs.

Mirth Connect interfaces

Our team has built 350+ interfaces on Mirth Connect, the engine we use for the HL7 v2 side of a MEDITECH integration.

Open-source headless EHR

Passes 47 of 47 ONC (g)(10) SMART App Launch tests (11 Jun 2026), the same certification program MEDITECH's APIs are tested under.

Headless EHR on GitHub ↗

Before you commit

MEDITECH integration questions, answered.

Does MEDITECH have an API?

Yes. MEDITECH Expanse has certified FHIR R4 APIs on US Core 6.1.0 with SMART App Launch and Bulk Data, documented on MEDITECH's certified API page, and developers test them in Greenfield Workspace. Older MEDITECH platforms have certified API versions too, and every generation supports HL7 v2 interfaces.

What is MEDITECH Greenfield Workspace?

Greenfield Workspace is MEDITECH's developer sandbox for testing integrations against a real MEDITECH EHR. You sign the Greenfield EULA, sign in with a Google ID and receive an OAuth client, then test with synthetic patients.

Can we register our app with MEDITECH ourselves?

No. MEDITECH registers client applications on behalf of the healthcare organization, and vendors do not self-register. Your hospital customer requests the registration, and we prepare the details with you.

Does MEDITECH charge for API access?

MEDITECH publishes no separate fee to app developers for its certified FHIR APIs. HL7 v2 interfaces are licensed to the hospital with a one-time implementation fee and monthly maintenance, and MEDITECH says it does not charge per transaction.

Do we need to join the MEDITECH Alliance?

No. The MEDITECH Alliance is MEDITECH's partner program for solutions already integrated with MEDITECH customers, with Innovator, Accelerator, Collaborator and services tiers. Many products integrate through Greenfield and hospital sponsorship first and apply later.

Can we integrate with MAGIC or Client/Server hospitals?

Yes, mostly through HL7 v2 interfaces, plus the certified API versions MEDITECH lists for MAGIC and Client/Server 5.67. We confirm what each hospital's platform supports before a workflow goes into scope.

What are MEDITECH's API rate limits?

MEDITECH enforces quotas per hospital instance, TEST and LIVE separately, and returns HTTP 429 with a Retry-After header, but publishes no fixed numbers. We queue requests per hospital and use bulk export for large loads.

Do we still need an integration if the hospital is on Traverse Exchange?

Usually, yes. Traverse Exchange is MEDITECH's FHIR-based exchange network with TEFCA access through Health Gorilla's QHIN. It helps retrieve records for care, but it does not put your product in the clinician's workflow or feed your product in real time.

What affects cost and timing?

The number of workflows, FHIR versus HL7 v2, the hospital's platform generation, how quickly the hospital sponsors registration and licenses interfaces, and how many hospitals you connect. Hospital interface fees are separate from our engineering fees.

Define the next step

What does your product need to do inside the hospital?

Tell us about your product and the hospitals you sell to. We will come back with the APIs, interfaces and hospital steps your workflow needs.

  • The target hospitals and their MEDITECH platform, if known
  • Any Greenfield access, interface or hospital sponsor you already have
  • Your workflow and delivery priorities

Please don’t include patient data, credentials or sensitive records.

Please exclude patient data and credentials. We use these details to respond to your enquiry. Privacy policy

Thank you. Your enquiry has been received. Our team will review your requirements.

MEDITECH and Expanse are trademarks of Medical Information Technology, Inc. Other product names are trademarks of their respective owners.