NEMT Trip Manifest
Track each NEMT trip in one manifest with pickup and drop-off times, mileage, mobility type, and passenger attestation. Use it to support cleaner Medicaid billing and a clearer trip record.
Trusted by frontline teams 15 years of frontline software
Built for: Non Emergency Medical Transportation · Medicaid Transportation Brokerage · Healthcare Logistics · Senior Transportation Services
Overview
This NEMT Trip Manifest template records the details needed to document a single non-emergency medical transportation trip: trip date, driver, vehicle, passenger identifier, pickup and drop-off locations, trip type, mobility type, pickup and drop-off times, wait time, odometer readings, trip miles, service exceptions, passenger signature, and driver attestation.
Use it when you need a repeatable trip record for Medicaid billing support, dispatch reconciliation, or internal quality review. The structure is built for operational accuracy: the routing section identifies what was scheduled, the timing and mileage section shows what actually happened, and the signature section captures passenger acknowledgment or a documented exception. It is especially useful when trips vary by mobility needs, when wait time matters, or when you need an audit trail for completed rides.
Do not use this template as a general intake form or a broad patient record. It is not meant to collect clinical details, diagnosis information, or unnecessary PII. If your workflow only needs a simple dispatch log, you may not need passenger signature fields or exception attestation. If your operation never bills by mileage or never requires proof of completion, a lighter trip log may be enough. Keep the form focused on the fields you will actually use, and use conditional logic so exception fields appear only when a trip does not follow the standard path.
Standards & compliance context
- Collect only the passenger and trip data needed for billing support and service verification to align with GDPR data minimization and the minimum-necessary principle.
- If the form collects any PII, include a clear disclosure explaining what will happen after submission and who can access the record.
- Use an audit trail for edits to trip times, mileage, and signature exceptions so billing review can trace changes back to the original entry.
- Design the form with WCAG 2.1 AA accessibility in mind, including clear labels, keyboard access, and readable validation messages.
- If the manifest is used in a healthcare-adjacent workflow, avoid collecting clinical details unless they are strictly required for transport coordination.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
What's inside this template
Trip and Driver Details
This section anchors the record to a specific date, driver, vehicle, and trip reference so the manifest can be traced later.
-
Trip Date
Select the date the trip occurred.
-
Driver Name
Enter the driver completing the trip manifest.
-
Vehicle ID or Unit Number
Enter the assigned vehicle identifier used for this trip.
-
Trip Reference Number
Optional internal reference number, dispatch ID, or run number.
Passenger and Trip Routing
This section shows who was transported, where the trip started and ended, and what kind of transport was provided.
-
Passenger Identifier
Enter the passenger name or internal member ID, based on your minimum-necessary policy and billing requirements.
-
Pickup Location
Enter the pickup address, facility name, or approved location.
-
Drop-off Location
Enter the destination address, facility name, or approved location.
-
Trip Type
Select the trip routing type.
-
Mobility Assistance Type
Select all mobility or assistance types that applied during transport.
Pickup and Drop-off Times
This section captures the actual service timeline and helps confirm whether the trip was completed as scheduled.
-
Pickup Time
Enter the actual time the passenger was picked up.
-
Drop-off Time
Enter the actual time the passenger was dropped off.
-
Wait Time at Pickup or Drop-off (minutes)
Optional total wait time in minutes, if tracked for operations.
Mileage and Service Verification
This section documents the odometer trail and any exception that explains why the trip did not follow the standard path.
-
Odometer Start
Enter the vehicle odometer reading at trip start.
-
Odometer End
Enter the vehicle odometer reading at trip end.
-
Trip Miles
Enter the total miles for this trip.
-
Service Exception or Delay
Describe any delay, no-show, route change, or other exception affecting the trip.
Passenger Signature and Attestation
This section records passenger acknowledgment or a documented exception, along with the driver’s confirmation of the trip.
-
Passenger Signed the Manifest
Select whether the passenger signed to confirm the trip.
-
Passenger Signature
Capture the passenger signature when available.
-
Reason Signature Was Not Obtained
Explain why the passenger could not sign and what alternative verification was used.
-
Driver Attestation
The driver must confirm the record is accurate before submission.
Submission Notes
This section is where you capture operational context that does not fit the structured fields but still matters for review.
-
Additional Notes
Use this field for brief operational notes only.
How to use this template
- Create one form entry for each completed trip and prefill the trip date, driver name, vehicle ID, and trip reference before the ride starts.
- Capture the passenger identifier, pickup location, drop-off location, trip type, and mobility type using field types that match the data, such as select menus and location fields.
- Record pickup time, drop-off time, and wait time minutes immediately after the trip so the timestamps stay accurate and do not rely on memory later.
- Enter odometer start, odometer end, and calculated trip miles, then use the service exception field only when the trip deviates from the planned route or schedule.
- Collect the passenger signature when required, or complete the signature exception reason and driver attestation when a signature cannot be obtained.
- Review the additional notes for billing issues, no-shows, delays, or accessibility concerns before submitting the manifest to your dispatch or claims workflow.
Best practices
- Use a date picker for trip_date and numeric inputs for mileage and wait time so the manifest stays easy to validate.
- Mark only the fields you truly need as required, and keep optional fields available for exceptions and notes.
- Add conditional logic so service_exception and signature_exception_reason appear only when the trip needs them.
- Record odometer readings at the start and end of the trip instead of estimating miles after the fact.
- Keep passenger_identifier limited to the minimum necessary identifier for your workflow and avoid collecting extra PII.
- Capture the passenger signature at the point of service whenever possible, before the passenger leaves the vehicle or facility.
- Use additional_notes for operational facts only, not clinical details or unrelated personal information.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What is this NEMT Trip Manifest template used for?
This template documents a single non-emergency medical transportation trip from pickup to drop-off. It captures the trip date, driver, vehicle, passenger identifier, route, times, mileage, and signature or exception details. The goal is to create a consistent record that supports operational review and Medicaid billing support.
Is this meant for one trip or a full day of trips?
It is structured as a per-trip manifest entry, so each completed ride should have its own record. That makes it easier to reconcile mileage, timing, and passenger attestation without mixing multiple trips into one form. If your operation runs many rides per day, you can duplicate the template for each trip or group records in a daily packet.
Who should complete the manifest?
The driver or dispatcher usually fills in the trip details, times, and mileage, while the passenger signs when required. A supervisor or billing reviewer may later confirm exceptions, missing signatures, or unusual route notes. The key is to assign one owner for completion so the record does not end up partially filled by multiple people.
What should be marked as required versus optional?
Core billing fields such as trip date, passenger identifier, pickup and drop-off locations, times, mileage, and attestation should be required when applicable. Fields like additional notes and service exception details should stay optional unless a problem occurred. Use conditional logic so exception fields appear only when a trip cannot be completed normally.
How does this help with compliance and audit readiness?
A complete manifest creates a clear audit trail for who traveled, when the trip occurred, and how the mileage was calculated. It also helps you apply the minimum-necessary principle by collecting only the passenger and trip data needed for service verification. If you collect any PII, include a clear disclosure about how it will be used and retained.
What are the most common mistakes when using a trip manifest?
Common issues include missing odometer readings, using free text where a date picker or numeric input should be used, and leaving signature exceptions unexplained. Another frequent problem is recording only the pickup time without the drop-off time, which makes trip validation harder. A final pitfall is collecting extra personal details that are not needed for the trip record.
Can this template be customized for different transportation programs?
Yes. You can rename passenger fields, add conditional logic for wheelchair or stretcher transport, and adjust the service exception list to match your workflow. If your program needs stronger verification, you can add dispatcher review, vehicle assignment, or a second attestation field without changing the core trip record.
How should this integrate with billing or dispatch workflows?
This manifest works best when it feeds a billing review queue or a trip reconciliation process after the ride is completed. Many teams connect it to a spreadsheet, database, or form automation so completed trips can be checked against schedules and claims. Keep the form aligned with your downstream system so field names and trip references match.
What should we do if the passenger cannot sign?
Use the signature exception reason field to document why the signature was not captured and who verified the trip instead. The form should not force a false signature or leave the reason blank. If your policy allows it, use a driver attestation and supervisor review to close the record.
Related templates
Go deeper on the topic
-
A standard operating procedure (SOP) is a documented, step-by-step procedure for a repeatable task — the written version of "how we do this here." Good SOPs...
-
Workforce management (WFM) is the operational discipline of getting the right employees, with the right skills, in the right place, at the right time — and...
-
A daily huddle is a brief (10–15 minute) standing meeting held at the start of a shift or workday to align the team on priorities, surface issues, and...
-
A deskless worker is any employee whose job happens without a desk, a company laptop, or a fixed workstation. They're roughly 80% of the global workforce —...
-
See how the Kansas City Chiefs unified communication for 600+ event staff with a branded app, achieving 90% adoption and reaching every employee on game day.
-
A vendor-agnostic checklist covering architecture, frontline access, AI, compliance, and payroll to evaluate any scheduling platform.
-
AI employee self-service assistants cut HR and IT support time with instant answers, automated routing, and better employee experience.
-
See how customers use MangoApps Projects Module to collaborate, track progress, and share knowledge across teams.
Ready to use this template?
Get started with MangoApps and use NEMT Trip Manifest with your team — pricing built for small business.
