EVV-Compliant Home Care Software Development: The Cures Act Mandate, State Aggregators, and Alt-EVV Integration

A Medicaid home care visit that can’t be matched to a verified electronic record is unpaid work. Through 2025 that mostly meant a warning letter; in 2026 it means a denial. EVV software development now sits on the payment path. Missouri denies claims with no matching verified visit for dates of service from April 1, 2026, and the first missed payment landed on the April 24 check.

Wisconsin tells providers that certifying an alternate EVV system and connecting it to the state aggregator can take up to 3 months.

In Colorado’s self-direction program, a low match rate lands on the Medicaid member: it can end their enrollment.

The federal requirement underneath all three of those is small and fixed. What costs you is the 50-plus state implementations stacked on top of it, each one with its own aggregator, certification calendar, enforcement date, and correction window. Whether you’re building the platform or shopping for one, that state layer is where the money goes.

What does building an EVV-compliant home care platform involve?

The federal ask is small: six data elements on every Medicaid-funded in-home visit, under Section 12006(a) of the Cures Act. Everything expensive comes from the states, which run 5 models and certify against their own aggregator specs on their own calendars. Two things decide whether a visit gets paid: per-state aggregator certification, which Wisconsin puts at up to 3 months, and the exception workflow standing between a verified visit and a paid claim.

Key Takeaways:

1. Six data elements are federal. Everything else in your scope comes from the launch states you pick. The model a state runs decides who picks the EVV system and who pays for it.
2. Build the exception queue before anything else, because it decides what you get paid. A visit that doesn’t auto-verify is unpaid work until someone clears it, and Texas closes the correction window at 95 days.
3. Certification sets your earliest revenue date in every state you enter. It repeats per state, and Connecticut repeats it again per provider Medicaid ID.

Table of Contents

1. The Cures Act asks for six data elements; your state decides everything else
2. The 5 state models, and why “EVV integration” means 50 different things
3. Alt-EVV certification is per state, per spec, and it takes months
4. Designing capture for homes you don’t control: GPS, IVR, and FVV
5. Exception handling and visit maintenance: where agency revenue is won or lost
6. Three records have to agree before a claim pays: EVV matching and hard edits at the aggregator
7. Consumer-directed care is a different product: family caregivers and fiscal intermediaries
8. Beyond verification: the modules that decide whether a visit is billable
9. Location data, caregiver trust, and where HIPAA stops helping you
10. Before you commit to a state: the EVV launch diligence checklist
11. Why Topflight Apps for EVV platform builds

The Cures Act asks for six data elements; your state decides everything else

EVV electronically confirms that a Medicaid-funded in-home visit happened and captures six data elements about it, required under Section 12006(a) of the 21st Century Cures Act. The scope stops at attendance. Vitals and clinical documentation belong to a different system.

The federal ask is a data contract, and the states own the design

Two service categories fall inside it, both on clocks that have already run out. Personal care services (PCS) came under the requirement on January 1, 2020, and home health care services (HHCS) followed on January 1, 2023, covering services delivered under Medicaid state plan and waiver authorities. The Program of All-Inclusive Care for the Elderly sits outside it.

CMS’s EVV guidance names six data elements per visit:

• type of service performed
• the individual receiving the service
• the individual providing the service
• date of service
• location of service delivery
• the time service begins and ends

That’s the whole federal ask, and nothing in it is architecture. The guidance names no vendor and no capture method. Operational control sits with the states.

The decisions that cost money all got delegated: whether a caregiver clocks in on a phone or a landline, which system the data lands in, who pays for it, and what happens when a visit doesn’t match. Everything an electronic visit verification app has to do past capturing those six data elements comes from somewhere other than CMS.

Your state keeps tightening because it’s losing money too

Miss a deadline and the state’s own check shrinks, every quarter, for as long as it stays out of compliance. The FMAP reduction is graduated: 0.75 percentage points off HHCS through 2026, a full point from 2027, applied against each quarter’s expenditures in the non-compliant category. PCS hit its full point back in 2023.

Two categories, two clocks. A state can be clean on one and losing money on the other.

CMS publishes the determinations, so the list is public. 7 states were determined non-compliant on HHCS as of January 1, 2024: Arkansas, Georgia, Massachusetts, Michigan, Mississippi, North Dakota, and South Carolina.

A state bleeding federal match every quarter pushes the requirement downhill, and the only lever it has is your claim. That mechanism is behind every state-level rule you’ll build to: the fields you’re forbidden to edit, the score you get measured on, the payroll run that doubles as a compliance deadline, and the exception queue that decides whether a visit turns into money.

The 5 state models, and why “EVV integration” means 50 different things

Scope here is set one state program at a time. Line up 5 launch states and you’ve lined up 5 separate integrations, because CMS left each state to decide who runs EVV, who pays for it, and where your visit data has to land.

The six data elements are identical in every row. Everything else, who owns the decision and who absorbs the cost, changes.

One state can still mean several integrations

One row per state holds until a state runs two answers at once.

North Carolina runs Sandata as the state aggregator for its Direct services, while the managed care entities and most prepaid health plans put their networks on HHAeXchange, which reports plan visit data into Sandata. Which payer the member sits under decides which system you feed, so one state license can mean two EVV integration targets.

That reorders your diligence. In a state-mandated model the first question is whether you’re allowed in at all, and only after that does the aggregator matter.

Aggregator assignments are contracts, and contracts end

An aggregator assignment is a procurement outcome with an end date.

Arizona let its Sandata contract expire on September 30, 2025 and became its own aggregator the next day. Every EVV vendor had to complete testing with the state before submitting again, even though the technical specifications didn’t change.

Michigan makes alternates work with the state platform’s data interchange process at their own cost. Pick launch states deliberately, then build the data model to the superset of aggregator field requirements you expect to face. Multi-tenant architecture here has to key on the state program as well as the agency, because each state program carries its own field spec and its own re-test cycle, and the re-test is the part you can schedule.

Alt-EVV certification is per state, per spec, and it takes months

Certification eats the schedule. Alt-EVV, meaning you run your own system instead of the state’s, requires you to clear each state’s aggregator certification before a single visit counts.

Certifying against an aggregator runs 6 gates before production

The states that publish their process describe roughly the same sequence:

1. You register as a vendor in that state’s aggregator portal.
2. The aggregator issues test credentials to the provider agency.
3. You transmit test visits built to the aggregator’s published Open EVV / Alt-EVV specification, working through its testing checklist.
4. The aggregator reviews your test files against the Cures Act data requirements.
5. You generate production credentials.
6. The provider agency completes aggregator training before it gets production access.

Every gate on that list is someone else’s queue. The interface itself is a published file format. The gates around it run on the aggregator’s calendar. The provider carries the cost. Certification months rarely show up in a healthcare app development cost estimate, and they should.

Arizona says its aggregator validates technical format only; policy compliance stays the provider’s.

Count the counterparties before you scope: Sandata, HHAeXchange, Netsmart’s Tellus platform, AuthentiCare, CareBridge, Therap, and state-built systems.

Registration repeats, certification expires, and the aggregators keep changing hands

Wisconsin’s 3 months is the only estimate any state publishes. Everything past it comes from repetition, and the repetition compounds in two directions: across states, and inside one.

Connecticut has the vendor register per provider Medicaid ID, so one client operating under several IDs is several registrations.

Certification also expires, and the spec you built to has a version number:

• Pennsylvania publishes separate guides for new vendor certification and for recertification
• Wisconsin’s alternate EVV technical specification is on version 2.6

Ownership consolidated in 2024 and the credentialing didn’t follow. HHAeXchange acquired Sandata that year, and the two are still separate destinations: a North Carolina provider working through HHAeXchange requests Sandata production credentials directly. CareBridge moved inside Elevance Health’s Carelon on the October 2024 announcement, which puts an aggregator inside a payer.

Read that list as market structure as much as an integration checklist. Who owns your counterparty sets how fast its spec moves and whose interests it moves for.

Some states certify your system, and then govern your releases

One state runs a heavier regime, where approval covers the system itself and survives past go-live. Your release process becomes a regulated artifact: EVV compliance software there ships on the state’s calendar, and change control, defect disclosure, and go-live timing stop being internal decisions.

Texas authorizes a provider or financial management agency to run its own EVV system after approval as a proprietary system operator, under Texas Government Code Chapter 532, Subchapter F, with the state’s Medicaid administrator running the review. Approval requires a 100% passing score across every method in an operational readiness review, with up to 3 rounds of scoring and no approval if all 3 fail. After approval the operator reports non-compliance to the state within 2 business days and notifies it of any planned change that alters an approved component of the system.

Designing capture for homes you don’t control: GPS, IVR, and FVV

The conditions in the home decide the capture path, and your app doesn’t get a vote. A missing smartphone, dead signal, an unregistered landline, or a live-in caregiver each routes the visit differently.

You build every one of them, because coverage across a caseload decides how many homes you can bill in. EVV app development that scopes the mobile path alone stalls at go-live.

Capture that passes your tests and still generates exceptions

CMS has said the Cures Act doesn’t require capturing location as the person moves through the community, and that recording where service starts and stops satisfies the requirement. So location belongs at the clock events. Visit verification is a two-moment record.

Texas won’t auto-verify a visit, meaning clear it without human review, when the caregiver clocks in on a landline that isn’t registered in the client’s profile. That’s a data-quality failure dressed as a capture failure.

Offline capture is a state requirement. New York tells providers to select systems that can record a visit offline when network capacity is inadequate and upload it once connectivity returns.

In the caregiver app that means capturing the clock event locally and queuing it, with transmission as a separate retryable job. A caregiver in a basement with no signal is normal.

Exemptions expire, and states audit them

Every state carves out live-in caregivers, and defines the carve-out differently.

• Colorado ties live-in status to Department of Labor or IRS criteria, or to state-approved extenuating circumstances, and the live-in caregiver exemption expires after 365 days. It also recognizes accommodation exemptions under the ADA.
• California asks for regular presence in the home for more than 24 hours at a time with availability to provide services, on an attestation the consumer keeps.
• Michigan wants an attestation plus 2 documents proving shared residency.
• New York lets its inspector general or health department audit whether an exempt caregiver actually lives there.

That makes exemption a record with an effective date, an expiry, a proof artifact, and an audit trail. The scheduler needs it before the visit is created, because a denied claim is a slow way to find out.

Exception handling and visit maintenance: where agency revenue is won or lost

Auto-verification is the only outcome worth designing for. Everything else drops into visit maintenance, the correction workflow between a captured visit and a billable one, and it comes with a deadline. Most of the named mechanics here come from Texas, which publishes what many states run without documenting.

Auto-verification fails on missing events and mismatched setup

A clock event that never arrived is the simplest failure. A mismatch is the common one: the visit doesn’t line up with the schedule, or with what the client’s profile says. Then there’s a manual entry standing in for a clock event that never happened.

With no schedule in the system, Texas validates 5 critical elements before it will auto-verify: caregiver identity, client identity, actual hours worked, clock method, and service type.

Corrections run on the state’s clock, and 5 fields never move

Texas’s visit maintenance handbook lays out the whole mechanism. Corrections run 95 days from the date of service. Every correction carries a reason code, meaning a code number plus a code description plus required free text on specified codes, and reviewers read that free text during compliance reviews.

The state freezes 5 fields for the duration:

• actual service date
• clock-in time
• clock-out time
• actual hours worked
• GPS coordinates

When the window closes the transaction locks, and only a payer-approved unlock request reopens it, with the payer answering within 10 business days, or 30 when the request supports a managed care claims appeal.

Medicaid Fraud Control Units work the same records. Missouri’s unit charged an attendant whose EVV clock-ins came from her own address rather than the client’s.

Captured values are append-only, and a correction is an adjustment recorded beside the original. That shape is what makes the record defensible, and it’s why those 5 fields are locked.

The levers that shrink the queue

Tolerance is configurable. Texas can auto-verify a visit whose duration lands within 0.25 bill hours of the schedule, and can trim bill hours by that quarter hour to match, without touching the actual hours worked.

Retries cost you. Every aggregator rejection counts against the rejected-transaction score, including repeat rejections of the same visit, and manual entries count against usage.

Which leaves exception handling with two jobs: an aging view keyed to the state’s window, and a submit path that validates before it transmits instead of learning from rejections.

An unworked queue shows up in audits, and in your rate

Texas requires a minimum 80% usage score every state fiscal quarter from agencies, financial management agencies (the payroll intermediaries), and self-direction employers alike, and reviews anyone below it.

The score cuts both ways. Arizona attached a payment differential to auto-verified visit performance for a window that opened October 1, 2025 and closes September 30, 2026, and a visit counts only when every required element was captured without manual adjustment.

Auditors find the queue too. Ohio’s state auditor found 37 of 100 sampled providers submitted no EVV data at all, and HHS-OIG recommended in 2026 that Colorado refund $8 million in federal share for personal care claims that didn’t meet requirements.

Any build where a claim depends on captured data ends up with a queue like this one. We hit the same pattern in remote therapeutic monitoring app development.

That’s the argument for choosing to build home care software over taking the free state system: a queue somebody can actually work before the window closes.

Three records have to agree before a claim pays: EVV matching and hard edits at the aggregator

Your visit, the aggregator’s accepted visit, and the claim all have to line up before money moves. The one that decides whether you get paid is the aggregator’s. Your own verified flag is an internal opinion until it comes back confirmed.

Your system validates, and then the aggregator validates again

In Texas your EVV system checks identifiers and code combinations before it transmits. Then the aggregator re-validates: is the provider identifier active on the visit date, does the payer match, was the client Medicaid-eligible that day.

Wisconsin says it plainly: only aggregator-verified visits go to the payer.

Your visit status field needs a second value for what the aggregator said. Every screen that shows a caregiver or a biller the word verified has to mean the aggregator’s version, because that’s the one attached to money.

Missouri matches claims on 5 keys, and in April 2026 started denying the misses

Missouri publishes the keys and the calendar for its pre-adjudication EVV matching. From January 7, 2026 the state compared claims against aggregator visit data on 5 keys:

• client number
• dates of service
• provider Medicaid ID
• procedure code with modifiers
• units

Mismatches were flagged on the remittance advice rather than denied. From dates of service on April 1, 2026, claims for personal care, consumer-directed services, homemaker, chore, and respite with no matching verified visit are denied outright, first landing on the April 24 payment. Two failures the keys don’t imply on their own: units present in the aggregator but short of the units billed, and no verified visit at all for that procedure code and date range.

Hard edits differ by state in where they bite, and so does the shape of the claim rejection you get back. Michigan went further on January 1, 2026. Managed care home health billing routes through the state’s aggregator platform, and a missing visit record stops the claim from being created at all. Michigan also rejects the same claim as a duplicate when it arrives through both the state system and the plan directly.

Correcting a visit after billing is its own exposure

Texas recoups when the last visit maintenance date falls after the claim receipt date, unless an adjusted claim follows, and an approved unlock request doesn’t extend the filing deadline.

Emit the adjusted claim as part of the same workflow whenever a billed visit gets corrected. A human remembering to rebill is exactly the failure mode the rule is written for.

837 claims, the electronic claim file, plus clearinghouse routing and scrubbing belong to medical billing software development. Home care software development owns the part before that: making sure the visit the claim points at exists and was accepted.

Consumer-directed care is a different product: family caregivers and fiscal intermediaries

In self-directed care, also called consumer-directed services, the Medicaid member is the employer: they hire the caregiver and carry the compliance. A fiscal intermediary runs payroll and submits the claims, and states call that role a financial management services agency or vendor depending on where you are. Family caregivers are usually who gets paid, which is the whole appeal of the model.

Colorado scores the member, and the last strike ends their enrollment

Colorado’s self-direction compliance protocol makes the Medicaid member the compliance subject, with the financial management vendor and the case manager sharing the workflow. The member or their authorized representative, the person legally designated to act for them, takes a strike when fewer than 80% of their claims match an EVV record. This 80% is a different number from the quarterly usage score. It runs monthly against one member’s paid claims, and it escalates toward ending their enrollment. Strikes escalate:

• mandatory training with the financial management vendor
• mandatory training with the state’s training contractor
• a performance improvement plan
• a conversation with the case manager about other service delivery models
• termination from the program

Colorado’s rule makes a consistent pattern of member EVV non-compliance grounds for involuntary termination, and requires members hitting a financial-management system outage to report it within 5 business days.

Arizona caps paid parent caregivers at 40 hours a week and one agency, monitored through live-in identification in the EVV record.

Every deadline and every error message in a consumer directed care platform is read by a person managing their own care. An agency below a threshold loses revenue and hires a biller. A member below this one loses the program. Build the interface for that reader.

Payroll deadlines are the compliance deadlines

Colorado states the mechanism outright: financial management payroll is the basis on which EVV records match claims, so hitting payroll deadlines is how a member stays compliant.

In this model timesheet approval, payroll submission, and visit verification are one workflow. Payroll integration that treats them as three screens creates the mismatch it then has to reconcile.

In Texas, a financial management agency that overrides the visit record with the payroll system triggers required visit maintenance.

Your integration counterparty can be replaced by statute

New York consolidated CDPAP’s roughly 600 fiscal intermediaries into a single statewide intermediary on April 1, 2025, and the transition produced federal litigation over enrollment gaps, rejected timesheets, and lost wages.

The self-direction segment carries the worst match performance. Ohio’s auditor found non-agency personal care aides had the highest share of paid services with no matching processed visit, at 62%. That figure counts paid services that never matched, where the earlier Ohio number counted providers who submitted nothing at all.

So the fiscal intermediary is a swappable dependency in a market where the swap is a policy decision. Its interface belongs behind an abstraction from the first release.

Beyond verification: the modules that decide whether a visit is billable

One test decides what belongs in the platform: does this module stop a visit you couldn’t have billed? Modules that pass earn a slot in the first release. The rest can wait for someone to ask twice.

Scheduling has to know the authorization before it can create a visit

Authorization passes that test more clearly than anything else in the build. Texas puts it in administrative code rather than guidance: payment depends on the EVV data agreeing with the claim line and with the approved prior authorization.

Texas will let you capture the visit anyway, and then hold it. A provider on an approved proprietary system can clock in when no service authorization is present, and the state declines to auto-verify.

That puts the authorization’s remaining units and date range inside scheduling at creation time. A perfectly captured visit against an exhausted authorization is still unbillable.

Credentials and task records carry the claim, and states keep moving the fields

Caregiver credential tracking and plan of care tasks pass the same test. The record that proves what was delivered, and that someone qualified delivered it, is the record the claim depends on. An expired credential on the visit date is a billing problem a biller finds.

Field requirements move. Arizona dropped prior authorization data out of the EVV visit record on October 1, 2025 while keeping claims validation in place.

CMS encourages states to wire EVV into their claims, prior authorization, and eligibility systems, which is the integration you’re building from the other side.

Treat this surface as per-state configuration rather than schema. The fields a state wants in a visit record are a policy decision it can revise.

Location data, caregiver trust, and where HIPAA stops helping you

Two data trails come out of every visit, and only one of them has a regulation attached.

The caregiver’s location trail sits outside the regime you know

The client’s record is PHI, and it travels the compliance path you’ve built before. That side is ordinary HIPAA compliant software development. The caregiver is an employee. Their location history is workplace monitoring, and what governs it is your employer policy, state labor law, and whether workers keep the app on their phones.

The Cures Act asks only for systems that are minimally burdensome and HIPAA-compliant.

Data minimization is a live state position. New York aggregates only the minimum set of EVV elements the Cures Act requires, citing that minimally-burdensome language and stakeholder concerns about privacy and self-direction.

The same state expects EVV data retained and backed up to Medicaid audit standards, which it puts at 7 years.

Workers objected on the record, and the workarounds cost you money

A 2020 study in Disability and Health Journal interviewed 21 people using home-based personal assistance services and 20 paid workers. EVV wasn’t on the interview protocol, and 13 consumers and 10 workers raised it anyway. Their objections were consistent: intrusive location capture, lost flexibility in scheduling, personal phones as tracking hardware, and monitoring that read as institutional distrust rather than a payment control.

Dennis Borel of the Texas Coalition of People with Disabilities put the consumer objection this way: “What am I, a felon? Put an ankle bracelet on me.”

The Center for Democracy and Technology points out that the Cures Act requires neither GPS nor real-time activity logs, and that states could limit verification to where a service began and ended.

Location privacy is a product requirement here:

• capture nothing between clock events
• keep location only as long as the state requires
• show in the app what’s stored and who reads it
• set geofencing tolerance so a bad fix routes to a queue instead of to a supervisor

An app the workforce works around produces manual entries, manual entries produce exceptions, and exceptions are the queue that holds up payment. Adoption is a revenue control. Our caregiver app case study covers a build in these settings.

Before you commit to a state: the EVV launch diligence checklist

Launch-state selection is an engineering budget decision, and every input is already published. Work the list per state before you commit a roadmap slot to HCBS software development.

Model and aggregator

• Which of the 5 models the state runs
• Which aggregator it designates
• Whether payers there route to different aggregators

Your path in

• Whether an alternate-vendor path exists at all
• What the certification sequence is
• Whether the state also certifies provider-operated systems
• How long the state itself says it takes

This group flips more go decisions than any other, because the certification sequence sets your earliest revenue date in that state.

Enforcement posture

• Whether claims-to-visit matching is live
• On what date it went live
• Which claim fields have to match
• What the remittance advice says on a mismatch

The answers here set how forgiving your first billing cycle will be.

The operating rules you have to build to

• Any compliance-score threshold and its measurement period
• The correction window length
• Which fields the state forbids editing
• The reason-code set

Who carries the consequence

• Whether self-direction scores the member or the agency
• The exemption rules, and whether they expire
• Which fiscal intermediaries operate there

Arizona is why this is a recurring review: its aggregator changed hands in 2025 and every vendor re-tested. Run it again each time you add a state, and again when an aggregator contract renews. Everything downstream is ordinary healthcare app development sequencing.

Why Topflight Apps for EVV platform builds

A custom build earns its cost on the parts the free state system leaves alone: an exception queue with an aging view keyed to revenue instead of a compliance screen, a submit path that validates before it transmits, self-direction structures with the fiscal intermediary behind an abstraction, multi-state operation with tenancy at the state-program level, and analytics an owner can act on before a billing cycle closes.

Certification sits outside that list. It’s what you pay for the choice, and running it as a scheduled workstream costs less than discovering it mid-build.

Topflight Apps builds HIPAA-bounded healthcare software, including field-clinician mobile apps and agency-side visit scheduling and tracking, like the home health staffing marketplace we built. The offline-first capture and the workforce-adoption problem are familiar ground; the aggregator layer is what we scope per state.

A first engagement runs in order: pick the launch states, work the diligence list against each, design the capture layer for the homes in that caseload, then build the exception and claim path before anything else gets added.

If you’re building the platform, or you own the agency and you’re deciding whether to buy one, that’s the conversation we’re set up for: home care agency software development that treats the claim as the finish line.