NEMT Patient Data Security: What One Trip Record Exposes

A non-emergency medical transportation record looks administrative. A name, an address, a time, a vehicle. That appearance is the problem. Judged against the identifier list HIPAA itself publishes, a single trip row is one of the more disclosing documents in healthcare, and it is handled at speed, in volume, by people who are looking at a whole day at once.

This isn't an argument for treating dispatch as clinical work. It is an argument for knowing exactly what is on the screen. Everything below is anchored to the text of the regulation, so you can check it rather than take it on trust.

What PHI is actually on a trip record?

The cleanest way to see it is through the de-identification standard. To strip a record under HIPAA safe harbor, 45 CFR 164.514(b)(2)(i) requires removing 18 categories of identifier. A routine trip record hits a large share of them in one row.

Note the ZIP code rule in category (B). A three-digit ZIP prefix may be retained only where the geographic unit it covers contains more than 20,000 people, and otherwise must be changed to 000. Rural transportation territory is precisely where that test fails, which is why "we only keep the ZIP" isn't a de-identification strategy in NEMT.

The billing side adds more: HCPCS mode codes and the NEMT T-codes, modifiers, ICD-10 diagnosis codes supporting medical necessity, prior authorization records, level of service, and equipment requirements. NEMT itself is a Medicaid benefit resting on 42 CFR 440.170(a) and the transportation assurance at 42 CFR 431.53, so the payer record and the trip record are joined at the hip.

Why the destination is the diagnosis

A trip record doesn't need a diagnosis code to disclose a diagnosis. The destination field does that on its own.

A methadone or opioid treatment program. A dialysis center. An oncology infusion suite. A behavioral health facility. A fertility clinic. A gender-affirming care provider. Each of those names a condition to anyone who can read a manifest, including people with no clinical training at all. Coded clinical data at least requires a code book and a reason to look. An address requires neither.

Coded clinical data needs a code book to interpret. A destination address needs nothing. That is why a dispatch screen is a higher-disclosure surface than most people assume, and why access scoping on a trip board is a real engineering problem rather than a policy sentence.

What a recurring schedule discloses

Single records disclose. Patterns disclose more. Three trips a week to the same renal facility is end-stage renal disease stated in a calendar rather than a chart. A tapering series of trips to an infusion center traces a treatment course and its progress. A standing order that stops discloses something too.

Scheduling metadata therefore carries clinical meaning that no individual row carries, which matters when deciding retention. Old trip history feels like exhaust. It is actually the most interpretable clinical record in the system, because it shows change over time.

Mobility and equipment fields are disability data

Stretcher. Bariatric. Oxygen. Wheelchair lift. Attendant or escort present. These are functional-status and disability data sitting in operational fields that dispatch staff read continuously, often as an icon or a two-letter code that makes them feel less sensitive than they are.

They also drive level-of-service billing, which means they propagate from the dispatch platform into claims, into remittance data, and into whatever spreadsheet someone built to reconcile the two. Every copy is another place the disclosure lives.

The exposure that is not financial

Most breached health data creates a financial and dignitary harm. Trip data creates a physical one. A home address paired with a predictable pickup time tells a reader where a specific person will be standing outside, alone, at a known hour, on a repeating schedule.

For survivors of domestic violence, people with protective orders, and behavioral health patients, that is a category of risk that credit monitoring doesn't address. It is worth saying plainly to any operator who is weighing how much rigor a dispatch board deserves.

The minimum necessary problem in a dispatch console

HIPAA's minimum necessary standard lives at 45 CFR 164.502(b) and 164.514(d). It asks that a workforce member access only what the task requires.

Dispatch makes that genuinely hard. The work is low-latency and visual: a dispatcher looks at a whole day's manifest to solve a routing problem, not at one member's record. The console is designed to show breadth because breadth is the job. So minimum necessary in a transportation operation isn't achieved by telling agents to look away. It is achieved by configuration:

• Queue and client scoping. An agent working one contract shouldn't be able to load another contract's board. This is the single highest-value control in a multi-client BPO and it is a permissions question, not a training question.
• Field-level suppression where the platform allows it. A router solving a geography problem needs an address. It doesn't always need a member ID, a diagnosis code, or a phone number in the same view.
• Separation of dispatch from billing views. The person sequencing vehicles and the person coding claims need different fields. Granting both to everyone is convenient and expensive.
• Export controls. Most real-world spread happens through a CSV someone pulled to work faster.

Access control and unique user identification are anchored at 45 CFR 164.312(a). Unique user identification is a required implementation specification, not an addressable one, which makes shared dispatch logins a straightforward compliance failure as well as an operational one.

When 42 CFR Part 2 sits on top of HIPAA

Records relating to the identity, diagnosis, prognosis or treatment of a patient in a federally assisted substance use disorder program fall under 42 CFR Part 2, which is stricter than HIPAA and carries its own consent regime. SAMHSA published a final rule aligning Part 2 more closely with HIPAA on February 16, 2024, effective April 16, 2024, with a compliance date roughly two years later.

A trip manifest received from, or created on behalf of, a Part 2 program can carry that status. Whether it does in your specific data flow is a legal question, and the honest answer for any operator is to have counsel look at the actual contract and the actual data path rather than reason from a blog post. What is safe to say is that a NEMT operation serving addiction treatment destinations shouldn't assume HIPAA is the ceiling.

Where trip data actually leaks

The public record is useful here. OCR publishes every breach of unsecured PHI affecting 500 or more individuals through its breach reporting tool, required by 45 CFR 164.408. The portal records the type of breach, the location of the information, and whether a business associate was involved.

The closest documented analogue to a transportation back office is Comstar, LLC, a billing vendor for emergency ambulance services. A ransomware incident reported in May 2022 affected over 585,000 individuals, and Comstar was a business associate to more than 70 covered entities at the time. OCR announced a settlement on May 30, 2025 of $75,000 with a two-year corrective action plan, and the specific failure named wasn't a firewall or an encryption gap. It was the absence of an accurate and thorough risk analysis. Massachusetts separately secured a $515,000 settlement with the same company, a reminder that state attorneys general enforce HIPAA too.

That pattern repeats. OCR's Risk Analysis Initiative, announced in late 2024, targets one requirement in particular: the risk analysis at 45 CFR 164.308(a)(1)(ii)(A). The document most operators skip is the document enforcement opens with.

Day to day, though, the leaks that reach a transportation operator are smaller and more mundane:

• Shared dispatch logins, which destroy the audit trail required by 164.312(b) and the activity review required by 164.308(a)(1)(ii)(D)
• A full-day manifest visible on an unattended screen in a shared room
• Trip details forwarded over personal email or text to move faster on a will-call
• Spreadsheets exported for reconciliation and never deleted
• Screen or call recordings retained far longer than the source records, in a system nobody assigned an owner
• Access that stays live after someone leaves, because offboarding runs on a weekly batch

None of these needs an attacker. They are habit and configuration failures, which is why they respond to configuration and review rather than to more software.

What to do about it

The controls that matter for trip data are unglamorous and checkable:

• Write the risk analysis and keep it current. Required at 164.308(a)(1)(ii)(A), and the first thing enforcement asks for. 45 CFR 164.316 requires documentation to be retained for six years and reviewed as the environment changes.
• Unique named accounts for every dispatcher and agent. Required, not addressable.
• Scope access by contract and by queue, so a multi-client operation can't become a single blast radius.
• Log access and actually review the logs. Logging is 164.312(b). Reviewing is 164.308(a)(1)(ii)(D), and it is the half that gets skipped.
• Decide retention for exports and recordings before you create them, and assign an owner to each store.
• Offboard the same day, not on the next payroll cycle.
• Sign a BAA with every vendor that touches the data, and require them to do the same with their own subcontractors under 164.308(b)(2).

This is how our own NEMT dispatch service is set up. Agents complete HIPAA training before touching client work, access is role based and logged, and the deliberate structural choice is that we work inside your dispatch and billing platforms rather than copying your trip data into a parallel system of our own. Fewer copies is the control that removes whole categories of exposure instead of managing them. We sign a Business Associate Agreement with every healthcare client before any PHI is handled, and we say plainly on our trust center that we hold no HIPAA certification, because no such certification exists.

Frequently asked questions