EVV Compliance Reporting

Part of the Anaya Care Handbook — the source of truth for how the product must behave. When the product needs to change, change this document first, then make the system match it.

Implementation status — this module is specified but not yet built. Every rule below is 🚧 Spec only until the feature ships and this page is audited against the code. Legend: ✅ In code · ⚠️ Partial · 🚧 Spec only (not yet built).

What this covers

This page governs Electronic Visit Verification (EVV) compliance reporting: the future work of reporting visit data to state EVV aggregators so that Medicaid-funded care delivered through Anaya is verifiable. The six federally required EVV data points are already captured by the platform today through everyday scheduling and clock-in/out; what remains to be built is not data capture but the per-state aggregator integrations and the reporting pipeline that submit that data outward.

Key terms

EVV (Electronic Visit Verification) — a federally mandated system for electronically verifying that a Medicaid-funded home-care visit actually happened, by recording who delivered what care, where, and when.
EVV data point — one of the six pieces of information federal law requires every verified visit to record: type of service, client receiving service, visit date, location, care provider providing service, and visit start/end time.
EVV aggregator — a state-designated system that receives and validates EVV records from providers. Requirements and the chosen aggregator vary by state.
Reporting pipeline — the future internal process that assembles captured visit data into the format each aggregator requires and submits it.
Medicaid-funded subscriber — a subscribing company (or its clients) whose care is reimbursed through Medicaid, the only case in which EVV reporting applies.

How it works

The platform already records everything an EVV visit must prove. Each of the six federally required data points is produced today as part of normal care delivery: the type of service comes from the care plan and daily task list for the visit, the client receiving service from the client profile linked to the shift, the care provider providing service from the logged-in identity of the care provider on the shift, and the date, location, and start and end time from the GPS-verified clock-in and clock-out recorded during the shift (see Scheduling & Shifts). No new capture step is needed.

The future work sits downstream of that capture. EVV is regulated state by state, and each state designates its own aggregator with its own submission format and rules. The platform must therefore build a per-state integration for each state it operates in, plus a reporting pipeline that gathers the captured data points for each completed visit, formats them for the relevant state, and submits them. This applies only where care is Medicaid-funded; private-pay and non-Medicaid subscribers are out of scope. The outbound integrations are expected to be delivered alongside the platform's broader integration surface (see the not-yet-built Integrations & API page).

Rules

EVV-1 — The platform must, for every completed visit, hold all six federally required EVV data points: service type, client identity, visit date, visit location, care provider identity, and visit start/end time. (🚧 Spec only)
EVV-2 — The service type and client identity must be taken from the visit's scheduled service and assigned client, not re-entered for EVV. (🚧 Spec only)
EVV-3 — The care provider identity and visit date must be taken from the shift assignment. (🚧 Spec only)
EVV-4 — The visit location and start/end time must come from the GPS-verified clock-in and clock-out recorded during the shift (see Scheduling & Shifts); EVV must not introduce a separate capture of these. (🚧 Spec only)
EVV-5 — The platform must provide a per-state EVV aggregator integration for each state in which it submits EVV data, since aggregators and submission requirements differ by state. (🚧 Spec only)
EVV-6 — The platform must provide a reporting pipeline that assembles each completed visit's six data points, formats them for the relevant state's aggregator, and submits them. (🚧 Spec only)
EVV-7 — EVV reporting must apply only to Medicaid-funded subscribers; visits that are not Medicaid-funded must not be submitted to any aggregator. (🚧 Spec only)
EVV-8 — EVV aggregator integrations must be delivered as part of the platform's outbound integration surface (see Integrations & API), not as bespoke one-off exports. (🚧 Spec only)
EVV-9 — Agencies remain responsible for their own state EVV compliance; the platform provides the data capture and submission infrastructure, but it does not assume or replace each agency's obligation to meet its state's EVV requirements. (🚧 Spec only)

Who can do what

EVV reporting is an automated back-office function, not a per-user action; it operates at the operations/compliance level and exposes no care-provider- or representative-facing controls.

Decisions needed

Which states must be supported first? The PRD names no states. Options: scope to the states of the first Medicaid-funded subscribers and add others on demand; pre-build for the largest-population states; defer until a Medicaid subscriber is signed.
Which aggregators must be integrated? The PRD does not name specific aggregators or vendors. Options: integrate directly with each state's designated aggregator; integrate via a single aggregator-of-aggregators vendor that fans out to states; a mix per state.
Is EVV certification required, and who owns it? The PRD does not address whether Anaya must be certified by each state or aggregator before submitting. Options: pursue certification per state before go-live; rely on a certified intermediary; treat as a per-subscriber onboarding step.
How are corrections and rejected submissions handled? The PRD does not cover resubmission. Options: automatic retry on rejection; a manual compliance queue; defer until first integration is built.