Most non-emergency medical transportation (NEMT) programs treat encounter reporting as a back-office problem. Something the operations team handles. Something that gets cleaned up at the end of the month.
That assumption is expensive.
States are enforcing encounter data requirements, and the penalties are landing directly on managed care organizations (MCOs) and their program partners.
Arizona's most common sanction against MCOs — more frequent than any other category of noncompliance — has been financial penalties tied specifically to data reporting errors, including one action covering over 119,000 member encounters. New York statute imposes a penalty of 1.5% of an MCO's total Medicaid premiums for untimely, incomplete, or inaccurate encounter submissions. Oregon has historically withheld 1% of capitation payments pending satisfactory encounter data. New Jersey ties encounter data violations to sanctions that can include suspension of enrollment, transfer of enrollees to another plan, or liquidated damages.
At the federal level, the exposure runs in both directions. 42 CFR 438.6 gives states the authority to withhold a percentage of capitation payments from MCOs that fail to submit timely encounter data. And states themselves aren't off the hook — under 42 CFR 438.242, if a state can't bring its encounter data submissions into compliance after CMS notification, CMS can defer or disallow federal financial participation on MCO contracts.
In Florida, the bar is even more operational: encounter acceptance rates must reach 95% or higher, with submission windows as tight as three business days and correction cycles that leave almost no margin for error.
For health plans managing NEMT programs, the exposure is real. And in most legacy models, that exposure is structural — built directly into how encounter data gets generated in the first place.
The reason most NEMT programs struggle with encounter data isn't a lack of effort. It's how the data gets assembled.
In legacy NEMT operations, encounter files are reconstructed after the trip. Trip records live in one system. Eligibility confirmation lives in another. GPS data, if it exists at all, lives somewhere else entirely. Provider and driver credentials are in yet another database. When it's time to generate an 837 encounter file, operations teams are forced to stitch all of it together manually, pulling from spreadsheets, call logs, third-party platforms, and fields that may or may not have been completed correctly at the time of service.
Every seam in that reconstruction process is a point of failure. Enrollee IDs get transposed. Provider identifiers don't match what's on file with the state's Medicaid Management Information System (MMIS). Timestamps conflict with GPS records. Service type codes are mismatched against authorization details. Each discrepancy becomes a rejected record. Each rejected record becomes a correction cycle. Each correction cycle burns operational capacity that should be managing transportation, not chasing errors.
This is the broken model that most NEMT programs are still running on: encounter reporting as damage control, not data integrity.
Meeting a 95% acceptance threshold isn't about having a strong QA process at the end of the pipeline. It requires a pipeline where the data is correct before it ever reaches the encounter file.
That means every 837 record needs validated data across the full trip lifecycle — enrollee eligibility confirmation, provider and driver identifiers, GPS-verified pickup and drop-off, service type and duration, and authorization details — all structured to meet X12 electronic data interchange (EDI) standards and state-specific MMIS edit requirements.
It also means the full EDI lifecycle needs to function end-to-end: ingesting 834 eligibility files, generating and submitting 837 encounter files, running automated error identification against both X12 and MMIS edits, managing correction and resubmission workflows, and reconciling 835 remittance data. Not as separate processes bolted together. As one integrated system.
This is an architecture problem Kinetik was built to solve.
Rather than assembling encounter data after the fact, Kinetik's closed-loop infrastructure captures and validates data at every stage of the trip lifecycle — from eligibility verification and scheduling through dispatch, real-time GPS tracking, and trip completion. By the time an 837 file is generated, every data point has already passed structured validation at each step. GPS coordinates, timestamps, provider credentials, enrollee eligibility, and authorization details are system-captured, not manually reconstructed after the trip ends.
That same closed-loop infrastructure extends directly into health plan systems. Kinetik integrates with plan-side claims environments, data warehouses, and reporting platforms, so trusted source data flows where it needs to go, in the formats each plan requires. Health plans get true program transparency, not a monthly report built from their own data by a third party.
State Medicaid agencies and their MCO partners don't just want encounter files submitted on time. They need them accurate on first submission, reflective of verified service delivery, and cleanly integrated into their systems. The programs that are meeting that standard have moved past the model of reconstructing data downstream. They're working with infrastructure where accurate encounter data is a natural output of running transportation well.
For health plans that are still relying on a third party to supply their own encounter data back to them — and absorbing the rejection rates, correction cycles, and audit exposure that come with it — the question isn't whether to change the architecture. It's how fast.
Authored by: Ari Weber