November 1, 2026

9 min read

Home Care Agency Software Breaks Down the Moment You Operate in a Second State

Why home care agencies can't buy their way out of EVV compliance

Electronic visit verification software will not make your agency compliant on its own, especially once you operate in more than one state. EVV compliance is a federal mandate executed through fifty different state implementations, each with its own vendor, its own data model, and its own audit rules. Software that handles this cleanly in Ohio can create a reconciliation mess the day you acquire an agency in Texas. That's not a vendor failure. It's a structural mismatch between how the mandate was written and how most home care agency software was built.

The 21st Century Cures Act required Medicaid personal care services to use EVV by January 1, 2020, and home health services by January 1, 2023, as confirmed on Virginia's Medicaid EVV page and other state Medicaid sites (dmas.virginia.gov). What the law didn't do is specify a single system. It left implementation to the states, which means an operator running agencies in three states is, in practice, running three different compliance regimes under one roof. Most home care agency software was designed to satisfy one state's rules well. Almost none were designed to reconcile across several at once, which is exactly the gap private equity-backed roll-ups are hitting right now.

What EVV compliance actually requires, and why every state is different

EVV requires agencies to electronically capture six data points for every Medicaid-funded home visit: the type of service, the individual receiving it, the date, the start and end time, the location, and the individual providing the service. That part is consistent nationwide. What differs completely is how states collect it.

States run one of two models. In an open model, agencies can use their own EVV-capable software as long as it feeds verified visit data to the state's aggregator in the required format. In a closed model, the state mandates a single vendor (commonly Sandata, Tellus, or HHAeXchange) and every agency in that state must submit through it, regardless of what scheduling or billing system they otherwise run. Tennessee, West Virginia, and Maryland each have published their own EVV guidance with different submission formats and exception-handling rules, and the Department of Health and Human Services' Office of Inspector General has an active work plan item specifically reviewing EVV data integrity for Medicaid personal care services (oig.hhs.gov). That's a signal that audit risk here is not theoretical.

So a multi-state operator isn't dealing with one compliance requirement. They're dealing with as many as there are states in their footprint, each with a different data pipe, a different exception workflow, and a different definition of what counts as a "late" or "missing" visit. This is the part vendor product pages leave out, because no single platform can claim to solve it everywhere.

Where home care agency software starts breaking down

The breaking point isn't visit count. It's state count. A single-location agency with a closed-model state vendor rarely has problems: one system, one format, one set of exceptions to chase. The trouble starts the moment an agency operates in, or acquires into, a second state with a different model.

At that point, caregivers are clocking in through different apps or devices depending on where they're assigned. Scheduling staff are reconciling visit data against two or three aggregator formats by hand, usually in a spreadsheet nobody wants to own. Billing teams are chasing EVV mismatches that silently sit behind claim denials, because most state Medicaid programs won't pay a claim if the EVV record doesn't match the billed visit. And compliance staff are trying to produce a single audit-ready record across systems that were never built to talk to each other.

We see the same shape of problem in multi-location provider groups outside home care, where credentialing breaks down past a certain location count for an entirely different but structurally identical reason: a compliance process designed for one jurisdiction gets asked to scale across several, and the off-the-shelf tool was never built for that. The same pattern shows up on the billing side once revenue cycle operations span multiple entities, which is why we wrote separately about when revenue cycle automation needs to be built rather than bought after a roll-up.

Private equity has made this scaling event common rather than rare. Global healthcare PE deal value hit an estimated $191 billion in 2025, a record, per coverage of Bain's healthcare private equity research, and home care has been a specific target of that activity, as documented by Americans for Financial Reform Education Fund's 2023 review of PE ownership in home healthcare (ourfinancialsecurity.org). Roll-ups don't happen gradually. An agency can go from one state to four in the space of a year through acquisition, long before anyone has had time to redesign the compliance stack for that reality.

The hidden operational cost nobody prices in

The cost that doesn't show up in a software demo is caregiver time spent fixing exceptions, and operations staff time spent chasing them. The direct care workforce grew from 3.2 million in 2011 to 4.7 million in 2021, and home care workers now make up 58% of that total direct care workforce, according to PHI National's workforce research. The Commonwealth Fund put the 2022 figure at 4.8 million direct care workers serving 9.8 million people at home (commonwealthfund.org, March 2024). That's a large, high-turnover, often part-time workforce, which means EVV exceptions (a missed clock-out, a GPS mismatch, a manual entry correction) happen constantly, at volume, across people who are not administrative staff and often aren't trained to fix them. Every one of those exceptions is a task: someone has to catch it, verify it, correct it, and resubmit it before a claim can be billed. Multiply that by multiple states with multiple aggregator formats, and you get a standing administrative function that exists only to compensate for systems that don't reconcile with each other. Agencies rarely budget for this because it doesn't appear as a line item. It shows up as denied claims, slower cash cycles, and an operations team that's permanently a few weeks behind on cleanup.

Build, buy, or augment: a framework for multi-location operators

The honest answer for most agencies under roughly five locations or one state is: buy, and don't overthink it. A good closed-model EVV vendor or an open-model platform that's EVV-capable will cover you. This is not the moment to build custom software.

The calculation changes once you cross into a second or third state, or once you're actively acquiring agencies that each arrived with their own system. At that point you have three real options, and the right one depends on what's actually broken, not on what's fashionable.

Buy more software. Some operators respond to multi-state pain by buying an "enterprise" EVV platform that claims to handle several states at once. This sometimes works, but it usually means migrating every acquired agency onto one vendor's workflow, which is slow, disruptive to caregivers mid-tenure, and still leaves you dependent on that vendor's roadmap for every new state you enter.

Build a reconciliation and exception-handling layer on top of what you already have. This is the option nobody selling EVV software will recommend, because it doesn't involve ripping out their product. Instead of replacing every agency's existing state-mandated system, you build a layer that ingests visit data from each aggregator format, normalizes it, flags exceptions automatically, and routes them to the right person before they become a billing problem. The underlying EVV systems stay in place because they're satisfying the state mandate correctly. What's missing is the cross-system intelligence layer, and that's usually a smaller, faster build than people assume because the data already exists, it's just scattered.

Augment with a narrow automation layer around one specific bottleneck, like exception triage or audit-trail assembly, without touching scheduling or billing at all. This is the right call when the pain is concentrated in one function rather than spread across the whole operation.

The framework we use with clients, whether the domain is EVV, billing, or credentialing, starts with diagnosis before any build decision: map where the manual work actually concentrates, quantify the hours or dollars it costs, and only then decide whether a platform swap, a reconciliation layer, or a narrow automation fixes it. We've applied this same logic to a healthcare staffing firm where credentialing agents cut processing time from 120 days to 30 (how AI agents cut healthcare credentialing from 120 days to 30), a different compliance bottleneck but the same underlying problem: a workforce-heavy, regulation-heavy operation outgrowing a tool that was built for a single-location version of the business.

What a compliant AI layer needs to get right

Any system touching EVV data is touching protected health information and caregiver location data simultaneously, which puts it squarely under HIPAA's Security Rule (hhs.gov/hipaa). That means encryption in transit and at rest, strict access controls tied to job function, and an audit log that can reconstruct who touched what data and when, not just what the EVV record itself contains. For agencies operating across state Medicaid programs, there's a second layer: some states have data residency or handling expectations tied to their aggregator contracts, and your reconciliation layer needs to respect those boundaries rather than pooling everything into one undifferentiated database. We cover the specifics of what counts as genuinely compliant AI handling of this kind of data, beyond a signed business associate agreement, in what HIPAA-compliant AI actually requires beyond a signed BAA. For agencies that want zero ambiguity on where caregiver and client data lives, the more conservative architecture is self-hosted open-source models running on infrastructure the agency controls, with no data retention by a third party. That's a more expensive build than calling an API, but for a business whose entire value proposition depends on Medicaid trust and audit cleanliness, it's often the only architecture that survives a serious compliance review.

If you're working through this decision, this is exactly what our Discovery phase at Genta AI Solutions maps out before anything gets built, and we're happy to compare notes.

Frequently asked questions

What is EVV compliance and who does it apply to?

EVV, or electronic visit verification, is a federal requirement under the 21st Century Cures Act that Medicaid-funded personal care and home health visits be electronically verified, capturing service type, recipient, date, start/end time, location, and provider. It applies to any agency billing Medicaid for personal care services (required since January 1, 2020) or home health services (since January 1, 2023).

What are the EVV requirements by state, and why do they differ?

The federal mandate sets what data must be captured, but each state chooses how. States run either an "open model," where agencies use their own EVV-capable software, or a "closed model," where a single state-designated vendor like Sandata, Tellus, or HHAeXchange is mandatory. That's why a system that works in one state often doesn't transfer cleanly to the next.

Who is exempt from EVV?

Exemptions vary by state but commonly include visits where live-in caregivers provide care to a family member in the same household, certain self-directed care arrangements, and some non-Medicaid-funded services. Always confirm exemption rules against your specific state Medicaid agency's guidance, since the federal mandate leaves this determination to the states.

What's the difference between an open model and closed model EVV system?

In an open model, agencies can choose or build their own EVV software as long as it transmits compliant data to the state's aggregator. In a closed model, the state requires every agency to submit visit data through one designated vendor platform, regardless of what internal scheduling system the agency otherwise prefers.

Is EVV required for home health services, or only personal care services?

Both. The 21st Century Cures Act required EVV for Medicaid personal care services by January 1, 2020, and extended the same requirement to home health services by January 1, 2023. Agencies providing both service types often have to satisfy the mandate on two separate timelines and, in some states, two separate systems.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

November 1, 2026

9 min read

Home Care Agency Software Breaks Down the Moment You Operate in a Second State

Why home care agencies can't buy their way out of EVV compliance

Electronic visit verification software will not make your agency compliant on its own, especially once you operate in more than one state. EVV compliance is a federal mandate executed through fifty different state implementations, each with its own vendor, its own data model, and its own audit rules. Software that handles this cleanly in Ohio can create a reconciliation mess the day you acquire an agency in Texas. That's not a vendor failure. It's a structural mismatch between how the mandate was written and how most home care agency software was built.

The 21st Century Cures Act required Medicaid personal care services to use EVV by January 1, 2020, and home health services by January 1, 2023, as confirmed on Virginia's Medicaid EVV page and other state Medicaid sites (dmas.virginia.gov). What the law didn't do is specify a single system. It left implementation to the states, which means an operator running agencies in three states is, in practice, running three different compliance regimes under one roof. Most home care agency software was designed to satisfy one state's rules well. Almost none were designed to reconcile across several at once, which is exactly the gap private equity-backed roll-ups are hitting right now.

What EVV compliance actually requires, and why every state is different

EVV requires agencies to electronically capture six data points for every Medicaid-funded home visit: the type of service, the individual receiving it, the date, the start and end time, the location, and the individual providing the service. That part is consistent nationwide. What differs completely is how states collect it.

States run one of two models. In an open model, agencies can use their own EVV-capable software as long as it feeds verified visit data to the state's aggregator in the required format. In a closed model, the state mandates a single vendor (commonly Sandata, Tellus, or HHAeXchange) and every agency in that state must submit through it, regardless of what scheduling or billing system they otherwise run. Tennessee, West Virginia, and Maryland each have published their own EVV guidance with different submission formats and exception-handling rules, and the Department of Health and Human Services' Office of Inspector General has an active work plan item specifically reviewing EVV data integrity for Medicaid personal care services (oig.hhs.gov). That's a signal that audit risk here is not theoretical.

So a multi-state operator isn't dealing with one compliance requirement. They're dealing with as many as there are states in their footprint, each with a different data pipe, a different exception workflow, and a different definition of what counts as a "late" or "missing" visit. This is the part vendor product pages leave out, because no single platform can claim to solve it everywhere.

Where home care agency software starts breaking down

The breaking point isn't visit count. It's state count. A single-location agency with a closed-model state vendor rarely has problems: one system, one format, one set of exceptions to chase. The trouble starts the moment an agency operates in, or acquires into, a second state with a different model.

At that point, caregivers are clocking in through different apps or devices depending on where they're assigned. Scheduling staff are reconciling visit data against two or three aggregator formats by hand, usually in a spreadsheet nobody wants to own. Billing teams are chasing EVV mismatches that silently sit behind claim denials, because most state Medicaid programs won't pay a claim if the EVV record doesn't match the billed visit. And compliance staff are trying to produce a single audit-ready record across systems that were never built to talk to each other.

We see the same shape of problem in multi-location provider groups outside home care, where credentialing breaks down past a certain location count for an entirely different but structurally identical reason: a compliance process designed for one jurisdiction gets asked to scale across several, and the off-the-shelf tool was never built for that. The same pattern shows up on the billing side once revenue cycle operations span multiple entities, which is why we wrote separately about when revenue cycle automation needs to be built rather than bought after a roll-up.

Private equity has made this scaling event common rather than rare. Global healthcare PE deal value hit an estimated $191 billion in 2025, a record, per coverage of Bain's healthcare private equity research, and home care has been a specific target of that activity, as documented by Americans for Financial Reform Education Fund's 2023 review of PE ownership in home healthcare (ourfinancialsecurity.org). Roll-ups don't happen gradually. An agency can go from one state to four in the space of a year through acquisition, long before anyone has had time to redesign the compliance stack for that reality.

The hidden operational cost nobody prices in

The cost that doesn't show up in a software demo is caregiver time spent fixing exceptions, and operations staff time spent chasing them. The direct care workforce grew from 3.2 million in 2011 to 4.7 million in 2021, and home care workers now make up 58% of that total direct care workforce, according to PHI National's workforce research. The Commonwealth Fund put the 2022 figure at 4.8 million direct care workers serving 9.8 million people at home (commonwealthfund.org, March 2024). That's a large, high-turnover, often part-time workforce, which means EVV exceptions (a missed clock-out, a GPS mismatch, a manual entry correction) happen constantly, at volume, across people who are not administrative staff and often aren't trained to fix them. Every one of those exceptions is a task: someone has to catch it, verify it, correct it, and resubmit it before a claim can be billed. Multiply that by multiple states with multiple aggregator formats, and you get a standing administrative function that exists only to compensate for systems that don't reconcile with each other. Agencies rarely budget for this because it doesn't appear as a line item. It shows up as denied claims, slower cash cycles, and an operations team that's permanently a few weeks behind on cleanup.

Build, buy, or augment: a framework for multi-location operators

The honest answer for most agencies under roughly five locations or one state is: buy, and don't overthink it. A good closed-model EVV vendor or an open-model platform that's EVV-capable will cover you. This is not the moment to build custom software.

The calculation changes once you cross into a second or third state, or once you're actively acquiring agencies that each arrived with their own system. At that point you have three real options, and the right one depends on what's actually broken, not on what's fashionable.

Buy more software. Some operators respond to multi-state pain by buying an "enterprise" EVV platform that claims to handle several states at once. This sometimes works, but it usually means migrating every acquired agency onto one vendor's workflow, which is slow, disruptive to caregivers mid-tenure, and still leaves you dependent on that vendor's roadmap for every new state you enter.

Build a reconciliation and exception-handling layer on top of what you already have. This is the option nobody selling EVV software will recommend, because it doesn't involve ripping out their product. Instead of replacing every agency's existing state-mandated system, you build a layer that ingests visit data from each aggregator format, normalizes it, flags exceptions automatically, and routes them to the right person before they become a billing problem. The underlying EVV systems stay in place because they're satisfying the state mandate correctly. What's missing is the cross-system intelligence layer, and that's usually a smaller, faster build than people assume because the data already exists, it's just scattered.

Augment with a narrow automation layer around one specific bottleneck, like exception triage or audit-trail assembly, without touching scheduling or billing at all. This is the right call when the pain is concentrated in one function rather than spread across the whole operation.

The framework we use with clients, whether the domain is EVV, billing, or credentialing, starts with diagnosis before any build decision: map where the manual work actually concentrates, quantify the hours or dollars it costs, and only then decide whether a platform swap, a reconciliation layer, or a narrow automation fixes it. We've applied this same logic to a healthcare staffing firm where credentialing agents cut processing time from 120 days to 30 (how AI agents cut healthcare credentialing from 120 days to 30), a different compliance bottleneck but the same underlying problem: a workforce-heavy, regulation-heavy operation outgrowing a tool that was built for a single-location version of the business.

What a compliant AI layer needs to get right

Any system touching EVV data is touching protected health information and caregiver location data simultaneously, which puts it squarely under HIPAA's Security Rule (hhs.gov/hipaa). That means encryption in transit and at rest, strict access controls tied to job function, and an audit log that can reconstruct who touched what data and when, not just what the EVV record itself contains. For agencies operating across state Medicaid programs, there's a second layer: some states have data residency or handling expectations tied to their aggregator contracts, and your reconciliation layer needs to respect those boundaries rather than pooling everything into one undifferentiated database. We cover the specifics of what counts as genuinely compliant AI handling of this kind of data, beyond a signed business associate agreement, in what HIPAA-compliant AI actually requires beyond a signed BAA. For agencies that want zero ambiguity on where caregiver and client data lives, the more conservative architecture is self-hosted open-source models running on infrastructure the agency controls, with no data retention by a third party. That's a more expensive build than calling an API, but for a business whose entire value proposition depends on Medicaid trust and audit cleanliness, it's often the only architecture that survives a serious compliance review.

If you're working through this decision, this is exactly what our Discovery phase at Genta AI Solutions maps out before anything gets built, and we're happy to compare notes.

Frequently asked questions

What is EVV compliance and who does it apply to?

EVV, or electronic visit verification, is a federal requirement under the 21st Century Cures Act that Medicaid-funded personal care and home health visits be electronically verified, capturing service type, recipient, date, start/end time, location, and provider. It applies to any agency billing Medicaid for personal care services (required since January 1, 2020) or home health services (since January 1, 2023).

What are the EVV requirements by state, and why do they differ?

The federal mandate sets what data must be captured, but each state chooses how. States run either an "open model," where agencies use their own EVV-capable software, or a "closed model," where a single state-designated vendor like Sandata, Tellus, or HHAeXchange is mandatory. That's why a system that works in one state often doesn't transfer cleanly to the next.

Who is exempt from EVV?

Exemptions vary by state but commonly include visits where live-in caregivers provide care to a family member in the same household, certain self-directed care arrangements, and some non-Medicaid-funded services. Always confirm exemption rules against your specific state Medicaid agency's guidance, since the federal mandate leaves this determination to the states.

What's the difference between an open model and closed model EVV system?

In an open model, agencies can choose or build their own EVV software as long as it transmits compliant data to the state's aggregator. In a closed model, the state requires every agency to submit visit data through one designated vendor platform, regardless of what internal scheduling system the agency otherwise prefers.

Is EVV required for home health services, or only personal care services?

Both. The 21st Century Cures Act required EVV for Medicaid personal care services by January 1, 2020, and extended the same requirement to home health services by January 1, 2023. Agencies providing both service types often have to satisfy the mandate on two separate timelines and, in some states, two separate systems.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

November 1, 2026

9 min read

Home Care Agency Software Breaks Down the Moment You Operate in a Second State

Why home care agencies can't buy their way out of EVV compliance

Electronic visit verification software will not make your agency compliant on its own, especially once you operate in more than one state. EVV compliance is a federal mandate executed through fifty different state implementations, each with its own vendor, its own data model, and its own audit rules. Software that handles this cleanly in Ohio can create a reconciliation mess the day you acquire an agency in Texas. That's not a vendor failure. It's a structural mismatch between how the mandate was written and how most home care agency software was built.

The 21st Century Cures Act required Medicaid personal care services to use EVV by January 1, 2020, and home health services by January 1, 2023, as confirmed on Virginia's Medicaid EVV page and other state Medicaid sites (dmas.virginia.gov). What the law didn't do is specify a single system. It left implementation to the states, which means an operator running agencies in three states is, in practice, running three different compliance regimes under one roof. Most home care agency software was designed to satisfy one state's rules well. Almost none were designed to reconcile across several at once, which is exactly the gap private equity-backed roll-ups are hitting right now.

What EVV compliance actually requires, and why every state is different

EVV requires agencies to electronically capture six data points for every Medicaid-funded home visit: the type of service, the individual receiving it, the date, the start and end time, the location, and the individual providing the service. That part is consistent nationwide. What differs completely is how states collect it.

States run one of two models. In an open model, agencies can use their own EVV-capable software as long as it feeds verified visit data to the state's aggregator in the required format. In a closed model, the state mandates a single vendor (commonly Sandata, Tellus, or HHAeXchange) and every agency in that state must submit through it, regardless of what scheduling or billing system they otherwise run. Tennessee, West Virginia, and Maryland each have published their own EVV guidance with different submission formats and exception-handling rules, and the Department of Health and Human Services' Office of Inspector General has an active work plan item specifically reviewing EVV data integrity for Medicaid personal care services (oig.hhs.gov). That's a signal that audit risk here is not theoretical.

So a multi-state operator isn't dealing with one compliance requirement. They're dealing with as many as there are states in their footprint, each with a different data pipe, a different exception workflow, and a different definition of what counts as a "late" or "missing" visit. This is the part vendor product pages leave out, because no single platform can claim to solve it everywhere.

Where home care agency software starts breaking down

The breaking point isn't visit count. It's state count. A single-location agency with a closed-model state vendor rarely has problems: one system, one format, one set of exceptions to chase. The trouble starts the moment an agency operates in, or acquires into, a second state with a different model.

At that point, caregivers are clocking in through different apps or devices depending on where they're assigned. Scheduling staff are reconciling visit data against two or three aggregator formats by hand, usually in a spreadsheet nobody wants to own. Billing teams are chasing EVV mismatches that silently sit behind claim denials, because most state Medicaid programs won't pay a claim if the EVV record doesn't match the billed visit. And compliance staff are trying to produce a single audit-ready record across systems that were never built to talk to each other.

We see the same shape of problem in multi-location provider groups outside home care, where credentialing breaks down past a certain location count for an entirely different but structurally identical reason: a compliance process designed for one jurisdiction gets asked to scale across several, and the off-the-shelf tool was never built for that. The same pattern shows up on the billing side once revenue cycle operations span multiple entities, which is why we wrote separately about when revenue cycle automation needs to be built rather than bought after a roll-up.

Private equity has made this scaling event common rather than rare. Global healthcare PE deal value hit an estimated $191 billion in 2025, a record, per coverage of Bain's healthcare private equity research, and home care has been a specific target of that activity, as documented by Americans for Financial Reform Education Fund's 2023 review of PE ownership in home healthcare (ourfinancialsecurity.org). Roll-ups don't happen gradually. An agency can go from one state to four in the space of a year through acquisition, long before anyone has had time to redesign the compliance stack for that reality.

The hidden operational cost nobody prices in

The cost that doesn't show up in a software demo is caregiver time spent fixing exceptions, and operations staff time spent chasing them. The direct care workforce grew from 3.2 million in 2011 to 4.7 million in 2021, and home care workers now make up 58% of that total direct care workforce, according to PHI National's workforce research. The Commonwealth Fund put the 2022 figure at 4.8 million direct care workers serving 9.8 million people at home (commonwealthfund.org, March 2024). That's a large, high-turnover, often part-time workforce, which means EVV exceptions (a missed clock-out, a GPS mismatch, a manual entry correction) happen constantly, at volume, across people who are not administrative staff and often aren't trained to fix them. Every one of those exceptions is a task: someone has to catch it, verify it, correct it, and resubmit it before a claim can be billed. Multiply that by multiple states with multiple aggregator formats, and you get a standing administrative function that exists only to compensate for systems that don't reconcile with each other. Agencies rarely budget for this because it doesn't appear as a line item. It shows up as denied claims, slower cash cycles, and an operations team that's permanently a few weeks behind on cleanup.

Build, buy, or augment: a framework for multi-location operators

The honest answer for most agencies under roughly five locations or one state is: buy, and don't overthink it. A good closed-model EVV vendor or an open-model platform that's EVV-capable will cover you. This is not the moment to build custom software.

The calculation changes once you cross into a second or third state, or once you're actively acquiring agencies that each arrived with their own system. At that point you have three real options, and the right one depends on what's actually broken, not on what's fashionable.

Buy more software. Some operators respond to multi-state pain by buying an "enterprise" EVV platform that claims to handle several states at once. This sometimes works, but it usually means migrating every acquired agency onto one vendor's workflow, which is slow, disruptive to caregivers mid-tenure, and still leaves you dependent on that vendor's roadmap for every new state you enter.

Build a reconciliation and exception-handling layer on top of what you already have. This is the option nobody selling EVV software will recommend, because it doesn't involve ripping out their product. Instead of replacing every agency's existing state-mandated system, you build a layer that ingests visit data from each aggregator format, normalizes it, flags exceptions automatically, and routes them to the right person before they become a billing problem. The underlying EVV systems stay in place because they're satisfying the state mandate correctly. What's missing is the cross-system intelligence layer, and that's usually a smaller, faster build than people assume because the data already exists, it's just scattered.

Augment with a narrow automation layer around one specific bottleneck, like exception triage or audit-trail assembly, without touching scheduling or billing at all. This is the right call when the pain is concentrated in one function rather than spread across the whole operation.

The framework we use with clients, whether the domain is EVV, billing, or credentialing, starts with diagnosis before any build decision: map where the manual work actually concentrates, quantify the hours or dollars it costs, and only then decide whether a platform swap, a reconciliation layer, or a narrow automation fixes it. We've applied this same logic to a healthcare staffing firm where credentialing agents cut processing time from 120 days to 30 (how AI agents cut healthcare credentialing from 120 days to 30), a different compliance bottleneck but the same underlying problem: a workforce-heavy, regulation-heavy operation outgrowing a tool that was built for a single-location version of the business.

What a compliant AI layer needs to get right

Any system touching EVV data is touching protected health information and caregiver location data simultaneously, which puts it squarely under HIPAA's Security Rule (hhs.gov/hipaa). That means encryption in transit and at rest, strict access controls tied to job function, and an audit log that can reconstruct who touched what data and when, not just what the EVV record itself contains. For agencies operating across state Medicaid programs, there's a second layer: some states have data residency or handling expectations tied to their aggregator contracts, and your reconciliation layer needs to respect those boundaries rather than pooling everything into one undifferentiated database. We cover the specifics of what counts as genuinely compliant AI handling of this kind of data, beyond a signed business associate agreement, in what HIPAA-compliant AI actually requires beyond a signed BAA. For agencies that want zero ambiguity on where caregiver and client data lives, the more conservative architecture is self-hosted open-source models running on infrastructure the agency controls, with no data retention by a third party. That's a more expensive build than calling an API, but for a business whose entire value proposition depends on Medicaid trust and audit cleanliness, it's often the only architecture that survives a serious compliance review.

If you're working through this decision, this is exactly what our Discovery phase at Genta AI Solutions maps out before anything gets built, and we're happy to compare notes.

Frequently asked questions

What is EVV compliance and who does it apply to?

EVV, or electronic visit verification, is a federal requirement under the 21st Century Cures Act that Medicaid-funded personal care and home health visits be electronically verified, capturing service type, recipient, date, start/end time, location, and provider. It applies to any agency billing Medicaid for personal care services (required since January 1, 2020) or home health services (since January 1, 2023).

What are the EVV requirements by state, and why do they differ?

The federal mandate sets what data must be captured, but each state chooses how. States run either an "open model," where agencies use their own EVV-capable software, or a "closed model," where a single state-designated vendor like Sandata, Tellus, or HHAeXchange is mandatory. That's why a system that works in one state often doesn't transfer cleanly to the next.

Who is exempt from EVV?

Exemptions vary by state but commonly include visits where live-in caregivers provide care to a family member in the same household, certain self-directed care arrangements, and some non-Medicaid-funded services. Always confirm exemption rules against your specific state Medicaid agency's guidance, since the federal mandate leaves this determination to the states.

What's the difference between an open model and closed model EVV system?

In an open model, agencies can choose or build their own EVV software as long as it transmits compliant data to the state's aggregator. In a closed model, the state requires every agency to submit visit data through one designated vendor platform, regardless of what internal scheduling system the agency otherwise prefers.

Is EVV required for home health services, or only personal care services?

Both. The 21st Century Cures Act required EVV for Medicaid personal care services by January 1, 2020, and extended the same requirement to home health services by January 1, 2023. Agencies providing both service types often have to satisfy the mandate on two separate timelines and, in some states, two separate systems.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.

Tell us where the manual work hurts

We’ll tell you straight whether AI can fix it, what it costs, and what it should return. Whatever we build, you own.