NEMT dispatch problems rarely start in the dispatch office. A late pickup is usually the end of a chain that began with a vague trip request, a stale address, a vehicle mismatch or a broker file that arrived after the routes were built.
This guide is for non-emergency medical transportation providers, brokers and the teams that build their software. It walks through the failure points dispatchers see every day, traces each to its cause, explains how dispatch issues turn into compliance findings under federal broker rules, and lists the metrics that show trouble early.
What are the most common NEMT dispatch problems?
Dispatch software that keeps up?
Agnotic builds NEMT dispatch systems with mode-aware assignment, offline driver apps and broker integrations that stay in sync.
The most common NEMT dispatch problems are late pickups, the wrong vehicle type arriving, return rides left waiting, disputed no-shows and trips lost between broker and provider systems. Most trace back to missing or stale trip data and manual handoffs, so the fixes are data rules and integrations more than extra dispatchers.
Dispatchers absorb these problems by phone, which hides their causes. A good dispatch system makes each failure visible as data: which trips were late, by how much, for what reason, and which upstream step produced the bad input.
The sections below take each failure in turn, starting with the one riders and clinics notice first.
Why do NEMT pickups run late?
NEMT pickups run late mainly because schedules are built on optimistic travel and loading times, and because one delay early in a route cascades through every later trip. Traffic is a smaller cause than planning assumptions.
- Fixed service times: The schedule assumes the same loading time for an ambulatory rider and a wheelchair rider who needs securement.
- No buffer for appointments: Pickups are timed to arrive exactly at appointment time, with no allowance for check-in.
- Overloaded routes: Shared rides are added until the vehicle is full, without checking whether every rider can still arrive on time.
- Late manifests: Trips arrive from the broker after routes are built, and dispatchers squeeze them in by hand.
- Stale addresses: The pickup address on file is not where the rider is today, and the driver spends time finding them.
The fixes sit in the scheduling rules. Use measured loading times per mobility type, schedule arrival a set number of minutes before the appointment, cap ride-sharing by on-time risk rather than seats, and confirm addresses during the reminder call the day before.
Feed actual times back into the rules. Pickup and drop-off events from the driver app show real loading times by vehicle, rider type and location, so the schedule stops repeating yesterday's assumptions.
Why does the wrong vehicle show up?
The wrong vehicle shows up when the trip record does not carry accurate mobility needs, or when the dispatcher swaps a vehicle without the system checking compatibility. The rider is then refused or carried unsafely, and the trip has to be redone.
Mode rules are also billing rules. Colorado's NEMT billing manual, for example, covers wheelchair van service only when the member's medical professional indicates in writing that the member is wheelchair-confined and unable to use less costly modes, and wheelchair vans otherwise bill at the ambulatory rate.
- Mobility as structured data: Ambulatory, wheelchair, power chair, stretcher, attendant needed, and any weight or size limits, never only a free-text note.
- Documentation status: Whether the supporting statement for the mode is on file and still current.
- Vehicle capabilities: Lift, ramp, securement positions and stretcher capacity recorded per vehicle.
- Hard checks: The system blocks assigning a trip to a vehicle that cannot carry the rider, and logs any override with a reason.
How do will-call returns and last-minute changes break the day?
Will-call returns and last-minute changes break the day because they arrive after routes are set and land on drivers already committed elsewhere. A rider finished early at the clinic, or a procedure that ran long, has to be fitted into a schedule that had no space reserved.
- Reserved capacity: Hold some vehicle time in each region for will-calls, sized from past will-call volume by time of day.
- Clinic status feeds: Where a facility can send an appointment completion or discharge event, use it to trigger the return instead of waiting for a phone call.
- Change as update: Treat a changed time or address as an update to the existing trip, preserving its history, not a new trip that leaves a duplicate behind.
- Rider notifications: Send updated arrival times automatically when a trip is reassigned or delayed.
Duplicates are the quiet cost of poor change handling. A trip cancelled in one system and recreated in another can be run twice, billed twice or missed entirely, and each outcome causes a different problem later.
Why are NEMT no-shows so hard to prove?
NEMT no-shows are hard to prove because the evidence is usually a driver's word against a rider's, with no reliable time or location record. When the broker or plan disputes a no-show, the provider often cannot show that the driver was at the right place at the right time.
- Arrival event: Captured in the driver app with GPS location and device time when the driver reaches the pickup point.
- Wait timer: The required wait period tracked in the app, with attempted calls to the rider logged.
- Dispatcher confirmation: A dispatcher contact attempt recorded before the no-show is finalized.
- Offline capture: Events stored on the device with their original time when signal drops, then synced later.
The same records protect riders. When a rider reports that no vehicle came, the trip history shows whether the driver arrived, where, and for how long, which settles the complaint fairly in either direction.
What goes wrong between broker and provider systems?
Between broker and provider systems, trips go missing, arrive twice, or carry different details on each side. The usual cause is batch files exchanged on a schedule, with no shared trip identifier and no acknowledgment that each trip was received.
- Shared IDs: Keep the broker's trip ID on every provider record, and reject updates that cannot be matched.
- Acknowledgments: Confirm receipt of each trip and each change, so the broker knows what the provider actually has.
- Near real-time feeds: Replace once-a-day files with an API or frequent deltas where the broker supports it.
- Reconciliation: Compare the broker's assigned trips with the provider's completed and cancelled trips every day, and work the differences.
Providers that serve several brokers face this problem once per broker, each with its own file layout and change rules. A thin adapter per broker, mapping into one internal trip model, keeps dispatch working from a single board instead of one screen per broker.
What happens when drivers or credentials run short?
When drivers or credentials run short, dispatchers assign trips to whoever is available, and some of those assignments are to drivers whose license, training or background check has lapsed. The trip runs, but it may not be billable and it becomes an audit finding.
- Credential dates: Store license, training, vehicle inspection and screening dates per driver and vehicle, with alerts well before expiry.
- Assignment gate: Block trips to any driver or vehicle with an expired item, so the check does not rely on the dispatcher remembering.
- Capacity forecast: Compare next week's booked trips by mode and region with available credentialed drivers, so gaps show up before the day.
Shortages also push dispatchers toward overloaded routes, which brings back the late-pickup problem. Showing forecast gaps early gives operations time to recruit, rebalance or ask the broker to move trips.
How do dispatch problems become compliance problems?
Dispatch problems become compliance problems because federal Medicaid rules make timeliness and the choice of transport part of the broker's obligations. Late trips and poor mode choices show up in state audits, not just in complaints.
Under 42 CFR 440.170(a)(4)(i), an NEMT broker must have oversight procedures to monitor beneficiary access and complaints and to ensure that transportation is timely and that transport personnel are licensed, qualified, competent and courteous, and is subject to regular state auditing of quality and timeliness. Under 440.170(a)(4)(ii)(D), a broker may not withhold necessary transportation or provide a mode that is not the most appropriate and cost-effective for the rider for financial gain or any other purpose.
For software, that means on-time data, complaint records and assignment reasons are audit evidence. A dispatch system that records why each trip got each vehicle, and when it actually arrived, lets a broker or provider answer an audit from data instead of reconstructing it.
Which dispatch metrics show problems early?
The dispatch metrics that show problems early are on-time pickup and drop-off rates against the schedule, late trips by cause, will-call wait times, mode mismatch refusals and unmatched broker trips. Track them by region, provider and hour, not just as a daily average.
- On-time rates: Pickups and drop-offs within the program's window, split by outbound and return legs.
- Late reasons: A short coded list chosen by dispatch, such as prior trip late, rider not ready or address error.
- Will-call wait: Minutes from the rider's call to pickup for return trips.
- Refusals and redos: Trips where the vehicle could not carry the rider.
- Disputed no-shows: Share of no-shows challenged, and the share upheld with event evidence.
- Unmatched trips: Broker trips with no matching provider record at day's end.
Review these numbers daily with dispatch leads and weekly with the broker. A shared view of the same figures ends most arguments about whose system caused a missed trip.
How Agnotic can help
Fixing dispatch means fixing the data that feeds it. Agnotic Technologies builds NEMT dispatch software for providers and brokers: mode-aware assignment with hard compatibility checks, scheduling rules tuned from real trip times, offline-first driver apps that capture proof of service, and broker integrations with shared IDs and daily reconciliation.
Agnotic also builds the reporting layer that turns trip events into on-time, complaint and audit reports, so operations teams and auditors work from the same records.
Stop firefighting dispatch
Explore custom NEMT dispatch software, or browse more guides for healthcare operators.
Related reading on Agnotic
See how NEMT platforms are built, why NEMT matters to care, where NEMT technology is heading and how AI helps providers.
