NEMT Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does broker adapter scope get underestimated so often?

Every proposal in this category has a line that reads broker integrations, with a number beside it. That line is where these projects go wrong, because ModivCare, MTM, Access2Care, Veyo and a state Medicaid fee-for-service line are not five instances of one job. One pushes a nightly file. One expects you to pull from a portal. One sends trip changes by email to a shared inbox. Their trip identifiers do not match yours or each other's, and their cancellation semantics differ.

The estimating error is treating a portal-only broker the same as one with a proper interface. A scrape adapter costs roughly double an interface-based one to build, and the real expense is not the build, it is the maintenance when the portal changes markup without notice. A developer who has not run one in production quotes the build and then resents the project when the portal moves in month five.

The fix is to price adapters individually, by broker, by name, with a stated integration method for each, and a separate ongoing maintenance allowance for anything scraped. Then sequence them: your two highest volume brokers in release one, everything else in phase two. Reconciliation is what earns the money, not the count of adapters, so a build with two brokers reconciling every fifteen minutes beats one with five brokers importing and never checking.

What goes wrong when standing orders and trip history get migrated?

Trip history is easy. Nobody has ever lost money because a completed trip from 2023 imported with the wrong mileage. The migration risk sits entirely in recurring templates, authorisations and member records.

A standing order is not a repeating calendar entry. It carries a level of service, an authorisation with a period and a trip count, a facility, a chair or appointment time that may have been amended in the broker's system but not in yours, and often a member preference that a dispatcher has never written down. Export it flat and you lose the parts that matter. Import it without checking against the broker's current picture and you inherit every discrepancy that already existed, then run against it automatically, which is worse than a human noticing on the second week.

The discipline is simple and it is skipped constantly. Before cutover, validate every live recurring order against the broker's current authorisation and current schedule, one at a time, and resolve differences before the new system is allowed to dispatch anything. Treat member records the same way: duplicates created by name variations and different member identifiers across brokers will otherwise produce two trips for one person on the same morning. Budget explicit weeks for this rather than assuming an export handles it, and run parallel for two to four weeks so a discrepancy shows up as a mismatch rather than as an empty driveway.

Why do broker and clearinghouse integrations break after launch?

They break because they were built against a moment rather than against a contract. A broker adjusts its will-call rules, a portal changes its layout, a state changes brokers mid-contract, and the adapter that worked for nine months silently returns fewer trips. The dangerous part is silence: a feed that fails loudly gets fixed the same morning, while a feed that returns an empty result set looks exactly like a quiet Tuesday.

The claims side fails differently. Modifier pairs encoding origin and destination, the codes for ambulatory and wheelchair legs, and payer-specific expectations all drift. A mapping that was correct at launch starts producing denials weeks before anyone connects the pattern, because denials arrive forty five days later and by then nobody remembers what changed.

Two defences matter. First, monitor expected volume rather than only errors: if a broker that normally delivers a hundred and forty trips delivers nine, that is an alert, not a data point. Second, close the loop on remittances by parsing every 835 back into a rules history keyed to the claim's full attribute set, so the system can flag a submission whose payer, level of service, origin type and modifier combination has been failing recently. That turns integration drift into a pre-submission warning instead of a six week surprise.

What happens when the evidence chain and HIPAA posture are not covered?

Most no-show denials are lost before the appeal starts, because the only evidence is a driver tapping a button. A defensible package needs geofenced arrival with the recorded accuracy, a wait timer the driver cannot short-circuit, a logged contact attempt with a real call record and duration, and a timestamped photo. Contract wait rules also differ between brokers, so a single hard-coded wait period will be wrong for at least one of your payers.

The HIPAA gap is the other half, and it is the one that gets waved through in sales conversations. Compliance is not a checkbox in a feature list. It is a signed business associate agreement, encryption at rest and in transit, audit logging on every read of protected health information so you can produce an access report for one member across a date range, an encrypted local cache in the driver app, and a remote wipe path for a lost phone. Every one of those is engineering time.

Ask for them as named deliverables with acceptance criteria. The test that separates real from claimed is simple: ask the developer to produce, on demand, a report of everyone who viewed a specific member's record in the last ninety days. A team that has built this will show you the query. A team that has not will explain that access is restricted, which is not the same answer.

Should you build custom or configure what you already own?

Under roughly forty trips a day on a single broker contract, do not build. Tobi and RouteGenie are competent products that solve that operator's problem for a few hundred dollars a month, and your capital belongs in vehicles. NEMT Cloud sits in the same bracket. Nobody has ever regretted buying a van instead of a platform at that size.

There is also a middle path most operators skip. Keep Tobi or RouteGenie for scheduling and build only the reconciliation and billing layer on top, reading through the incumbent's interface. That is typically a $60k to $90k project, it recovers denial and dead-mile money, and it never puts your live dispatch board at risk. It also tells you honestly whether a full replacement is warranted, because if reconciliation alone fixes your margin, the vendor's model matches yours better than you thought.

Before either, spend a day on what you already have. Most operators have never configured level of service durations properly, never set per-facility service times, and never used the exception views their tool already offers. The clearest signal that configuration has run out is when your operations manager keeps a spreadsheet the software cannot replace, and that spreadsheet is what actually runs the business. That spreadsheet is a specification.

How do hidden costs get into the quote?

Five line items are routinely absent.

Portal-scrape adapters, priced as a build with no maintenance allowance, when maintenance is the real cost. HIPAA posture, which adds real engineering time for audit logging, encryption and access controls that survive an audit rather than a conversation. Offline tolerance in the driver app, because vans go through rural dead zones and the app has to queue signatures and timestamps and reconcile without duplicating a trip, which is an architecture decision on day one rather than a feature added later. State-specific fee-for-service rules if you run that alongside broker work. And migration, which as covered above is a validation exercise rather than an export.

The honest bands from Digital Heroes delivery experience are $60k to $130k for a focused first release over 12 to 16 weeks, and $150k to $400k for a full platform phased over 6 to 12 months. A quote that lands under those bands has usually omitted the compliance work, the offline work, or both, and both will arrive later as change requests at a worse moment.

What separates an NEMT build that works from one that fails?

The builds that work put something in a driver's hands inside the first quarter and never build all of it before any of it is live. The scope that reliably lands is the 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 claim generation with remittance posting. That is enough to stop the two biggest leaks, and it funds the rest.

The second differentiator is whether the developer models the domain correctly. Trip, leg, authorisation and claim are four objects with four different lifecycles. A team that models a trip as one row will build something that cannot represent a will-call return, and you will discover that on the day a dialysis clinic calls forty minutes late. Make them draw it before contracts, and make them explain why a facility-to-facility leg codes differently from a residence-to-hospital leg.

The third is the exit. Own the repository, run the infrastructure in your own cloud account rather than the developer's, and get a documented handover in writing before the first invoice. Then ask what happens if you want to move on in year two. A clean answer means they expect the software to outlive the relationship, which is the correct expectation for a system your whole operation depends on, and it is also the only arrangement in which your protected health information is genuinely under your control.