Health Plan NEMT Software: Proving Your Transportation Benefit Actually Works

A health plan offers its members a ride to the doctor. Good benefit, real need. Then the actuary asks the question that matters now: did it improve anyone’s health, and can we show it? And the honest answer, for most plans, is that the data to answer it does not exist in one place. The rides happened. The proof did not get captured.

That gap used to be tolerable. It is not anymore. The rules have shifted from offering a benefit to evidencing it, and the plans that cannot connect a ride to an outcome are the ones who will struggle to justify the benefit at all.

I am the CMTO at Mindbowser, and the work I care about most is where clinical outcomes meet the systems that have to capture them. Transportation is one of the cleanest examples right now: a benefit that obviously helps, that plans increasingly have to defend with data, and where the software most plans run was never built to produce that data. This is a walk through what the rules now require, why it is a software problem, and what a plan-side build actually has to do.

The transportation benefit plans offer, and the gap underneath it

Start with where the benefit stands, because it is moving. In 2026, a medical transportation benefit was available to 22% of individual Medicare Advantage enrollees, down from 28% in 2025, and to 73% of SNP enrollees, per KFF’s June 2026 analysis. Non-medical transportation, offered as a Special Supplemental Benefit for the Chronically Ill, sat at 5% of individual plans and 36% of SNPs.

Two things stand out in those numbers. The benefit is widespread, especially in the SNP world where the membership is sickest and the need for reliable transportation to care is highest. And on the individual side it is contracting, which is what happens when plans cannot defend a benefit’s cost with evidence of its value. A benefit you cannot measure is a benefit you cut when margins tighten.

The gap underneath the benefit is the data. A plan knows it paid for rides. What it usually cannot show is which members used them, whether those members made their appointments, and whether the benefit changed anything about their care or their cost. That is not a reporting inconvenience. Under the current rules, it is an existential question for the benefit.

What CMS now requires you to prove

The CY2025 Medicare Advantage final rule, CMS-4205-F, with provisions taking effect into 2026, changed the standard for supplemental benefits. Two requirements matter most for transportation.

First, the evidence standard. For Special Supplemental Benefits for the Chronically Ill, a plan must maintain a bibliography of high-quality clinical research, published within ten years of the coverage year, showing the benefit has a reasonable expectation of improving or maintaining the health or overall function of the chronically ill enrollees who receive it. You can read the framing in the CMS-4205-F fact sheet. In plain terms, offering a transportation benefit on the belief that it helps is no longer enough. You have to be able to point to the evidence, and increasingly to your own.

Second, the mid-year notice. Beginning January 1, 2026, plans must send each enrollee with unused supplemental benefits a mid-year notification, no sooner than June 30 and no later than July 31, listing the benefits they have not used. For a transportation benefit, that means you have to know, member by member, mid-year, who has and has not used their rides. That is a live utilization-tracking requirement, not an annual report you assemble after the fact.

Put the two together and the message is clear. You must evidence that the benefit works, and you must track its use closely enough to nudge members who are leaving it on the table. Both are data capabilities, and most plans do not have them wired together.

Why this is a software problem, not a policy memo

It is tempting to treat the new requirements as a compliance task, something the regulatory team handles with a binder. But the binder cannot answer the actuary’s question, and it cannot generate the mid-year notice. The requirements decompose into four data capabilities, and every one of them is software.

You need eligibility logic that knows which members qualify for the benefit and under what rules, because SSBCI eligibility is narrower than the general membership. You need utilization tracking that sees each ride as it happens, not in a quarterly broker file, so the mid-year unused-benefit notice is accurate. You need outcome and encounter capture that connects a ride to what it enabled, the appointment kept, the gap in care closed, so the benefit can be tied to a measurable result. And you need member engagement, the reminders and the booking experience, that turns an offered benefit into a used one.

None of those is a transportation feature. They are health-plan data features, and they have to share a spine. The reason this lands as a custom build for serious plans is that the off-the-shelf tools own pieces of it, the broker owns the rides, the benefit-admin system owns eligibility, the analytics team owns outcomes, and nothing connects them into the single thread that proves the benefit worked. The same outcome-capture discipline that runs quality tracking under value-based care is exactly what a transportation benefit now needs, applied to rides.

The managed-care plumbing most vendors skip

Here is where precision separates a real plan-side build from a generic one. Transportation in managed care is structured in specific ways, and the structure changes how the benefit is administered and reported.

A plan may deliver NEMT through a prepaid ambulatory health plan arrangement, a NEMT-PAHP, where a separate entity is paid a capitated amount to manage the transportation benefit. NEMT-only PAHPs sit under a distinct medical loss ratio treatment, which affects how transportation dollars are accounted for against the MLR. And transportation can be offered as an in-lieu-of-service under the managed-care rules at 42 CFR 438.3(e)(2), which is a different mechanism again, with its own documentation and reporting expectations. The downstream Medicaid NEMT billing reflects each of these structures differently, which is part of why a generic line-item view misreports the benefit.

I am not raising these to show off the citations. I am raising them because a plan-side transportation build that does not model the actual contractual and regulatory structure of the benefit will produce numbers that do not reconcile with how the benefit is paid and reported. The software has to match the plumbing. A tool that treats every transportation benefit as the same generic line item will misreport it, and misreporting a benefit you are now required to evidence is the opposite of what this is for.

Connecting the benefit to outcomes data

The hardest and most valuable part is the outcome thread. Proving the benefit improved health means connecting a ride to something clinical, and that connection lives in systems the transportation vendor never touches.

A ride to a dialysis appointment is a logistics event to the broker. To the plan, it should be an encounter: this member, this date, this destination, this appointment kept, this gap in care closed. When that ride links to the member’s clinical record and care-management workflow, the benefit stops being a cost line and becomes outcomes data you can put in front of an actuary or a regulator. And that is precisely the link that makes the evidence requirement satisfiable with your own data instead of borrowed literature.

This is where transportation and clinical integration meet. When the transport event can flow into the member’s record, through the same kind of EHR-connected transport data that turns a ride into a structured clinical event, the plan can finally answer whether the benefit changed care. Without that link, you are left counting rides, and a ride count is not an outcome. The plans that build this thread are the ones who will defend their transportation benefit with evidence while others cut theirs for lack of it.

What off-the-shelf benefit administration can’t do

There are capable benefit-administration platforms and capable transportation brokers. Neither was built for what CMS-4205-F now asks of a plan.

Benefit-admin tools are built to determine eligibility and pay claims. They are not built to capture whether a benefit improved health, because that was never the job. Broker platforms are built to dispatch and reconcile rides. They are not built to feed a member’s clinical outcome thread, because they do not see it. And the analytics layer that could connect them is usually assembling data after the fact, quarterly, from files, which cannot support a mid-year unused-benefit notice or a live view of who is using the benefit.

The gap is not in any one tool. It is in the seam between them, the place where eligibility, utilization, outcomes, and engagement have to become one continuous record of a benefit doing its job. Closing that seam is the build, and it is why a plan serious about defending its transportation benefit ends up wanting custom NEMT software development on the plan side, not another point tool.

How Mindbowser approaches a plan-side build

We build the connective layer that makes a transportation benefit provable. In practice that means eligibility logic that encodes the actual SSBCI and managed-care rules, utilization tracking that sees rides in near real time to support the mid-year notice, outcome and encounter capture that links a ride to the care it enabled, and member-engagement flows that lift utilization so the benefit gets used. The thread, not another silo.

Let me be straight about proof, because this is a space where vendors promise outcomes freely. Our differentiator is the engineering to connect clinical, eligibility, and utilization data into one defensible record, demonstrated across our healthcare integration and outcomes work. I am not going to attach a borrowed improvement statistic to a transportation benefit and call it ours. When we ship a plan-side build with its own measured result, that number will live here. Until then, the capability is the claim, and for a plan that now has to evidence its benefits, it is the capability that matters.

The plans I talk to are not asking how to offer transportation. They already do. They are asking how to prove it was worth offering, and how to keep it from being the benefit that gets cut in the next bid because no one could defend it. That is a data and software question, and it is the one this build answers.