NEMT EHR Integration: How Transport Data Moves Between Your EHR and Dispatch

A discharge nurse finishes a patient’s paperwork, opens a second browser tab, logs into a broker portal, and re-types the patient’s name, address, appointment time, and wheelchair requirement into a form. The EHR already holds every one of those fields. The transport system just can’t see them. So a person becomes the integration layer, and the patient waits while she keys it in.

That gap is the whole problem. The EHR knows the patient is ready to move. The dispatch system doesn’t, because nothing connects the two. Most of what is slow, error-prone, and expensive about non-emergency medical transportation traces back to that missing connection.

I run engineering at Mindbowser, and most of what my team does on the healthcare side is build the connections between clinical systems and the platforms that act on them. This is a guide to closing the transport version of that gap: how data actually moves between an EHR and a dispatch platform, which standards carry it, how Epic, Cerner, and athenahealth each expose it, why the rules now push in this direction, and why off-the-shelf NEMT software cannot do this no matter what the sales deck says.

What EHR-connected NEMT actually looks like

Most NEMT today runs on manual coordination. A care coordinator reads a discharge order, calls a broker or opens a portal, and books the ride by hand. The ride happens. Hours later, maybe, someone updates a spreadsheet. Nothing flows back to the chart.

EHR-connected NEMT replaces the human relay with a data path. The discharge event in the EHR triggers the ride request on its own. The dispatch platform receives structured patient context, not a typed address. Trip status flows back into the patient record so the care team can see where the ride is. The coordinator stops being a copy-paste machine and starts handling the exceptions that actually need judgment.

The data that should move on its own is not exotic:

• Patient demographics and contact details
• Pickup and drop-off locations
• Appointment date, time, and provider
• Mobility and accommodation needs (ambulatory, wheelchair, stretcher, bariatric)
• Insurance, eligibility, and prior-authorization status

Every field already lives in the EHR. The work is not collecting it. The work is connecting two systems that were never built to talk to each other, across a healthcare data standard that each EHR implements its own way. That makes this an integration problem, not a software-purchase problem, and the difference decides everything about how you solve it. This is also where the broader idea of healthcare interoperability stops being abstract: NEMT is one of the clearest cases of two systems that should share data and don’t.

Discharge-triggered ride requests via FHIR

The cleanest version of EHR-connected transport fires the ride request off a clinical event. The patient’s status changes in the EHR, and that change becomes the trigger.

The trigger is usually an ADT message. ADT stands for admit, discharge, transfer, and it is the HL7 v2 event stream hospitals have run for decades. A discharge or a “ready for transport” status update generates an event. That event is what tells the transport layer a ride is needed, the moment it is needed, without anyone watching a queue.

From there, modern integrations carry the detail in FHIR. Using the HL7 FHIR R4 standard, the resources that matter for transport are a short list:

• Patient: who is moving, and their demographics
• Encounter: the visit context, including discharge disposition
• ServiceRequest: the actual order for transport, the resource that says this patient needs a ride, here, then, with these requirements
• Appointment: the destination visit the ride is serving
• Coverage: the insurance and benefit context behind eligibility and authorization

The flow reads in one line: a discharge event creates a ServiceRequest, the dispatch platform picks it up, a driver is assigned, and the trip status writes back to the EHR. ServiceRequest is the spine. It is the FHIR resource designed to represent an order for a service, and a transport order fits it exactly, with the requested time, location, and patient requirements all structured rather than buried in free text. Building this well is the same discipline as any custom NEMT software development effort that has to hold up in production, not a one-off script.

What “real-time” actually requires

But real-time is where a lot of integrations quietly fail. The difference is subscription versus polling. A polling integration asks the EHR “anything new?” every few minutes and waits for the answer. It is simple to build and always a step behind. For a discharge that needs a ride now, a few minutes behind is a patient sitting in a wheelchair by the door.

Real-time means the EHR pushes the event to you the instant it happens, through an event subscription rather than a scheduled check. FHIR supports this directly through its Subscription mechanism, and the older HL7 v2 interface world supports it through live interface feeds. Either way, the design rule is the same: the clinical system tells the transport system when something changed, not the other way around. If a vendor describes their “EHR integration” as a nightly file or a periodic pull, that is not real-time, and it will not support discharge-triggered dispatch.

Why FHIR-based integration is now a payer mandate

For years, EHR integration was a nice-to-have that strong health systems did and everyone else deferred. But the rules have caught up to the workflow.

The CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F, finalized in 2024, requires impacted payers to stand up HL7 FHIR APIs. The impacted payers are Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the federally facilitated exchanges, per the CMS-0057-F fact sheet. Those are the same plans that pay for and manage most NEMT. The rule names four APIs, Patient Access, Provider Access, Payer-to-Payer, and a Prior Authorization API, with operational provisions generally beginning January 1, 2026, and the API build requirements due by January 1, 2027.

The Prior Authorization API is the one to notice. Authorization confirmed too late is one of the most expensive failures in NEMT: the trip runs, then it turns out it was not covered, and the revenue is gone. A FHIR-based prior-authorization exchange is the standardized plumbing that makes pre-trip authorization checkable instead of a phone call. The rule is turning a workflow gap into required infrastructure.

The certification side moves the same way. The ONC HTI-1 final rule, effective March 11, 2024, adopts USCDI version 3 as the certification baseline and requires certified health IT to support FHIR Release 4 with the US Core 6.1.0 implementation guide by January 1, 2026, per ONC’s HTI-1 summary. In plain terms, FHIR R4 and US Core are becoming the floor for certified EHRs, not an optional upgrade. If you are building transport integration today, you are building against a standard that the rules are actively pushing everyone toward, which is a far better position than betting on a proprietary connector.

How Epic, Cerner, and athenahealth handle transport differently

Here is the part the brochures skip. FHIR is a standard, but every EHR exposes it through a different door, with different access rules, different available resources, and different setup work. A connector that works against Epic does not drop into Cerner unchanged. This is the single biggest reason a generic, off-the-shelf “EHR-integrated” dispatch product cannot really exist.

1. Epic. Epic integrations run through Interconnect, with HL7 v2 interfaces historically handled through Bridges and modern API access governed through Epic’s developer program. ADT feeds are mature and reliable. FHIR access follows US Core and Epic’s own implementation, and getting to it means working through the health system’s Epic team, not a public sandbox you can self-serve. The access path is as much organizational as technical.
2. Cerner, now Oracle Health. Millennium is the platform, CareAware is the connectivity and device-integration fabric, and FHIR and HL7 v2 are both available depending on the site’s configuration and version. The resource availability and the auth model differ from Epic’s in ways that matter at build time, even though both speak FHIR R4 on paper.
3. athenahealth. athenahealth exposes a more REST-oriented, lighter-weight API surface. For some transport use cases that is simpler to work with. It is also a different integration model again, with its own endpoints and its own conventions.

The practical takeaway: same FHIR standard, very different access paths. The clinical meaning of a discharge is identical across all three. The engineering to receive it, parse it, and act on it is not. That gap is exactly where deep integration work lives, and exactly what a SaaS dispatch vendor selling one product to every customer cannot absorb for you. Epic, Cerner, and athenahealth are integration targets here, not competitors, which is why the work belongs with a team that does cross-EHR integration as its main job.

Watch: EHR Integration Explained, HL7 v2 vs FHIR vs SMART on FHIR (Epic + Cerner). A walk through how the same integration looks across standards and across the two biggest EHRs.

Trip status feeds: closing the loop back to the chart

A one-way integration is half an integration. Firing the ride request off a discharge event is the outbound half. The inbound half is sending trip status back into the patient record: driver assigned, driver en route, patient picked up, arrived at destination.

And that return feed is what turns transport from a black box into part of the care record. When the status lives in the chart, the care team can see that a discharged patient’s ride is twenty minutes out instead of phoning the broker to ask. It also gives billing and audit a clean, time-stamped trail of what actually happened on each trip, which matters more every year as payers and state programs tighten documentation requirements.

Mechanically, status can flow back as updates to the FHIR ServiceRequest or Task status, so the order’s state stays current in the EHR, or as HL7 v2 messages where a site’s interface engine expects them. Richer trip data, like arrival times or mileage captured for the record, can land in the chart as observation-style results where that fits the workflow. The right mechanism depends on the EHR and the receiving workflow. The principle does not change: if status does not write back, the care team is still working blind and someone is still picking up the phone. The same status feed is what lets AI-assisted NEMT dispatch act on real clinical timing instead of a static schedule.

What off-the-shelf dispatch software can’t do

There is good NEMT dispatch software on the market. RouteGenie, TripMaster, MediRoutes and others do real work for fleets that need scheduling, routing, and driver management. But none of that is the same as EHR integration, and it is worth being precise about why.

• No FHIR patient context. Off-the-shelf dispatch takes a typed address and a name. It does not consume an Encounter or a ServiceRequest. The clinical context that makes a ride safe and authorized, the discharge disposition, the mobility need, the coverage, never reaches it in structured form.
• No discharge trigger. Without a connection to ADT or FHIR events, someone still has to notice the patient is ready and start the ride. The automation stops at the fleet’s front door.
• No write-back to the chart. Status stays in the dispatch tool. The care team cannot see it without logging into a second system, which in practice means they do not see it.
• Authorization and eligibility live outside their world. Whether a trip is covered, and whether prior authorization was confirmed before the wheels moved, is a question the dispatch tool cannot answer because it never sees the coverage data.

This is the build-versus-buy fork, and it is not a question of which product is better. Or rather, it is not about better or worse software at all. It is a question of what the transport is connected to. For a standalone fleet that books its own trips, SaaS dispatch is often the right call. For transport that has to move with a health system’s clinical events, the value is in the integration layer, and that layer has to be built against the specific EHRs in play. A vendor selling the same connector to everyone is selling a connector to no one.

How Mindbowser approaches an NEMT EHR integration

We build the integration layer, not another dispatch product. That is the honest description of where we fit. A health system or a transport operator already has, or is choosing, a dispatch platform, and the problem is connecting it to the clinical systems that should drive it. FHIR and HL7 integration across Epic, Cerner, and athenahealth is core engineering work we do, and the NEMT use case is a direct application of it rather than a generic template.

What that looks like in practice:

• Event layer. Subscribe to the EHR’s discharge and transport-relevant events through ADT feeds or FHIR subscriptions, so ride requests fire on the clinical event instead of a coordinator’s attention.
• Translation and mapping. Map the EHR’s data into a clean ServiceRequest the dispatch platform can act on, including the fields that are easy to get wrong: mobility requirements, discharge disposition, and the coverage and authorization state behind the trip.
• Dispatch handoff. Deliver the structured request to the dispatch logic, whether that is a partner platform or a custom build, with the patient context intact.
• Write-back. Return trip status to the chart so the loop closes and the care team and the billing trail both stay current.
• Reliability discipline. Handle events idempotently so a duplicated discharge message does not create a duplicate ride, and design for the exceptions, the deviated trip, the canceled appointment, the failed eligibility check, because that is where real workflows live.

I want to be precise about proof here, because the category invites inflated claims. Mindbowser’s genuine differentiator is the FHIR and HL7 integration capability itself, demonstrated across EHR-integration work broadly. We are not going to attach a borrowed transport-time metric to it. When we ship a delivered NEMT integration with its own measured outcome, that number will go here. Until then, the capability is the claim, and it is a real one.

What operators are actually telling us

The demand for this is not theoretical. A New York non-emergency medical transport operator running Medicaid and Early Intervention trips came to us wanting to move off third-party billing software and own its platform. The pains they described map almost one to one onto the integration gaps above:

• Prior authorization confirmed too late, so trips run uncovered and the revenue is lost after the fact. This is the exact gap CMS-0057-F’s Prior Authorization API is meant to close.
• No clean exception handling when a trip deviates from plan.
• GPS and billing that don’t reconcile, which is where both fraud and honest leakage hide.
• Eligibility unverified at booking, only discovered later.
• Denials worked by hand, if at all, so revenue quietly leaks.

Every one of those is an integration and data problem before it is a transport problem. Authorization and eligibility are coverage data the dispatch tool never sees. Reconciliation needs trip data and billing data in the same place. This is what operators run into when they outgrow generic software, and it is the same gap from the discharge-nurse story, viewed from the billing side instead of the clinical side. The billing half of it is its own deep topic, covered in Medicaid NEMT billing challenges.

How to scope an NEMT EHR integration project

If you are weighing this, a few questions decide the shape of the work before any code gets written:

• Which EHR or EHRs? Epic, Cerner/Oracle Health, athenahealth, or a mix. Each one changes the access path and the timeline. A multi-EHR environment is a different project than a single-EHR one.
• What event access do you have? Can you reach ADT feeds, FHIR subscriptions, or both? This decides whether real-time, discharge-triggered dispatch is on the table or whether you start with something more batch-oriented.
• FHIR, HL7 v2, or both? Most real environments are both for a while. Knowing which carries which data shapes the design.
• Who owns the interface engine? The health system’s integration team is a stakeholder from day one, not a detail to sort out later. Their access and their timeline are part of yours.

And from there, the honest answer on phasing is to start narrow. One EHR, one direction, the discharge-to-request path working end to end and reconciling cleanly, before adding write-back, then additional EHRs, then the richer data. Teams that try to build the whole bidirectional, multi-EHR, fully reconciled platform in one pass are the teams that stall. The same discipline applies whether you are building an NEMT platform from scratch or extending one you already run.