What an EVV aggregator is, and where your visit data goes

Picture the problem from a state Medicaid agency's side. Several thousand providers deliver home visits. Some use a state-provided system, some use their own software, some use whatever their managed care plan gave them. The state has to confirm that the visits it is paying for actually happened, in a consistent format, across all of them.

An aggregator is the answer to that. It is a central system that receives verified visit records from every source, normalizes them into one format, stores them, and makes them available for checking against claims.

The word describes a role rather than a product. The same company can be a state's aggregator and also sell an EVV system that providers use directly, which is a large part of why this gets confusing.

Following a single visit from a client's living room to a paid claim makes the whole picture clearer.

1. Capture. A caregiver checks in and out. The six required data elements are recorded: service, client, caregiver, date, location, and start and end times.
2. Transmission. That record reaches the state's aggregator. If you use the state system directly, it is already there. If you use a third-party system, it is sent through an integration.
3. Validation. The aggregator checks the record is complete and well formed. Records failing validation come back as exceptions to fix.
4. Claim submission. Separately, a claim for the service is submitted for payment.
5. Matching. The claim is checked against verified visits held by the aggregator. A claim with a matching visit proceeds. One without may be denied, pended or paid and recouped later.

Step five is where an abstract compliance requirement turns into money not arriving.

Most EVV payment problems are not caused by visits going unrecorded. They are caused by a visit record and a claim that do not line up, and the causes are mundane.

• A visit captured under a slightly different service code from the one billed
• A caregiver identifier in your system that does not match the one the state holds
• A visit that never transmitted because an integration silently failed
• A visit sitting unresolved in an exception queue while the claim went out anyway
• Times that disagree because a correction was made after the claim was submitted

The practical consequence for how you run the office: unresolved visits are not an administrative tidiness problem, they are an unpaid claim waiting to happen. Clearing them before claims go out is worth more than clearing them at all.

Three terms get used interchangeably and mean different things. Being able to tell them apart makes vendor conversations much easier.

An EVV system is what captures the visit. The app on the caregiver's phone, the telephony line, the fixed device.

A provider portal is where your office works: scheduling, viewing visits, fixing exceptions, submitting claims. The state's free offering is usually a system and a portal together.

An aggregator is the state's central collection point. You may never log into it directly.

One company frequently plays several of these roles at once. When a vendor says they are "the state EVV system," it is worth asking which of the three they mean, because being the aggregator and being a system you can choose are very different things.

If you are in an open vendor state and you want to use your own software, integration is what connects it to the aggregator. It generally involves:

• Registering your intention with the state or its vendor, often through a form declaring which third-party system you will use
• Your vendor building to a published technical specification, if they have not already
• A testing phase where sample visits are sent and validated before you go live
• Keeping an account in the state system regardless, because that is usually where authorizations arrive and where problems surface

The two questions that matter when a vendor tells you they integrate with your state: are they already live there with other agencies, and how long does onboarding take. "We support integration" can mean they have done it many times, or that they would be willing to try.

Transmission failures are the quiet problem in EVV. A visit that never reaches the aggregator does not announce itself. The caregiver checked in, the app looked fine, the office saw the visit, and the record simply never made the last hop. You find out weeks later when a claim is denied.

The causes are usually one of four things:

• The visit is still on a phone. Captured offline and never synced, because the device was replaced, the app was removed, or the caregiver never regained coverage while the app was open.
• The visit failed validation and nobody looked. The aggregator rejected it for a missing or malformed field and the rejection sat in a queue.
• The integration broke. A credential expired or a specification changed, and transmission stopped for everything, not just one visit.
• The record was corrected after transmission. The original went through, the correction did not, and now the two systems disagree.

What protects you is not avoiding failures, which is impossible, but noticing them quickly. Two habits do most of the work. Reconcile before you bill, by checking that the visits you are about to claim for are actually present in the state system rather than only in yours. And treat a sudden drop in transmitted visits as an outage rather than a quiet week, because a broken integration looks exactly like a quiet week until the claims come back.

Of your state agency or managed care plan:

• Which system is the aggregator for the programs I bill?
• Do I need an account in it even if I use another system?
• What happens to a claim when a visit fails validation or arrives late?
• How do I see which of my visits failed to transmit?

Of any EVV vendor:

• Are you live with the aggregator in my state today?
• How many agencies in my state are using that integration?
• How will I know if a visit fails to reach the aggregator, and how quickly?
• What does it cost, including any integration or setup fee?

That last one is worth asking directly. Some vendors charge separately for the integration that makes their product usable in your state, and it is better to learn that before you sign.