NEMT Software: Fixing the Denials and Dead Miles Killing Your Margin

Why dispatch and billing software decide your margin

An NEMT operation lives or dies on two numbers: how many billable trips each vehicle completes per day, and what percentage of those trips get paid on the first claim submission. Everything else is noise. Run it on your own figures. Take 300 trips a day at your average ambulatory rate, then take the slice you write off to denials and no-shows you cannot document. For most operators at that size the annual number is six digits. That is two dispatchers and a van.

The tooling reality is grim. Most operators are running Tobi or RouteGenie or NEMT Cloud for scheduling, then exporting to a spreadsheet at 6pm because the broker portal wants a different file format than what the software produces. ModivCare wants trips confirmed in its own portal. MTM wants a different one. Access2Care has its own. So your dispatcher spends the last two hours of every shift re-keying trips between three broker portals and your scheduling tool, because none of them talk to each other, and the trip IDs do not match. Meanwhile your billing person is in a fourth system, usually Office Ally or a clearinghouse portal, building 837P claims by hand from a CSV your dispatch software spat out with the wrong modifier on wheelchair legs.

Here is the scene that repeats every Monday. A dialysis patient's standing order for Tuesday, Thursday, Saturday sits in your system as three recurring trips. The facility calls Friday at 4pm and moves her chair time from 6am to 11am, permanently. Your dispatcher updates this week. Nobody updates the recurring template. For the next six weeks the driver shows up at 6am to an empty house, marks a no-show, and you bill a no-show that the broker denies because the standing order on their side already reflected the 11am change. Six weeks of denials, a facility that now calls your competitor first, and a driver who burned 90 minutes a week on nothing. The software did exactly what it was told. That is the problem.

Problem: broker trip feeds arrive in three incompatible shapes and nobody reconciles them

ModivCare, MTM, Access2Care, Veyo, and the state Medicaid fee-for-service line each hand you trips differently. Some push a nightly file. Some expect you to pull from a portal. Some send trip changes by email to a shared inbox that your dispatcher checks between radio calls. A trip that gets cancelled on the broker side at 11pm is still on your board at 6am, and your driver runs a leg you will never be paid for.

Off-the-shelf tools do have broker integrations, and they work until they do not. The integration typically covers trip import and status push for the two or three biggest brokers, on the vendor's roadmap, on the vendor's timeline. When your state changes brokers mid-contract, which happens, you wait. When a broker changes its will-call rules, you wait. You are one of thousands of tenants, and your subscription does not move a roadmap.

A custom build treats every broker as a normalized adapter into one canonical trip record. Each adapter handles that broker's quirks: file drop, API poll, portal scrape, whatever is available. The canonical record carries broker trip ID, your internal leg ID, member ID, level of service, authorization number, and the reconciliation state. Then you run a reconciliation job every 15 minutes that diffs the broker's current picture against your board and surfaces exceptions to a queue: trip cancelled on their side but still assigned here, level of service downgraded from wheelchair to ambulatory, mileage mismatch on the return leg. Your dispatcher works a short exception list instead of eyeballing four portals. This one flow is usually where the build pays for itself, because every unreconciled trip is either an unpaid mile or a denial you will fight in 45 days.

Problem: routing that ignores what actually happens in an NEMT vehicle

Generic routing optimizes for distance and time windows. NEMT does not work that way. A wheelchair pickup at a private residence with three porch steps takes 14 minutes, not 4. A bariatric transfer needs two attendants and a specific vehicle. A dialysis return leg is a will-call, meaning the clinic calls when the patient is off the chair, which could be 40 minutes after the scheduled time. A patient with a documented aggression history needs a specific driver. A member with an oxygen requirement cannot ride with certain configurations.

Tobi and RouteGenie will let you tag vehicles and set service durations, and that is useful at 60 trips a day. At 300 trips a day across four counties, the tags stop carrying the constraints. Your best dispatcher, the one who has been there nine years, holds the real routing model in her head: she knows the Riverside dialysis center runs 25 minutes late on Tuesdays, that Mrs. Alvarez's building has a service elevator that is faster than the main lobby, that driver 14 should never be assigned to the memory care facility. None of that is in the software. When she takes vacation, your on-time performance drops and you find out from a broker scorecard rather than from your own dashboard.

The custom build encodes those constraints as data instead of folklore. Per-address load times learned from your own GPS and driver app timestamps, not estimated. Per-facility will-call lag distributions computed from your history, so the optimizer schedules the dialysis return against a realistic window instead of a fictional one. Per-member equipment, attendant, and driver-exclusion rules that the assignment engine treats as hard constraints. Then the optimizer runs continuously, not once at 5am, and proposes reassignments to the dispatcher as a suggestion with a reason attached: "move leg 4412 to unit 22, unit 9 is 18 minutes behind and will miss the 2:15 appointment." The dispatcher stays in control. The software carries the memory.

Problem: will-calls and no-shows are where the money leaks and nobody can prove anything

A no-show costs you a dry run and usually gets denied unless you can prove the driver was there, waited the contractually required time, and attempted contact. Most operators can prove none of this cleanly. The driver marks "no show" in an app, and 45 days later the broker denies it and you have nothing but that tap.

The off-the-shelf driver apps capture arrival timestamps and sometimes a signature. What they rarely produce is an evidence package that survives a broker audit. And they almost never enforce the specific wait rule in your specific contract, which might be 10 minutes for ModivCare and 15 for the state line.

A custom driver app enforces the rule per contract at the moment of truth. Geofenced arrival with GPS accuracy recorded, a wait timer the driver cannot short-circuit, forced call attempt logged through a Twilio number so you have a call record with duration, a timestamped photo of the residence door, and an automatic exception to dispatch at minute 7 so a live human can try the member or the facility before the driver rolls. When the denial arrives, your appeal packet builds itself from records already captured. In the builds we have shipped, that turns no-show denials from an automatic write-off into a recovery line, and the same instrumentation kills the dry runs you would have driven anyway.

Problem: claims go out with the wrong modifier and come back 45 days later

The 837P for NEMT is unforgiving. A0130 for wheelchair, A0120 for ambulatory mileage, S0215 depending on payer, and the modifier pairs that encode origin and destination: RH, RN, RD, and the rest. Get the origin/destination modifier wrong on a nursing-facility-to-hospital leg and you get a denial that looks identical to fifteen other denial types. Your biller finds out in six weeks and reworks it by hand.

General billing tools and even NEMT-specific ones let you map codes, but the mapping is static. They do not know that this particular broker started rejecting a modifier combination three weeks ago. Your biller learns by pattern recognition and a sticky note on the monitor.

What a custom build does: claims are validated before submission against rules derived from your own remittance history. Every 835 that comes back is parsed and stored with the claim's full attribute set, so the system learns which combinations of payer, level of service, origin type, destination type, and modifier actually paid. New claims get scored against that history, and anything below threshold routes to a pre-submission review queue with the specific reason: "this payer denied 11 of the last 12 claims with this modifier pair on facility-to-facility legs." This is where AI does real work, and not as a chatbot. Two places specifically. First, document extraction: physician certification statements and PCS forms arrive as faxes and phone photos, and an extraction model pulls the signature date, diagnosis, and certification period, then flags certifications expiring inside 30 days so you are not running trips against a lapsed PCS you cannot bill. Second, denial classification: the free-text remark on a denial gets classified into an actionable bucket and routed, so your biller works appeals by category instead of reading 200 EOB lines. Both are narrow, checkable, and reversible. Neither should ever auto-submit a claim.

Problem: after-hours booking and facility calls eat a dispatcher you cannot afford

Discharge calls come at 7pm. Facilities call to add tomorrow's trips at 6:30am. Members call to confirm pickups all day. Most operators either pay for overnight dispatch coverage or lose the trip to whoever answers.

A voice agent on the intake line, backed by your actual trip data, handles the confirmable cases: member calls to confirm tomorrow's pickup, gets the real time and vehicle ETA. Facility scheduler calls to add a discharge, and the agent captures member ID, level of service, pickup facility, destination, and mobility requirements, then creates a pending trip that a human confirms at 6am. Anything ambiguous, anything involving a schedule change to an existing trip, anything where the member sounds distressed, escalates to a live person immediately. The rule is simple: the agent can create and read, it cannot cancel or modify. That boundary is what makes it safe to run overnight. Facility scheduler portals matter just as much, because the highest-volume facilities want to self-serve at 5am and every trip they enter themselves is a trip your dispatcher did not re-key.

What this actually costs and how long it takes

Across 2,000-plus projects, Digital Heroes sees a focused first release land between $60k and $130k, shipping in 12 to 16 weeks. For NEMT that scope is typically: canonical trip model, one or two broker adapters with reconciliation, a dispatch board that replaces the spreadsheet, a driver app with geofenced arrival and the wait-timer evidence chain, and 837P generation with 835 posting. That is enough to stop the two biggest leaks.

Full platform work, meaning multi-broker EDI at scale, continuous optimization, facility portal, voice intake, claims scoring against your remittance history, and a real reporting layer, runs $150k to $400k phased over 6 to 12 months. Phase it. Never build all of it before any of it is in a driver's hands.

What drives price up in this category specifically: the number of distinct broker and payer integrations, because each one is its own adapter, its own quirks, its own test cycle, and portal-scrape adapters cost roughly double a clean API. HIPAA posture, meaning BAAs, audit logging on every PHI read, encryption at rest, and access controls that survive a real audit, adds real engineering time and is not optional. Offline tolerance in the driver app, because your vans go through rural dead zones and the app must queue signatures and timestamps and reconcile without duplicating trips. State-specific Medicaid rules if you run fee-for-service alongside broker work. And data migration from Tobi or RouteGenie, where the standing orders and recurring templates are the hard part, not the trip history.

Build versus buy, and where the line actually sits

Stay on the off-the-shelf tool if you are under roughly 40 trips a day, running one broker, in one county, with one dispatcher. Tobi and RouteGenie are competent products and they solve that operator's problem for a few hundred dollars a month. Buying vans beats buying software at that size, every time. Do not let anyone tell you otherwise.

Build when these show up together: you run more than 150 to 200 trips a day, you carry three or more broker or payer relationships, your denial rate is high enough that your biller cannot explain it in one sentence, you employ a human whose full-time job is moving data between two systems, and you have lost a contract or a facility relationship over on-time performance you could not measure. The clearest single signal: your operations manager has a spreadsheet that the software cannot replace, and that spreadsheet is what actually runs the business. That spreadsheet is a specification. It is telling you the vendor's model does not match yours, and no amount of configuration closes that gap.

The honest middle path most operators skip: keep the off-the-shelf tool for scheduling and build only the reconciliation and billing layer on top of it, reading through its API. That is often a $60k to $90k project that recovers more money than a full replacement and does not put your dispatch board at risk. Take it if it fits.

How to choose a developer for NEMT software

Ask them to explain the origin and destination modifier logic on an 837P without looking it up. If they cannot describe why a facility-to-facility leg codes differently than a residence-to-hospital leg, they have never shipped this and you will pay for their education. The domain data model is the whole game here: trip versus leg versus authorization versus claim are four different objects with four different lifecycles, and a developer who models a trip as one row will build you something that cannot handle a will-call return.

Ask what they have integrated with by name. ModivCare, MTM, Access2Care, a state Medicaid MMIS, a clearinghouse. Ask specifically what happens when a broker has no API and the answer is a portal. If they have not built and maintained a scrape adapter, they do not know that the real cost is the maintenance, not the build, and they will underquote you and then resent the project.

Push on HIPAA specifics, not the word. Will they sign a BAA. How do they log PHI access, and can they produce an access report for a single member across a date range. How is the driver app's local cache encrypted, and what happens when a driver's phone is lost. Vague reassurance here is disqualifying.

Get the code ownership and the exit in writing before the first invoice. You own the repository, the infrastructure runs in your cloud account, and there is a documented handover. Then ask the uncomfortable question: what happens if we want to move off you in year two. A developer who has a clean answer is one who expects the software to outlive the relationship, which is the correct expectation for a system your entire operation depends on.