MedRide Mobile Documentation

Talking points for the demo — non-technical

Demo Overview

A snapshot of where MedRide's mobile platform stands today — written for the conversation, not the codebase. Use these as talking points.

The headlines

• Drivers are using the app in the field, today. Not a prototype. A live cohort of 30 drivers at Grand Junction School District 51 is running their daily routes through the app.
• The morning manifest is automatic. Every night the system pulls the next day's schedule from MediRoutes and pushes it to each driver's phone, attributed to the right person. The driver doesn't have to look anything up.
• Carpooling is solved. When two kids ride together — same pickup, same drop, or anything in between — the app handles it intelligently in one tap. No more "I picked up Kaleb but the app still wants me to pick up Kolton."
• The guardian sees the ride happen. Parents follow the trip in their own app: the driver pin updates every few seconds, the status flips as the kid is picked up and dropped off.
• The district runs their own contract. A school admin can log in, see the day's trips, retrigger an import if something changed, and configure how their contract behaves — without engineering help.

What's different from a month ago

• Drivers used to coordinate by phone calls and paper manifests. Now the manifest is in their pocket and updates automatically.
• Parents used to wait for the driver to call. Now they get notifications and can see the van approaching on the map.
• A morning routing change used to mean calling every driver. Now the admin presses one button and every affected driver's phone updates.

Carpooling — the crowd-pleaser

For school district transportation, siblings ride together all the time. We just rolled out intelligent carpool handling so the driver's experience matches reality:

The grouping is automatic — the driver doesn't have to pick a mode. The app looks at where and when each pickup/drop-off happens and groups the ones that share a curb.

What the driver experience looks like during a trip

1. Driver opens the app at the start of the shift — today's schedule is already there.
2. Taps a stop — the phone's native maps app opens with turn-by-turn directions.
3. As they drive, the map follows them and the orange route line "eats itself" behind the car (Waze-style).
4. They arrive — the Confirm Pickup button unlocks only when they're within the curb's geofence. The driver can't accidentally mark pickups they didn't physically attend.
5. After confirming, the schedule advances to the next stop. Repeat.

What the parent experience looks like

1. Parent opens their app — sees today's trips for their kid.
2. As the driver progresses, status updates land in the app: "Driver is on the way" → "Arrived at pickup" → "Picked up" → "Dropped off".
3. Real-time map: the driver's pin updates every 15 seconds. No more "where's the van?" phone calls.

How we'd describe the architecture in one sentence

"Two phone apps and a school district web portal, all pointed at the same trip data, fed every night by the existing MediRoutes scheduling system."

No new data entry. No new system to learn. Pam's office still works inside MediRoutes the way they always have. The mobile platform takes that schedule and makes it useful on every device that needs it.

What's coming next

• Open the pilot beyond District 51 once we've sustained two weeks of clean morning imports.
• Self-serve driver onboarding from the admin portal (Pam adds new hires without engineering involvement).
• Expand guardian rollout to more families.
• Voice AI for trip requests (the Pulsar service) that feeds into the same engine.

Pilot scope and how the pieces connect

Overview

Ride.dev's mobile platform powers the day-to-day operation of MedRide's non-emergency medical transportation contracts. It connects three groups of people who each see their own purpose-built experience:

• Drivers — receive their daily route on a phone, navigate to each pickup, and confirm arrivals through the driver app.
• Guardians (parents and caregivers) — track the rider's trip in real time and stay in contact with the driver through the guardian app.
• School district administrators and dispatchers — manage the contract through the admin portal at app.ride.dev.

All three experiences share the same trip data, driven by the same upstream MediRoutes scheduling system used by MedRide's office staff.

What's live today

How the pieces connect

Every morning before drivers start their routes, the orchestrator pulls the day's manifest from MediRoutes, attributes each trip to the correct driver, and pushes it down to their device. Drivers don't have to log in to MediRoutes themselves — they just open the app.

What "go live" means in this pilot

1. Drivers can log in with credentials issued by MedRide ops, see their real route, drive it, and confirm pickups and drop-offs without having to coordinate by phone or paper.
2. Guardians can see when their child is going to be picked up, when they arrive, and where they are during the ride.
3. School district administrators can monitor on-time performance and reconcile the day's trips against MediRoutes without leaving the portal.

The remaining sections document each of those three experiences, the data pipeline that powers them, the onboarding process for new drivers and guardians, and the current state of the pilot.

Driver app and guardian app — features and daily flow

Mobile Apps

Two apps run on top of the same trip data — one for the driver behind the wheel and one for the guardian following along at home. Both ship on iOS and Android.

Driver app

The driver app is what each MedRide driver opens on their phone at the start of every shift. It replaces a stack of printed manifests and the ad-hoc phone calls between dispatcher and driver.

Daily experience

A driver's day in the app follows a predictable rhythm:

1. Log in — first time, the driver enters the temporary password issued by MedRide ops; the app immediately prompts them to set their own password. After that, biometric/PIN unlock.
2. See today's schedule — a chronological list of stops for the day, each one a pickup or drop-off with a passenger name, time window, and address.
3. Navigate to the next stop — tapping the active stop opens the phone's preferred maps app (Apple Maps / Google Maps / Waze) with turn-by-turn directions to the address.
4. Confirm arrival on site — once the driver is physically at the stop, the "Confirm" button unlocks. Until they're inside the pickup geofence, the button stays disabled and the app shows the remaining distance ("820 ft away — confirm unlocks within 250 ft").
5. Repeat for each stop — the schedule progresses automatically as each pickup and drop-off is confirmed.

Why the geofence matters

MedRide is reimbursed for trips that genuinely happened. The geofence gate ensures drivers can't accidentally — or intentionally — confirm a pickup before they're at the address. The radius is configurable per contract: tight for residential pickups, looser for hospitals and schools where parking lots are large.

When the driver is en route, the app shows a live distance hint in feet and miles (US pilot).

What the driver sees in each card

For every stop, the card surfaces the information drivers actually need before pulling away:

• Passenger first and last name
• Pickup or drop-off label
• Scheduled time and current ETA
• Full address with one-tap copy
• Capacity / mobility flags (ambulatory, wheelchair, escorted)
• Any free-text driver notes from MediRoutes (allergies, gate codes, accessibility instructions)
• Distance to the stop while en route

Information that isn't relevant to a driver — diagnoses, billing codes, funding source — is intentionally hidden.

Communication

A "chat" thread is available per trip, scoped to the assigned driver and the rider's guardian. The chat can be turned off per contract by an administrator: some districts prefer no driver-guardian channel, others require it.

Driver app — what's been built

Guardian app

The guardian app is the parent or caregiver's window into their rider's trip. For school district contracts, guardians are typically parents of students in special-needs transport.

What guardians see

A guardian opens the app and lands on a list of trips for the people they're linked to (their kid, their spouse, the patient they manage). Each trip card shows:

• Rider's name and the trip's purpose (school AM run, dialysis, etc.)
• Scheduled pickup and drop-off times
• Pickup and drop-off addresses
• Driver's name and vehicle once assigned
• Live status — Scheduled, Driver En Route, Arrived, Picked Up, Dropped Off

Guardians can have more than one rider linked to their account. For a parent with two kids both in school transport, both children appear in the same app under one login.

Real-time status updates

The status of each trip updates as the driver progresses through the day, with no manual refresh needed. The sequence on a typical school morning:

1. Scheduled — the trip exists for today; nothing has happened yet
2. Driver assigned — a specific driver and vehicle are on the trip
3. En route to pickup — driver has started moving toward pickup
4. Arrived at pickup — driver confirmed arrival (geofence-gated, so this means physically there)
5. Picked up — rider has been confirmed in the vehicle
6. Dropped off — rider has been delivered

For nervous parents, the most-used status is "Arrived at pickup": "the van is here, send the kid out."

Linking guardians to riders

A guardian can be linked to multiple riders, and a rider can be linked to multiple guardians (e.g. divorced parents, primary and backup caregivers). Permissions are per link — a guardian might be able to view trips and receive notifications for one rider but only view (no notifications) for another.

Guardian app — what's been built

What district admins and dispatchers can do

School District Admin Portal

The admin portal lives at app.ride.dev and is what district transport coordinators, MedRide operations, and school administrators use to oversee the day's trips. It's the same Web2.0 application as the public marketing site — just a different entry point gated by login.

Who logs in

Three roles use the portal today:

• MedRide operations (Pam and her team) — full visibility across every contract and tenant.
• School district transportation coordinators — visibility scoped to their own district. For District 51, that's the team in Grand Junction.
• Dispatchers — day-of operational view, can re-attribute trips between drivers when something changes mid-day.

Drivers and guardians don't log into the portal. Their experience lives entirely in the mobile apps.

What admins can do

See the day's trips

A live list of every trip on the contract: who's the rider, who's the driver, what's the status, where is the vehicle right now. Filterable by funding source, date range, status, and driver.

Trigger a manual MediRoutes sync

The daily import runs automatically every morning. If the schedule changes mid-day — a route gets re-cut, a driver calls in sick — the admin can trigger an immediate re-sync from MediRoutes, scoped to just their district's contract so other tenants are not affected.

Manage drivers and employees

The Employees page lists every driver on the contract, their funding source assignments, current vehicle, and onboarding status. Admins can:

• See which drivers are linked to which contracts
• Reassign a driver from one funding source to another
• See the driver's MediRoutes attribution status

Configure contract behavior

Each contract (funding source) has a Settings panel where the admin can change behavior without code changes:

• Chat enabled — turns the driver-guardian chat on or off for every trip on this contract.
• Arrival confirmation radius — how close (in meters today, soon in feet) the driver has to be to the address before the "Confirm" button unlocks. Default is 200 m for most contracts; District 51 uses a tighter radius for residential pickups.

These settings take effect on the next time the driver app pulls its schedule — no app update needed.

Reconciliation

At the end of each day, admins can compare what MediRoutes scheduled against what actually happened in the app — which trips were confirmed, which were no-shows, which were cancelled mid-route. This is the same data MedRide bills against.

Data the portal doesn't expose

By design, drivers' and guardians' personal information is not viewable in the portal beyond what's needed for operations. PHI fields (diagnosis codes, Medicaid IDs, dates of birth) are encrypted at rest and only surfaced to roles that genuinely need them. School district admins see student names and addresses; they do not see medical records.

What's been built for go-live

How trips flow from MediRoutes onto every device

Daily Trip Pipeline

Every morning, before drivers start their shift, the day's trips need to flow from MediRoutes — where MedRide's office staff plan them — onto each driver's phone, attributed to the correct driver, in their local time zone, with the correct passenger details.

This pipeline runs without anyone pressing a button. By the time a driver opens the app, today's route is already there.

The flow

What happens, step by step

1. Scheduled at MedRide HQ — MedRide office staff plan tomorrow's trips inside MediRoutes, assigning each ride to a vehicle, a driver, and a route. By the end of the workday, MediRoutes is the source of truth for tomorrow's manifest.

2. Pre-dawn export — a background worker on Ride.dev's side calls MediRoutes around 4:30 AM Mountain Time and pulls the day's full schedule for every contract.

3. Attribution — the orchestrator walks every trip and links it to the right driver record on Ride.dev, using the driver's name as shipped by MediRoutes. Drivers whose name on file matches a pre-onboarded driver are matched in this step. Trips for unknown names temporarily land on a placeholder record until the driver is onboarded.

4. Funding-source filter — each trip is attributed to the right contract (school district, Medicaid, private pay, etc.) so the driver app can show only the trips relevant to that driver's role.

5. Slack notification — operations gets a summary in the #mediroutes-import-data Slack channel: total trips imported, per-driver breakdown, and any trips that couldn't be attributed. This tells Pam if a driver was missed in onboarding, before drivers even open their phones.

6. Driver opens the app — pulls today's stops attributed to them. Local time, no UTC drift.

7. Guardian opens the app — pulls today's trips for the riders they're linked to.

Why attribution by name is fragile (and what we do about it)

MediRoutes assigns trips to "Tom Ferry" while HR knows him as "Thomas Ferry". MedRide's office calls a particular driver "Goose" even though his legal name is "Gustavo". Attribution that matches on the legal name would silently skip these drivers' trips every morning.

We work around this in two ways:

1. Onboarding stores the MediRoutes shipping name — the driver record on Ride.dev keeps both names: the legal name (what the driver sees in the app) and the MediRoutes shipping name (what's used to match incoming trips). Any nicknames or middle-name inconsistencies get captured at onboarding time.

2. The system auto-learns the MediRoutes employee ID the first time a driver appears on a real route. Once that ID is on file, attribution becomes unambiguous and name spelling no longer matters.

Manual sync for mid-day changes

The morning import is the bulk of the work, but routes change. A driver calls in sick at 9 AM and Pam re-cuts three routes; a new patient gets added at lunch. Either Pam or the school district admin can trigger a fresh sync from the admin portal — scoped to just their contract — and the affected drivers' apps will reflect the change on the next pull.

What can go wrong (and what we monitor)

The system is built to fail loudly, not silently — operations is notified before drivers are.

Current state of the District 51 pilot

Pilot Status — Grand Junction School District 51

The first production rollout of MedRide's mobile platform is with Grand Junction School District 51 in Colorado, contracted through MedRide for special-needs student transportation.

Snapshot date: 2026-05-07. This page is updated as the pilot progresses.

At a glance

What's working today

• The morning MediRoutes import runs reliably and posts a per-driver trip count summary to Slack so Pam can spot anomalies before drivers start their shift.
• Drivers can log in, see their stops, navigate, and confirm pickups inside the geofence. The geofence radius is configured tightly for residential pickups (the bulk of school transport) and loosely for large facilities.
• The school district admin and MedRide ops have a manual re-sync button that re-pulls just District 51's trips from MediRoutes without affecting any other contract.
• All 30 driver accounts have been provisioned with onboarded credentials handed to Pam via Slack. Drivers can log in on demand as they're scheduled.
• The chat between drivers and guardians is currently disabled for District 51 — the district prefers all communication go through their dispatch.

Driver-by-driver attribution

Of the 30 drivers, the system attributes their trips by matching the name MediRoutes ships against the name on file. A handful of drivers use nicknames in MediRoutes that don't match their legal name (Tom vs Thomas, Mike vs Edward, Goose vs Gustavo); their records are configured to match the MediRoutes spelling so attribution succeeds every morning.

A small set of drivers haven't yet had their MediRoutes employee ID auto-learned by the system because they haven't been assigned a real route since onboarding. The first time they appear on a route, the system records the ID and they're permanently locked in.

Known operational issues being tracked

• Some pilot drivers have not yet attempted first login. Pam is rolling out logins in cohorts so issues can be triaged in batches.
• A few drivers' MediRoutes nicknames differ from their HR records. The fix is one of two: rename the driver in MediRoutes to match HR, or carry the nickname on the Ride.dev profile. Both are being applied case by case.
• A new hire was just added (Jody Campbell, May 7). Account provisioned but she hasn't yet been assigned to a route in MediRoutes — her trips will start flowing once Pam adds her to a daily run.

What's next

In rough priority order:

1. Continue rolling out logins to the remaining drivers and ensure all 30 have completed first-login.
2. Migrate the geofence distance display to the imperial system end to end (drivers asked for feet/miles instead of meters/km — done in the latest build).
3. Move driver onboarding to a self-serve admin form so Pam can add new hires without engineering involvement.
4. Open the pilot to a second district once D51 has sustained two weeks of clean morning imports and stable driver login rates.
5. Roll out guardian app to a wider set of pilot families once driver side is stable.

Why the pilot is in District 51 first

District 51 was chosen because it's a manageable scope (≈30 drivers, predictable AM/PM school routes, low trip count compared to MedRide's broader Medicaid contracts) while still exercising every part of the system: real drivers, real students, real guardians, real geofences, real disputes when something goes wrong. If the pipeline can survive the morning rush at D51, scaling to MedRide's larger contracts is a configuration change rather than a re-architecture.