Why NEMT Matters

Why does NEMT matter?

NEMT matters because federal Medicaid rules require every state plan to ensure necessary transportation to and from providers, so a missed ride is a gap in a required benefit. For health systems and plans, reliable NEMT keeps scheduled care on time, from dialysis and therapy series to post-discharge follow-up visits.

The benefit sits outside the clinical record, but its effects show up inside it. No-shows, delayed discharges and repeat bookings can be transport problems recorded as scheduling problems.

That makes NEMT a software question as much as a policy one. Trips are booked from appointments, checked against eligibility, run by drivers with phones, and billed as claims. Each handoff is a place where a ride can fail.

What do federal Medicaid rules require?

Federal law and regulation make transportation an assured part of Medicaid and set minimum rules for drivers and brokers. These are the provisions builders and buyers should know by citation.

• Assurance: 42 CFR 431.53 requires a state plan to specify that the Medicaid agency will ensure necessary transportation for beneficiaries to and from providers, and to describe the methods it will use.
• Statute: Section 1902(a)(4)(A) of the Social Security Act (42 U.S.C. 1396a) carries the same assurance in law, including a description of the methods the agency will use.
• Scope: 42 CFR 440.170(a) defines transportation to include travel expenses needed to secure medical examinations and treatment, such as ambulance, taxicab or common carrier costs, meals and lodging en route, and an attendant when necessary.
• Brokers: Under 42 CFR 440.170(a)(4), a state may run an NEMT brokerage program. The broker must have oversight procedures to monitor beneficiary access and complaints, and is subject to regular state auditing of quality and timeliness.
• Drivers: Section 1902(a)(87), added by section 209 of the Consolidated Appropriations Act, 2021, requires a mechanism, which may include attestation, ensuring that NEMT providers and drivers are not excluded from federal health care programs and that each driver has a valid license.

The same driver provision requires each provider to have a process to address violations of state drug law and to disclose drivers' driving history to the state Medicaid program. It expressly covers transportation network companies and excludes public transit authorities.

For software teams, these provisions turn into records. The driver mechanism needs per-driver evidence with dates. Broker oversight needs complaints linked to trips. State auditing of timeliness needs scheduled and actual pickup times captured on every trip, not estimated afterward.

State contracts and plan agreements can add their own reporting and performance terms on top of the federal floor. Ask for those documents early, because they define the fields the trip record must hold.

Who carries the NEMT obligation?

The state Medicaid agency holds the legal duty, but it passes much of the daily work to others. Each party needs different software and different data.

• State Medicaid agency: Sets the method, chooses whether to use a broker or managed care plans, audits performance and enforces the driver mechanism.
• Broker: Takes trip requests, checks eligibility, assigns trips to a network of transportation providers, handles complaints and reports to the state.
• Managed care plan: Where the state includes NEMT in plan contracts, the plan arranges rides directly or through its own broker and reports on access.
• Transportation provider: Runs the vehicles and drivers, records pickup and drop-off, and bills the broker, plan or state for completed trips.
• Health system or clinic: Books rides for discharges and recurring treatment, and absorbs the cost when a patient arrives late or not at all.

Software that serves one party has to exchange data with at least two others. A provider's dispatch system that cannot read the broker's trip file forces dispatchers to re-key every trip.

What happens to care when a ride fails?

When a ride fails, the visit fails with it, and the clinical team often learns the cause only afterward. The effect depends on the kind of care.

Recurring treatment is especially exposed. Dialysis, infusion and therapy series depend on standing ride orders, and one missed trip can push the next session back or force an urgent visit.

Discharges are the second pressure point. A patient ready to leave who has no ride stays in a bed, and the unit cannot admit the next patient until the trip is arranged.

Follow-up visits after a hospital stay are the third. A care plan that depends on a seven-day or fourteen-day visit only works if the patient can reach the clinic within that window.

In each case the EHR records a no-show or a delay, not a transport failure. Linking trip status to the appointment is what turns those records into something a care team can act on.

Where do ride data and clinical data meet?

Ride data and clinical data meet at four points: the appointment, the discharge, the social needs referral and the claim. Each has an existing standard worth reusing.

• Appointment: The clinic's schedule, exposed as FHIR Appointment resources or HL7 v2 scheduling messages, is the source for trip requests and standing orders. Trip status flowing back lets staff see a late ride before the visit is marked missed.
• Discharge: An HL7 ADT discharge event or a FHIR Encounter update can trigger a ride request, so transport planning starts before the patient is waiting at the door.
• Social needs referral: The HL7 SDOH Clinical Care implementation guide covers screening, goals and referrals through ServiceRequest and Task, which suits care teams that track transport help as part of a care plan.
• Eligibility and billing: X12 270/271 confirms Medicaid eligibility before the ride, and completed trips become X12 837 claims or broker invoices, with X12 835 remittance matched back to each trip.

Trip records also link a named person to a medical destination and time. Held by a covered entity or a business associate, that is protected health information, so access controls and audit logs belong in the first release, not a later one.

Where NEMT programs lose trips

Trips are lost at handoffs between systems and people, and software can close many of those gaps. This failure-point list follows a trip from request to paid claim.

• Request: Rides are booked by phone from a separate list, so an appointment moved in the EHR leaves the ride booked for the old time.
• Standing orders: Recurring dialysis or therapy trips are re-entered by hand each week, and one missed entry means one missed session.
• Eligibility: Coverage is checked at booking but not again before the ride, so a lapsed member rides and the claim is denied weeks later.
• Vehicle match: The trip record lacks mobility needs, so an ambulatory car arrives for a patient who needs a wheelchair van or stretcher.
• Driver credentials: License and exclusion checks live in a spreadsheet, and the state's driver mechanism cannot be shown on audit.
• Proof of service: The driver app needs a constant signal, so pickup and drop-off times are missing for rural trips.
• Complaints: Rider complaints arrive by phone and email and are never linked to the trip, so the broker cannot show the oversight 42 CFR 440.170(a)(4) expects.
• Feedback to care teams: Trip outcomes never reach the clinic, so the same patient misses the next visit for the same reason.

What to settle before building NEMT software

Settle whose workflow the software serves and which outside systems it must exchange with before choosing features. The decisions below shape the data model and the integrations more than the screens.

• 1. Role: Decide whether you are a provider, broker, plan or health system, because each role owns different records and reports.
• 2. Trip record: Define one trip record that carries the appointment link, mobility needs, eligibility result, driver, timestamps and claim status.
• 3. Exchange partners: List every broker file format, payer, EHR and state portal the system must read or write, with a test file from each.
• 4. Driver compliance: Store license, exclusion screening and driving-history disclosures per driver, with dates, so the state mechanism is auditable.
• 5. Privacy: Treat trip data as PHI where HIPAA applies, with role-based access, audit logs and business associate agreements with hosting and messaging vendors.
• 6. Reporting: Generate timeliness, complaint and access reports from the trip record itself, so the numbers sent to the state match the trips that ran.
• 7. Build or buy: Compare packaged products against your trip record and exchange list before deciding to build.

How Agnotic can help

Getting patients to care on time takes software that links rides to appointments, eligibility and claims. Agnotic Technologies builds that software for NEMT providers, brokers, health plans and health systems, or extends a packaged product where one already fits.

Agnotic maps one trip from request to paid claim, builds the dispatch, driver and broker connectors, adds X12 eligibility and claim flows, and links trip status back to the EHR so care teams can act before a visit is missed.

Sources

• 42 CFR 431.53: Assurance of transportation
• 42 CFR 440.170: Transportation and NEMT brokerage programs
• 42 U.S.C. 1396a: State plans, paragraphs (a)(4)(A) and (a)(87)
• CMS Informational Bulletin: NEMT provider and driver requirements (12 July 2021)
• HL7: SDOH Clinical Care implementation guide
• HL7 FHIR R4: Appointment
• 45 CFR Part 164 Subpart C: HIPAA Security Rule