Greenfield Workspace build
ProposedA first build against synthetic patients in Greenfield, from MEDITECH's published documents.
Where it stops: We would prove your calls there first. Nothing public exists yet.
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 integrationFor 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
- Founded in 2020
- Rated 4.7 on Clutch (12 reviews, November 2026)
- ISO 27001:2022 certified
- HIPAA safeguards built in; 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
Evidence, by status
What we can show on MEDITECH today
We have no public MEDITECH recording yet. So here is what is a plan and what depends on a hospital, with no gloss.
HL7 v2 with Mirth Connect
ProposedOur team has built 350+ interfaces on Mirth Connect, across vendors.
Where it stops: That count is not specific to MEDITECH. The hospital licenses each interface.
Patient, provider and backend FHIR at a hospital
Access-dependentMEDITECH registers the app on the hospital's behalf.
Where it stops: No hospital sponsor, no test or live connection.
Live at a hospital
Access-dependentNeeds the hospital's vetting, MEDITECH onboarding and the hospital's interface team.
Where it stops: Ask what can be shared under NDA.
The two routes
A hospital sponsors every MEDITECH go-live
Developers cannot self-register for a live hospital. These flows show who has to act at each step.
From Greenfield to a hospital's LIVE instance
The hospital starts the onboarding, and the order matters.
- 1. Your companyBuilds in Greenfield Workspace
EULA, a Google ID for sign-in and a redirect URI, with synthetic patients.
- 2. The hospitalVets and approves your app
That review is the hospital's own process.
If it fails: Without a sponsor, Greenfield is as far as the work goes.
- 3. The hospitalRaises an NMI task, category ON-BOARD
This is the route MEDITECH describes for hospitals.
- 4. MEDITECHHelps test, then onboards to TEST or LIVE
MEDITECH registers the client on the hospital's behalf.
- 5. Your companyChecks version and identity at TEST
Platform version, identity provider and rate limits differ per hospital.
If it fails: A 429 carries Retry-After, and MEDITECH publishes no fixed quota, so back-off is per hospital.
- 6. The hospitalMoves to LIVE with its interface team
The hospital owns the window.
MEDITECH Patient Access API FAQ, read October 31, 2026. API terms and Greenfield pages as read September 26, 2026.
Real-time events: which route carries what
FHIR for reads, and licensed interfaces for real-time feeds. Most hospital products need both.
- 1. MEDITECH ExpanseSends ADT, results or scheduling outbound
Each interface is licensed per hospital, with a one-time fee and monthly maintenance.
- 2. Interface engineReceives, stores and acknowledges
Mirth Connect handles mapping, monitoring and replay.
If it fails: When the engine is down, what can be resent depends on the hospital's interface settings.
- 3. Your productFetches detail with certified FHIR
The event says what changed, and the read gets the record.
- 4. Your productSpots drift between the two
A scheduled compare catches events that never arrived.
MEDITECH HL7 outbound list and August 2024 cost disclosure as read September 26, 2026. License terms vary, so confirm them with the hospital.
Failure modes
What fails on MEDITECH, and the limit of each fix
Most of these come from the fact that each hospital runs its own instance.
A hospital's platform version lacks your feature
- How it gets noticed
- A version check at TEST
- What we do
- A version matrix per hospital, with features switched by it.
- The limit
- Upgrades are the hospital's decision.
Rate limits differ between TEST and LIVE
- How it gets noticed
- 429s with Retry-After, tracked per instance
- What we do
- Back-off per instance, and a separate load check in LIVE's first days.
- The limit
- No fixed quotas are published, so a TEST run cannot predict LIVE exactly.
An interface was licensed for one direction only
- How it gets noticed
- An interface list checked with the hospital in scoping
- What we do
- Each feed names its license, direction and owner.
- The limit
- The purchase is the hospital's decision and timing.
Access is ended
- How it gets noticed
- Authentication failures, alerted per hospital
- What we do
- A written fallback and a data export plan for your product.
- The limit
- MEDITECH's terms let it or the hospital end access at any time. We cannot prevent that.
Decision makers
For the person signing off a MEDITECH project
This is a hospital-led path. Decide with that in mind.
Main risks
No sponsor, or a sponsor on an older platform. Confirm the hospital's version and its interest before you spend on a build.
PHI
Greenfield uses synthetic patients. Hospital access follows a BAA and that hospital's vetting.
Code and agreements
Once paid, you own the custom code, mappings and all of your data. We keep our reusable tools and open-source parts. The hospital holds its interface licenses and its approval.
Team
A technical lead, a Mirth developer where feeds apply, and your hospital contact. Meet the lead before you sign.
What you receive
Custom source code, a per-hospital interface and version list, channels, test evidence, runbooks and a handover.
Your security review
ISO 27001:2022 certified, and we sign BAAs. Ask for the certificate and scope.
How to judge a MEDITECH vendor
- Ask how they get an app into a hospital's TEST instance.
- Ask who raises the NMI task, and when.
- Ask what they will do if the hospital has no interface budget.
- Ask to see any MEDITECH work, and in which environment. We will answer the same question.
Work and sources you can inspect
MEDITECH integration: make the access decision before the build
A patient-facing FHIR connection, a hospital interface and a legacy data feed need different plans. Use the documented Greenfield path and our implementation guides to define the first workflow.
Vendor documentation
MEDITECH describes its Greenfield Workspace and developer access. Use the documented capability for the intended workflow, then confirm customer-specific access.
Review Greenfield WorkspaceImplementation guide
Our MEDITECH Expanse guide brings the API and interface decisions together for an engineering team.
Read the MEDITECH guideView the integration architecture
These are documented integration paths to assess. Greenfield patient access does not by itself establish clinician launch, write operations or approval at a customer hospital.
Discuss this workflowThe problem
Sound Familiar?
What health tech teams tell us when they start selling to MEDITECH hospitals.
We cannot register our own app
MEDITECH registers apps on the hospital's behalf, so nothing goes live without a hospital sponsor.
Every hospital runs a different platform
Expanse, 6.x, Client/Server and MAGIC hospitals support different routes.
Real-time feeds wait for the interface team
HL7 v2 interfaces are licensed per hospital and scheduled by the hospital's interface team.
The limits are not published
Quotas apply per hospital instance, and a 429 can stop a bulk job that was not built to wait.
Use cases
What It Looks Like When It Works
Four use cases, each shown as the console your team works in. The hospitals and patients are fictional; the MEDITECH rules behind each screen are real.
Each Hospital Matched to Its Route
Today
The product is sold to a hospital whose platform does not support the planned API.
With the integration
Each hospital's platform, certified FHIR support, licensed interfaces and registration status are visible before scope is agreed.
What we build
- Platform check per hospital
- Certified API versions matched to each generation
- Registration requests prepared for the hospital
A SMART App From Greenfield to LIVE
Today
The app works in the sandbox and fails at the hospital's sign-in.
With the integration
The app is proven in Greenfield Workspace, then in each hospital's TEST instance with the hospital's identity provider, before the LIVE go-live window.
What we build
- Greenfield build on synthetic patients
- TEST launch with the hospital's identity provider
- A go-live runbook per hospital
Real-Time Feeds You Can Watch
Today
An ADT feed slows down and nobody notices until data is missing.
With the integration
Each HL7 v2 feed through Mirth Connect shows its last message and queue depth, and a slow feed raises an alert.
What we build
- Mirth Connect channels per licensed interface
- Acknowledgements, alerting and replay
- Feed monitoring shared with the hospital team
Bulk Export That Waits Instead of Failing
Today
A population export hits a quota and the job fails overnight.
With the integration
Bulk exports run per hospital and instance, and a 429 with Retry-After pauses the job instead of failing it.
What we build
- Bulk Data exports for registries and quality work
- Retry-After handling per instance
- Progress and state per hospital
First call
Questions We Will Ask You on the First Call
The answers decide the route for each hospital and the order of work.
Which hospitals are you selling to, and which platform does each run?
Expanse, 6.x, Client/Server and MAGIC support different routes.
Which hospital will sponsor the first registration?
MEDITECH registers apps for the hospital, so a sponsor is needed to go live.
Do you need real-time events or scheduled reads?
Real-time feeds usually mean licensed HL7 v2 interfaces.
Does your product open inside Expanse?
SMART launch testing starts in Greenfield and moves to the hospital's TEST instance.
Do you need population data?
Bulk export runs per hospital instance within its quotas.
Which identity provider does each hospital use?
Sign-in and MFA run through the hospital's provider, such as Entra ID or Okta.
Who on the hospital side schedules interface work?
The interface team's calendar often sets the go-live date.
Are any hospitals moving to Expanse?
Migrations change which route to build first.
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.
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.
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.
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.
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.
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
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
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
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.
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.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.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.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
Passed all 47 ONC (g)(10) SMART App Launch Standalone Patient App tests (October 27, 2026), the same certification program MEDITECH's APIs are tested under.
Headless EHR on GitHub ↗Before you commit
MEDITECH Integration Questions, Answered
What are MEDITECH's interoperability solutions?
MEDITECH offers four routes. Traverse Exchange is its national data exchange network and its on-ramp to TEFCA. Expanse has certified FHIR R4 APIs with SMART App Launch and Bulk Data, tested in Greenfield Workspace. Every MEDITECH generation sends and receives HL7 v2 interfaces. The MEDITECH Alliance lists partner products. Exchange networks retrieve records; putting your product in the clinician's workflow still needs the APIs or interfaces, which is the work we do.
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.
Thank you. Your inquiry 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.
Vendor sources behind these diagrams
- MEDITECH Patient Access API FAQ, read October 31, 2026
- MEDITECH REST API resources, read October 31, 2026
- Greenfield Workspace, read September 26, 2026