01
Standing order generation
Recurring dialysis and therapy rides created from rules, with closures and holds applied.
Healthcare / NEMT Dispatch
Custom NEMT dispatch software development
By mid-morning, cancellations, late vehicles and will-call returns have broken the plan your dispatchers made at dawn. Agnotic Technologies builds NEMT dispatch engines that know each rider's level of service and time limits, re-plan only what changed and log every manual move.
Level of service
Hard rule on assignment
Will-call
Returns re-planned live
Overrides
Logged with a reason
Trusted by global innovators
Industry Overview
What is custom NEMT dispatch software development?
Custom NEMT dispatch software development is building the engine that assigns non-emergency medical trips to vehicles and drivers, then re-plans the day as rides change. Agnotic Technologies builds dispatch engines that model level of service, pickup windows, ride-time limits, shared-ride rules, standing orders and will-call returns, with every dispatcher override logged.
Industry Challenges
Why do NEMT dispatch boards fall apart by mid-morning?
The trip list is rarely the problem. The rules behind each trip are missing from the data, so the board cannot respect them when the day changes.
Level of service is a free-text note, so a stretcher trip lands on an ambulatory sedan and the driver has to turn back.
Standing orders are copied by hand each week, and a holiday closure at the dialysis center is missed.
Will-call returns have no time until the clinic calls, so the board either holds a vehicle idle or forgets the rider.
Shared rides are grouped by distance alone, ignoring riders whose program or condition rules out sharing.
The optimizer re-plans the whole day on every change and moves drivers who are already on their way.
Manual moves leave no trace, so nobody can explain later why a pickup was late.
Decision table
How should the engine treat each dispatch constraint?
Every constraint is either a hard rule the engine never breaks, a soft penalty it trades against others, or a call left to the dispatcher. We agree this table with your operations lead before writing the solver.
| Constraint | How the engine treats it | Data field it needs |
|---|---|---|
| Level of service (ambulatory, wheelchair, stretcher, bariatric) | Hard rule: the trip goes only to a vehicle and driver qualified for it | Trip level of service, vehicle capability, driver qualification flags |
| Vehicle capacity and securement positions | Hard rule: seats and securement positions are counted on every leg, including attendants | Vehicle seat map, securement positions, lift capacity, attendant count |
| Pickup window | Hard at the edges, soft inside: early arrival costs a small penalty, late needs a dispatcher override | Window start and end, appointment time, facility hours |
| Maximum ride time | Hard rule per rider, from the program or broker contract | Maximum on-board minutes per trip or program |
| Shared-ride eligibility | Hard exclusion when the rider or program rules it out; otherwise a soft preference to group | Shared-ride flag with reason code, program rules |
| Driver shift and breaks | Hard on shift end; soft on break timing within the allowed range | Shift start and end, break rules, time on duty |
| Will-call return | Unscheduled until the call, then inserted with a response target as a soft penalty | Will-call flag, expected pickup range, facility contact |
| Dispatcher override | Always wins, and is logged with the rule it broke | User, time, reason code, constraint broken |
Our Approach
How should an NEMT dispatch engine be designed?
Three design choices separate an engine dispatchers trust from one they work around.
Separate rules from preferences
Level of service, capacity and shift end are rules. Grouping riders and arriving early are preferences with a cost. Keeping them apart stops the solver trading safety for mileage.
Re-plan locally
Trips already en route or about to start are frozen. A change re-plans only the vehicles it touches, so drivers are not reshuffled across the whole day.
Make overrides data
Dispatchers will always know things the engine does not. Each override records the rule it broke and a reason, and the reasons feed back into the rules.
Capabilities
What do we build into a custom NEMT dispatch engine?
How to build custom NEMT dispatch software that holds up on a busy day. The driver app, broker import and billing are separate modules around this engine.
Trip constraint model
Level of service, window, ride-time limit, attendants and shared-ride eligibility stored as fields on every trip, never as notes.
Standing order generator
Recurrence rules for dialysis, therapy and treatment series, with facility closures, rider holds and review dates, generated ahead of the service day.
Assignment solver
A vehicle routing model, for example built on Google OR-Tools, that respects the hard rules and scores the soft ones for your fleet.
Will-call queue
Return trips waiting for the clinic's call, each with an expected range, so the engine keeps a qualified vehicle within reach.
Same-day re-planning
Cancellations, no-shows, late vehicles and new trips trigger a local re-plan that dispatchers see as a list of proposed changes.
Shared-ride grouping
Riders grouped only where the program and the rider allow it, with every leg checked against each rider's ride-time limit.
Dispatcher board
Map, unassigned queue and vehicle timelines, where a drag to reassign is checked against the rules before it is saved.
Override and audit log
Every manual change with user, time, reason and the constraint it broke, searchable by trip, driver and day.
How It Works
How does the engine re-plan the day when a ride changes?
The loop that runs each time something changes after the morning plan is published.
An event arrives
A cancellation, no-show, will-call, late vehicle or new same-day trip enters the event log with its time.
01
1
Freeze what is committed
Trips already en route, or starting within your agreed lead time, are locked so drivers are not pulled off a pickup.
02
2
Re-plan the affected window
Only vehicles whose routes touch the changed trip are solved again, which keeps the change small and fast.
03
3
Check the hard rules
Any candidate plan that breaks level of service, capacity, ride time or shift end is rejected before anyone sees it.
04
4
The dispatcher confirms
Proposed moves appear as a short list. The dispatcher accepts, edits or rejects them, and each choice is logged.
05
5
Publish
Updated manifests go to drivers and status updates to riders and facilities through the channels your operation already uses.
06
6
Engineering Stack
Systems and standards behind a dispatch engine
Chosen to fit your fleet size, service area and existing trip systems.
Optimization
Vehicle routing with time windowsGoogle OR-Tools or custom insertion heuristicsConstraint settings as versioned configuration
Maps and time
Traffic-aware travel timesGeocoding with address validationTime zone safe scheduling
Data
PostgreSQL with PostGISEvent log of every trip changeStanding orders stored as recurrence rules
Security
Role-based access for dispatch staffAudit loggingEncryption in transit and at restHosting under a BAA
Measured Impact
What should a dispatch engine report?
Measures we build into the dispatch dashboard and review with your operations lead.
On-time
Pickups by level of service
Arrivals inside the window, split by ambulatory, wheelchair, stretcher and bariatric trips.
Will-call
Response time
Time from the clinic's call to the vehicle's arrival for return trips.
Sharing
Grouped where allowed
Shared legs as a share of eligible trips, never of all trips.
Overrides
By reason
Manual moves grouped by reason code, which shows which rules need changing.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Women's Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
Where do NEMT operators start with a dispatch engine?
First releases we scope, each one a single part of the dispatch problem.
02
Mixed fleet matching
Level of service and securement checks for operators running sedans, wheelchair vans and stretcher vehicles.
03
Will-call handling
A queue and re-planning loop for return trips that wait on the clinic.
04
Shared-ride grouping
Grouping that respects program rules and every rider's ride-time limit.
05
Replacing a spreadsheet board
Moving a small operator's daily plan from spreadsheets to an engine with an audit trail.
06
An engine behind an existing product
Assignment and re-planning added to a dispatch product that exposes its trips through an API.
Integrations
Which systems does the dispatch engine connect to?
The engine reads trips and vehicle positions, and writes assignments back.
Trip source
Broker and facility trip intake
Manifests and status
Driver app
Live positions
Vehicle telematics and GPS
Travel times
Maps and routing service
Completed trips
Billing system
Status updates
Rider notifications
What we check
Is your trip data ready for a dispatch engine?
We work through this list with your operations lead before the solver goes live. Every unchecked item becomes a dispatcher workaround later.
Trips and riders
- Every trip has a level of service from a fixed list
- Attendants and escorts are recorded as seats, not notes
- Shared-ride exclusions carry a reason code
- Maximum ride time is set per program or contract
Vehicles and drivers
- Each vehicle has a seat map, securement positions and lift capacity
- Driver qualifications for wheelchair and stretcher trips are current
- Shift and break rules are agreed with operations
Standing orders and overrides
- Every standing order has an end date or a review date
- Facility hours and closure days are loaded
- Override reason codes are defined and reviewed weekly
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does an engagement work?
We start with one part of the dispatch problem. Timing depends on scope; we agree a fixed first release on the scoping call.
01
Scoping call
We walk through a real day of trips with your dispatchers and pick the first problem to solve.
02
Constraint workshop
Your operations lead and our engineers fill in the constraint table, rule by rule.
03
Replay test
The engine plans past days from your own trip history, and dispatchers compare its plan with what happened.
04
Fixed-scope first release
One module, such as standing orders or will-call handling, live beside your dispatchers.
05
Support
Rule changes, new programs and fleet changes under agreed change control.
Facts and sources
Rules behind NEMT dispatch
Short facts the dispatch rules rest on, each linked to its primary source.
A State Medicaid plan must specify that the Medicaid agency will ensure necessary transportation for beneficiaries to and from providers, and describe the methods it will use to do so.
Source: 42 CFR 431.53 (eCFR)Medicaid travel expenses can include the cost of an attendant to accompany the beneficiary when necessary, along with the attendant's transportation, meals and lodging.
Source: 42 CFR 440.170(a)(3) (eCFR)The ADA accessibility specifications for vans and buses set a wheelchair lift design load of at least 600 pounds and a clear floor area of 30 by 48 inches for each securement location.
Source: 49 CFR 38.23(b) and (d) (eCFR)
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related pages
Related NEMT and routing pages
This page covers the dispatch engine. These pages cover the rest of an NEMT operation and the routing patterns behind it.
NEMT software buyer's guide
What to evaluate across intake, dispatch, driver apps, broker workflows and billing.
Dynamic fleet routing engine
Routing and live re-optimization patterns from freight and delivery fleets.
Fleet telematics platform
GPS and vehicle data that feed live positions into dispatch.
Transportation management system
Planning, execution and carrier management for transport operations.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
Fleet size and mix, the number of programs with different rules, how much same-day change you handle, the trip and vehicle data you already have, and whether the engine sits behind an existing product. We explain these drivers on the scoping call instead of quoting a price.
It depends on scope; we agree a fixed first release on the scoping call. Standing orders or will-call handling alone is a smaller first release than a full assignment engine.
No. The engine proposes assignments and re-plans, and dispatchers accept, change or reject them. It removes the repetitive work so dispatchers can handle the calls that need judgment.
The attendant is a seat on every leg of the trip, so capacity checks count them. Medicaid can cover an attendant's travel when one is necessary, which is why the trip record carries the attendant explicitly.
Often, if the product exposes trips and accepts assignments through an API. We check that interface during scoping; if it cannot write assignments back, a separate engine and board is the better route.
Yes. Rider names, addresses, appointments and mobility needs are protected health information when you work for a covered entity or broker. We build HIPAA-ready dispatch software with role-based access and audit logs, and Agnotic signs a business associate agreement before PHI is shared.
Yes. Custom NEMT dispatch software for startups usually begins with level of service matching and standing orders for a single program, then adds shared rides and same-day re-planning as trip volume grows.
Industries