Setting user roles in NEMT software: who should see and change what

Start from the job, not the person

Set up access by asking what each job needs to get done, then give every person the role for their job and nothing extra. Security people call this least privilege. In a small NEMT office it mostly prevents ordinary mistakes: a new dispatcher who can edit payer rates, a biller who can change a completed trip’s mileage, a driver whose phone shows every rider’s address for the day.

HIPAA points the same way. Under 45 CFR 164.514(d)(2), a covered entity has to identify the people or groups in its workforce who need access to protected health information, name the categories of information each one needs, and make reasonable efforts to hold access to that. The Security Rule adds policies for authorizing access (45 CFR 164.308(a)(4)) and systems that let in only people granted access rights (45 CFR 164.312(a)(1)).

Two details matter for NEMT. The minimum necessary standard does not apply to disclosures to a health care provider for treatment or to the rider themselves (45 CFR 164.502(b)(2)). It does apply to how your own staff use rider information, which is exactly what roles control. For the wider HIPAA picture, see HIPAA for NEMT providers.

A role-by-role access table

The table uses seven roles. Rename them to fit your office, but keep the boundaries.

Two boundaries do most of the work.

Separate the people who record a trip from the people who bill it. A biller who can edit trip times and miles can make a claim match anything, and a dispatcher who can edit invoices can hide a missing payment. Keeping those duties apart is one of the simplest fraud controls a small company has, and it protects honest staff when a payer questions a claim.

Scope drivers to their own work. A driver’s phone leaves the office every day, rides in a van, and sometimes gets left on a seat. The fewer riders it can show, the smaller any loss. The driver phone guide covers the device side.

Rules for every account

These apply whatever the role:

1. One person, one login. Unique user identification is a required Security Rule safeguard (45 CFR 164.312(a)(2)(i)). A shared “dispatch” account turns the activity history into a list of changes nobody made.
2. Strong sign-in. The Security Rule requires a way to confirm each sign-in really comes from the account owner (45 CFR 164.312(d)). Two-step codes or passkeys do this far better than a password taped to a monitor. The cybersecurity guide compares the options.
3. Automatic sign-out on shared computers. Ending a session after a set idle time is an addressable safeguard (45 CFR 164.312(a)(2)(iii)). It matters most on the dispatch desk that three people use across a day.
4. An activity history you actually read. The Security Rule calls for audit controls that log what happens in systems with health information (45 CFR 164.312(b)), and someone must regularly review those records (45 CFR 164.308(a)(1)(ii)(D)).
5. An emergency access plan. The Security Rule requires a way to reach needed information in an emergency (45 CFR 164.312(a)(2)(ii)). Keep two owner-level accounts in different hands.
6. Temporary access that ends. When a dispatcher covers billing during a vacation, add billing access for those dates and take it off on the return date. Access that was meant to be temporary is the kind that lingers for years.

Granting access to new staff

Put the same four steps behind every new account:

1. The manager asks for a named role, in writing or in a message that is kept.
2. The owner or administrator approves it and creates the account.
3. The new person signs in with their own credentials and sets up two-step sign-in on day one.
4. The approval, the role, and the date go into a simple access log.

The Security Rule’s access authorization and access establishment specifications (45 CFR 164.308(a)(4)(ii)(B) and (C)) call for exactly this: a documented way to grant, review, and change each user’s access.

Job changes need the same care. When a dispatcher moves to billing, switch the role rather than adding a second one. Stacked roles are how a three-year employee ends up able to do everything. When hiring a dispatcher, decide the role before the first day so the account is ready and limited from the start.

Removing access the day someone leaves

End access on the last day, before the person leaves the building if you can. The HHS Office for Civil Rights published a termination checklist in its November 2017 cybersecurity newsletter. Its main steps, applied to an NEMT office:

• Work from a standard exit checklist so nothing depends on memory.
• Disable or delete every user account as soon as possible.
• Take back company phones, laptops, keys, badges, and fuel cards.
• If the person used a personal phone for work, remove work data and app access from it.
• Close remote access and accounts on outside services, which for NEMT means broker portals, the state Medicaid portal, shared drives, and email.
• Change passwords to any administrator or shared accounts the person knew, including gate codes and voicemail PINs.
• Keep a log of what access was granted and when it was removed.

Broker and Medicaid portals are the step most often missed, because each one keeps its own user list outside your software. List every outside login a role uses, and remove the person from each.

The cost of skipping this step is on the record. In February 2017, Memorial Healthcare System paid HHS $5.5 million to settle potential HIPAA violations. The login of a former employee at an affiliated physician’s office had been used daily, without detection, from April 2011 to April 2012 to reach the electronic records of 80,000 people. HHS said the health system had access policies but failed to implement procedures for reviewing, modifying, or terminating users’ access, and did not regularly review system activity records.

A tighter deadline may come. HHS’s proposed Security Rule update, published January 6, 2025, would require ending a departing workforce member’s access no later than one hour after the job ends, and notifying other covered entities or business associates within 24 hours when a person’s access to their systems changes. As of September 30, 2026, the Federal Register lists it as a proposed rule with no final rule issued. Same-day removal is the sensible standard either way.

Reviewing access on a schedule

A quarterly review catches what the daily routine misses. For a small company it is a short checklist:

1. Export the list of active users and their roles.
2. Compare it with the current staff roster and each facility’s current contacts. Disable anyone not on either.
3. Check that each role still matches the person’s job.
4. Look for accounts nobody has used in 30 days or more. The 2017 HHS newsletter suggests alerts for accounts idle past a set number of days.
5. Count the administrators. More than two is usually too many.
6. Scan the activity history for patterns that do not fit a job, such as a driver account opening trips for other drivers, bulk exports, or sign-ins at odd hours.
7. Record the date, who reviewed, and what changed.

Keep that record. HIPAA requires a written record of required activities, and 45 CFR 164.316(b)(2)(i) sets the retention period at six years, counted from when the record was made or last in effect, whichever comes later.

Facility and outside users

Facilities that book rides through your system are outside users, and they need the same discipline. Give each nurse, social worker, or scheduler their own account rather than one login for the nursing station. Limit each account to that facility’s residents. Ask each facility to tell you when a staff member leaves, and include facility contacts in your quarterly review.

The same goes for outside helpers such as a billing service or an accountant. Give them a role cut to what they do, with an end date if the work is short term, and remove it when the engagement ends.

Roles and access in HealthRide

HealthRide lets you create accounts for dispatchers, secretaries, billers, and everyone else on your team, and each role sees what the job needs and nothing more. A full activity history lists each change and who made it, and sign-ins can use passkeys or two-step codes. See the provider portal for how team accounts work.