Real-Time NEMT Dispatch Platform
@ Operr — Software Engineer
Optimizing non-emergency medical transportation with intelligent real-time dispatch and route optimization
$ cat PROBLEM.md
Manual Dispatch Couldn't Handle Complexity
NEMT transportation involves complex constraints: appointment times, vehicle types (wheelchair, stretcher), driver certifications, and real-time traffic. The existing phone-based dispatch system led to inefficient routing, missed appointments, and underutilized drivers. Dispatchers were overwhelmed during peak hours.
Key Challenges:
- Dispatchers manually matching rides to drivers using paper logs and phone calls
- No visibility into real-time driver locations or availability
- Appointment times missed due to poor route planning
- Vehicle type mismatches — ambulatory patients assigned stretcher vehicles
$ cat SOLUTION.md
Event-Driven Dispatch with Intelligent Route Optimization
We built a real-time dispatch platform using Spring Boot microservices and Kafka, with a custom route optimization engine that considers all NEMT-specific constraints.
Technical Approach:
Event-Driven Architecture
Every ride request, driver location update, and status change flows through Kafka. The system reacts in real-time to changing conditions.
Constraint-Aware Matching
Custom matching algorithm considers vehicle type, driver certifications, appointment windows, and predicted traffic to find optimal assignments.
Real-Time Driver Tracking
GPS integration provides live driver locations. Geofencing triggers automatic status updates when drivers approach pickup/dropoff locations.
Predictive ETA Engine
ML model trained on historical trip data provides accurate ETAs that account for time-of-day, weather, and route-specific patterns.
$ cat tech-stack.json
🚀 Core Technologies
Spring Boot
Microservices framework
Why: Mature ecosystem, excellent Kafka integration, enterprise-grade reliability
Apache Kafka
Event streaming and messaging
Why: Real-time event processing with replay capability for debugging
PostgreSQL + PostGIS
Ride data and geospatial queries
Why: Powerful geospatial functions for location-based matching
🔧 Supporting Technologies
☁️ Infrastructure
$ cat ARCHITECTURE.md
The platform uses event-driven microservices:
| |
System Components:
Ride Service
Manages ride lifecycle from request to completion
Matching Service
Constraint-aware driver-ride matching engine
Location Service
Real-time driver tracking and geofencing
Route Service
ETA calculation and turn-by-turn navigation
$ man implementation-details
Building the Matching Engine
The matching algorithm had to balance multiple competing objectives:
Hard Constraints (must satisfy):
- Vehicle type matches patient needs
- Driver has required certifications
- Can reach pickup within time window
Soft Constraints (optimize):
- Minimize total miles driven
- Balance workload across drivers
- Prefer drivers familiar with the route
Implementation:
| |
Real-Time Location Processing
Processing driver locations at scale required careful optimization:
Location Update Flow:
- Driver app sends GPS every 10 seconds
- Location Service validates and enriches data
- Published to Kafka
driver-locationstopic - Multiple consumers: matching, geofencing, ETA recalculation
Geofencing for Auto-Status:
- 100m radius around pickup → “Arriving” notification
- At pickup location > 2 min → Auto “Waiting” status
- 100m radius around dropoff → Prepare for completion
Redis for Hot Path:
| |
$ echo $RESULTS
40% Improvement in Driver Utilization
Additional Outcomes:
- Dispatchers went from overwhelmed to strategic, handling 3x ride volume
- Vehicle type mismatches reduced to near-zero
- Driver satisfaction improved with fair, optimized assignments
$ cat LESSONS_LEARNED.md
Constraints Are Features, Not Bugs
NEMT constraints (vehicle types, certifications, appointment windows) seemed like obstacles but became competitive advantages when properly encoded in the matching algorithm.
Real-Time Requires Tolerance for Imperfection
We built the system to gracefully handle delayed GPS updates, network issues, and driver app crashes. Eventual consistency was acceptable for most operations.
Driver UX Determines Adoption
The best algorithm means nothing if drivers don't use the app. We invested heavily in a simple, one-tap interface for common actions.
$ cat README.md
Related
Experience: Software Engineer at OPERR
Technologies: Spring Boot, Java, Kafka, PostgreSQL, Redis
Related Case Studies: Hospital ERP System | Real-time EdTech Platform
Want Similar Results?
Let's discuss how I can help solve your engineering challenges.