Building NEMT platforms means building software for four parties at once: the Medicaid member who needs a ride, the broker that arranges it, the transportation provider that runs it, and the state agency that pays for and audits it. Each party sees a different slice of the same trip, and the platform has to keep those slices consistent.
This guide is for founders, brokers, transportation operators and health plans planning a non-emergency medical transportation build. It covers how the parties connect, the trip data model, which modules to build first, how billing and mileage work, how to keep broker and provider roles apart, and why the driver app is harder than it looks.
What does building an NEMT platform involve?
Planning an NEMT build?
Agnotic builds custom NEMT dispatch, broker and driver software for transportation operators, brokers and health plans.
Building an NEMT platform involves software for trip intake, eligibility checks, scheduling and dispatch, a driver app, billing and state reporting, all sharing one trip record. The platform connects Medicaid members, brokers, transportation providers and the state agency, so most of the effort goes into data exchange and audit trails, not screens.
A ride-hailing app is a useful comparison only up to a point. NEMT trips are booked days ahead as often as on demand, they must match a covered medical appointment, the vehicle type depends on documented mobility needs, and every completed trip turns into a claim that a state or plan may audit years later.
That changes the order of work. A team that starts with the rider app and leaves billing and reporting for later usually ends up rebuilding the trip record once the first audit request arrives.
Who does an NEMT platform serve?
An NEMT platform serves four parties with different jobs, and most products serve one or two of them directly while exchanging data with the rest. Decide early which role your organization plays, because that decides which records you own.
- Member: Requests rides, often by phone, sometimes through an app or a clinic, and needs confirmations, reminders and a way to complain.
- Broker: Takes requests, confirms eligibility and medical need, assigns trips to a provider network, handles complaints and reports to the state or plan.
- Transportation provider: Runs vehicles and drivers, accepts assigned trips, records pickup and drop-off, and bills the broker or payer.
- Medicaid agency or managed care plan: Sets rules and rates, pays for trips, audits timeliness and quality, and receives reports.
Federal rules shape what the platform must carry. Under 42 CFR 440.170(a)(4), a state's NEMT brokerage program covers wheelchair vans, taxis, stretcher cars, bus passes and tickets, secured transportation with occupant protection, and other covered transport. Each of those modes needs its own fields, rates and proof of service in the trip record.
How do the parties connect through an NEMT platform?
The parties connect through the trip record, which the broker usually holds at the center. The member's request comes in, the broker confirms eligibility and assigns a provider, the provider's driver completes the trip, and the completed trip flows back to the broker for billing and on to the agency for payment and reporting.
- Member to broker: Ride requests by call center, app, web or clinic referral, with appointment time, address and mobility needs.
- Broker to agency or plan: Eligibility checks before booking, and later encounter data, claims and performance reports.
- Broker to provider: Trip assignments, often as a daily file or API feed, with changes and cancellations sent as updates, not new trips.
- Provider to driver: Manifests and routes in the driver app, with pickup and drop-off events, odometer or GPS mileage and signatures sent back.
- Provider to broker: Trip status in near real time, completed-trip data for payment and incident reports.
- Agency to everyone: Rate tables, covered modes, rules and audit requests.
Every arrow in that flow is an integration someone has to build and test. List them with the file format, frequency and owner of each before estimating the project, because exchange work is where NEMT builds overrun.
What belongs in the core trip data model?
The core trip data model should hold one record per leg of travel, linked to the member, the appointment, the eligibility check, the assigned provider and driver, the events of the trip and the claim. Design it before any screen, because every module reads and writes it.
- Member and eligibility: Medicaid ID, plan, eligibility result with the date checked, and any standing order for recurring trips.
- Appointment link: Destination facility, appointment time, the reason category and who booked it.
- Mobility and mode: Ambulatory, wheelchair, stretcher or secured transport, with the documentation that supports it.
- Assignment: Provider, driver, vehicle, assigned time and every reassignment with a reason.
- Events: Scheduled and actual pickup and drop-off times, locations, no-shows, cancellations and who caused them.
- Billing: Procedure codes, units, mileage, modifiers, claim status and remittance.
- Audit: Who changed what and when, kept for the retention period the state contract requires.
Model a round trip as two legs. Return rides fail or change independently of outbound rides, and billing in many programs counts each one-way trip separately.
Keep changes as history, not overwrites. When a pickup time moves or a trip is reassigned, the earlier values are what an auditor will ask about.
Which modules should an NEMT build deliver first?
An NEMT build should deliver trip intake, eligibility and the trip record first, then scheduling and dispatch, then the driver app, then billing and reporting. Each step produces data the next one needs.
- 1. Intake and trip record: Call-center screens and APIs that create trips with all required fields and validation.
- 2. Eligibility: Real-time checks against the state or plan, with results stored on the trip.
- 3. Scheduling and dispatch: Assignment rules by mode, region and provider capacity, with a dispatcher board for exceptions.
- 4. Driver app: Manifests, navigation handoff, event capture, signatures and offline support.
- 5. Billing: Claim or invoice generation from completed trips, remittance posting and denial work queues.
- 6. Reporting and complaints: Timeliness, no-show and complaint reports from the same trip data, plus a complaint log linked to trips.
- 7. Member and facility self-service: Apps and portals once the core is stable, so new channels feed a proven back end.
Run the first releases against real trip files from at least one broker or plan. Synthetic data rarely includes the odd addresses, duplicate members, mid-day cancellations and mode changes that live programs produce every day.
Scheduling deserves extra care. Shared rides, wheelchair capacity per vehicle, driver breaks and pickup windows around appointment times all constrain assignment, so start with clear rules a dispatcher can override, and add optimization only once the rules and the data behind them are trusted.
How should billing and mileage work?
Billing should be generated from completed trip events, using each program's procedure codes, units and mileage rules, with no manual re-entry. The rules vary by state, so keep them in configuration tables rather than code.
Colorado's NEMT billing manual shows the level of detail involved. Wheelchair van trips bill A0130 per one-way trip with S0209 per mile, mileage is paid on the shortest trip length as determined by an internet-based map, trip planner or GPS, and a wheelchair van is covered only when the member's medical professional states in writing that the member is wheelchair-confined.
- Rate tables: Codes, units and modifiers by state, plan, mode and effective date.
- Mileage source: Store both the driven mileage and the routed shortest mileage, and bill the one the program requires.
- Documentation checks: Block billing for a mode whose supporting documentation is missing or expired.
- Remittance matching: Match each 835 payment line back to its trip leg, not just to the claim.
How do you keep broker and provider roles separate?
You keep broker and provider roles separate by enforcing referral rules in the assignment logic and recording why each trip went to each provider. Federal rules make this a design requirement, not a policy note.
Under 42 CFR 440.170(a)(4)(ii), a brokerage contract generally prohibits the broker from providing transportation itself or referring trips to a provider with which it, or an immediate family member, has a financial relationship. Narrow exceptions apply, such as rural areas with no other qualified provider, and they require documentation.
- Ownership registry: Record financial relationships between the broker and providers as data the assignment engine can read.
- Assignment reasons: Store why each trip went to each provider, including the rule and any exception used.
- Exception evidence: Attach the documentation for each rural or specialized-transport exception to the trips that rely on it.
Why is the driver app harder than it looks?
The driver app is harder than it looks because it must record legally significant events from moving vehicles with patchy signal, for drivers of varied technical comfort. Its timestamps and locations become the proof of service behind every claim.
Build it offline-first: store events on the device with their own timestamps and sync when signal returns. Capture pickup, drop-off, no-show and signature events with location, and never let a driver edit a timestamp without a recorded reason. Keep the screen flow short enough to use at the curb, with large controls and clear state for the next trip.
Plan for device management too. Lost phones, shared vehicles and drivers who work for several providers all affect how sign-in, data storage on the device and remote wipe should work.
How Agnotic can help
An NEMT platform succeeds when every party trusts the same trip record. Agnotic Technologies builds NEMT software for brokers, transportation providers and health plans: trip intake and eligibility, rule-based dispatch, offline-first driver apps, state-specific billing and the reports agencies ask for.
For teams already running a packaged product, Agnotic builds the integrations around it, such as broker trip feeds, eligibility connections, mileage routing and remittance matching, so the platform fits the programs it serves.
Design your NEMT platform
Explore custom NEMT dispatch software, or browse more guides for healthcare builders.
Related reading on Agnotic
Read about NEMT rules and access, dispatch failure points, NEMT billing software and AI in NEMT.
