Electronic visit verification was sold to agencies as a compliance obligation, which it is. What nobody put in the budget was the standing job it creates. The mandate under the 21st Century Cures Act requires six data elements on every visit: the service performed, the person receiving it, the person providing it, the date, the location, and the time the visit begins and ends. Capturing those six elements is the easy half.
The other half is what happens when one of them does not capture cleanly, which is a normal Tuesday and not an edge case.
Where Exceptions Come From
An exception is any visit the system cannot verify without a human looking at it. The recurring sources are boring and predictable:
- No signal at the home. Rural addresses, basement apartments and concrete-frame buildings produce visits captured offline or by telephony fallback. Both need reconciling later.
- GPS drift. Someone clocks in from the driveway or the lobby and the coordinates land outside the geofence. The visit happened. The record says it might not have.
- The device in the field. Dead battery, an app that needs an update, a device that was replaced last week, a new hire who has not logged in yet.
- Clock-out that never happened. The single most common one. The visit ends, the person leaves, and nobody closes the record until an alert fires.
- Schedule drift. The visit ran long, or short, or it went to a different client than the one on the schedule. All three are legitimate. All three read as variance.
- Aggregator rejections. In states with a mandated aggregator, a visit can be captured perfectly and still be rejected downstream on a formatting or matching rule that has nothing to do with care.
How to Size It Before It Sizes You
Two numbers tell you almost everything, and both can be pulled this week.
Exceptions per hundred visits. Take one full week, count total verified visits, count how many required a human to touch them, and express it per hundred. That is your exception rate. Most agencies who measure it for the first time are surprised by it, and the direction of the surprise is never downward.
Minutes per exception. Time ten of them honestly, including the phone call to the field to ask what happened. Include the ones that require the supervisor, because those are the expensive ones.
Multiply the two and you have the weekly cost of EVV in hours. That is the number to compare against any change you are considering, and it is the number to give the person who asks why one coordinator does nothing else.
Categorise Before You Fix
Do not attack the queue. Attack the categories. Tag every exception with a reason code you control, keep the list short, six or seven at most, and look at the distribution after two weeks. The distribution almost always shows one or two categories carrying the majority, and they usually have different fixes:
- Signal and geofence problems are a configuration fix, not a training fix. Widen the geofence to something defensible, and set up telephony fallback for the addresses that need it before anyone discovers they need it.
- Missed clock-outs are a prompting fix. An alert that fires at the scheduled end time, to the field first and the coordinator second, removes most of them.
- Device and login problems are an onboarding fix. Every one of them traces to a first shift that started before the app was working.
- Aggregator rejections are a data fix upstream. The mismatch is usually a member ID, a service code or a date that was wrong in the schedule before the visit ever happened.
the Part That Becomes a Denial
Here is the connection most agencies find late. An unresolved EVV exception does not stay an EVV problem. It becomes a claim that does not match the visit record the payer already holds, and it comes back as a denial weeks later, at which point nobody remembers that Tuesday, including the person who was there.
The operational rule that follows is simple to state and unpopular to implement: close the exception queue before the billing run, not after it. An exception resolved on the day costs a phone call. The same exception resolved after a denial costs a rebill, a follow-up and a cash flow gap.
What to Ask a Vendor
If you are looking at EVV software, or at a platform that includes it, the demo questions that matter are not about clock-in.
- 1.Show me the exception queue, not the visit list.
- 2.Can I define my own exception reason codes, and can I report on them?
- 3.What fires automatically when a visit has no clock-out, and to whom?
- 4.Does a visit with an open exception block the claim, or does it flow through and come back as a denial?
- 5.If my state uses an aggregator, what happens to a rejection, and who sees it?
Question four is the one that separates products. A system that lets an unverified visit reach a claim is not saving you the work. It is deferring the work into a more expensive month.
the Short Version
EVV verifies visits. It does not verify itself. Budget for the exception queue, measure it in hours rather than in feelings, categorise before you fix, and never let an open exception reach a claim. The agencies that treat EVV as a daily operational queue rather than a compliance checkbox are the ones whose denial rate does not quietly climb over a year.