Senior Care & Home Health App Development:The 2026 Electronic Visit Verification Guide

Most vertical app development guides start with the workflow — scheduling, notes, communication — and treat compliance as a section near the end. A home health or senior care app has to be built the other way around, because one requirement sits underneath almost every other design decision: Electronic Visit Verification, a federal mandate that determines how your app has to capture, timestamp, and transmit the fact that a caregiver actually showed up.

EVV requires that any Medicaid-funded personal care service or home health service visit be electronically confirmed — not written on a paper timesheet and reconciled later — with six specific pieces of information attached to every visit before it can be billed. Get this wrong, or bolt it on as an afterthought, and an otherwise well-built app produces claim denials, compliance findings, and caregivers who quietly work around a system that doesn't function in the actual conditions of a home visit.

The mandate itself is old enough to be settled law, not a live dispute: Section 12006(a) of the 21st Century Cures Act, signed into law in December 2016, required states to implement EVV for all Medicaid personal care services (PCS) by January 1, 2020, and for home health care services (HHCS) by January 1, 2023. Both deadlines have passed, and the federal mandate is now fully operational nationwide — every state has some EVV system in force for both service categories.

States that failed to make a documented "good faith effort" toward compliance, without "unavoidable delays" excusing the gap, faced a reduction in their federal medical assistance percentage (FMAP) of up to 1% — a real financial penalty that pushed even slow-moving states to stand up some form of EVV rather than accept the funding cut. What's shifted more recently, and what agencies building or buying software in 2026 are actually navigating day to day, is enforcement posture rather than the underlying mandate: several states have moved from "soft edits," where a visit record with a minor data error still gets paid, to "hard edits," where the same error triggers an automatic claim denial. We're naming this enforcement-tightening trend as reported by industry compliance vendors rather than as a verified national policy, since it varies by state and by specific edit rule — confirm your own state's current edit posture directly with your state Medicaid agency or aggregator rather than assuming a uniform national shift.

The practical upshot for anyone scoping an app: "EVV is required" has been true and settled since 2023. "How strictly a specific data gap gets penalized" is the part actively getting stricter in 2026, which raises the cost of a sloppy implementation even where the mandate itself hasn't changed.

The Cures Act fixes six data elements at the federal level, and every EVV-compliant visit record has to include all six before it can be submitted: the type of service performed, the individual receiving the service, the individual providing the service, the date of the service, the location where the service was delivered, and the time the service begins and ends.

• Type of service: Which specific service was delivered — personal care, home health aide services, skilled nursing, and so on, mapped to the codes your state's Medicaid program recognizes.
• Individual receiving the service: The Medicaid recipient — captured through a client ID that ties back to their eligibility record, not just a name your app stores locally.
• Individual providing the service: The specific caregiver, authenticated at check-in through whatever method your state accepts (see the verification-methods section below), not just whoever's account is logged in on the device.
• Date of the service: The calendar date, which sounds trivial until you're reconciling a visit that started before and ended after midnight.
• Location of the service: Where the visit happened — typically the client's address, verified against GPS or another accepted method rather than simply typed in by the caregiver.
• Time the service begins and ends: Timestamped check-in and check-out, which is what actually determines the billable duration of the visit.

States implement the technical details of each element differently — how location gets verified, what format the timestamp takes, which service-type code set applies — but none can legally drop an element from the requirement. Any app claiming EVV compliance that's missing one of the six, or capturing it inconsistently, is not actually compliant regardless of how polished the rest of the product is.

The single most consequential early decision in scoping a home health app isn't a technology choice — it's confirming which EVV model your state runs, because it determines whether a custom app can be your system of record at all.

In a closed-model state, the state itself selects a single EVV system — either a state-run platform or one state-designated vendor — that every provider must use, directly or through integration. A custom-built app in that environment is still worth building for scheduling, care documentation, payroll, and family communication, but it has to be architected to feed required visit data into the state's mandated system rather than to serve as the EVV record of truth on its own. In an open-model state, providers can choose their own EVV solution — a custom app, a purchased platform, or a hybrid — as long as it transmits the required data to the state's designated aggregator in that aggregator's specified format. Confirm your specific state's model before a single line of architecture gets written; it changes what "done" looks like for the entire build.

Sandatais the largest state-aggregator vendor in this space and, notably, chose to operate as an open-model-friendly aggregator rather than a closed one — a design decision that gives provider agencies interoperability with third-party systems instead of locking them into Sandata's own front-end. States using Sandata's Open EVV Series of Interfaces accept visit data as JSON submissions over secure FTP or a REST API, which is the concrete technical target a custom-built caregiver app needs to hit: your app's backend has to assemble each visit's six data elements into the exact schema Sandata's Real Time Interface expects, authenticate the submission correctly, and handle the acknowledgment or rejection response the aggregator sends back.

Other states designate different aggregators or run state-built systems entirely, each with its own submission format, authentication scheme, and error-handling behavior — there is no single national API a custom app can integrate against once and expect to work everywhere. If your agency operates across multiple states, budget for a genuinely separate integration effort per state's aggregator, not a single integration with minor per-state configuration on top.

States generally accept some combination of three verification methods, and the right choice for a given visit depends on connectivity, caregiver setting, and the specific fraud-risk profile of the caseload — not a single default every visit should use.

The practical pattern we build toward: GPS as the default for caregivers visiting multiple client homes with reliable connectivity, telephony as an automatic fallback the app triggers when GPS or network signal isn't available, and biometric check-in reserved for caseloads or agencies where a state accepts it and a documented fraud-risk justifies the added sensitivity. Relying on GPS as the sole method is both weaker engineering — it produces missing visit records in exactly the low-signal areas where home health visits are common — and, as the next section covers, the specific method drawing the most political and disability-rights scrutiny in 2026.

A caregiver's phone losing signal inside a client's home doesn't excuse the visit from EVV requirements — it just means your app's architecture has to handle the gap instead of failing at exactly the moment it matters most. The correct pattern queues the visit record locally the instant it's captured (check-in time, check-out time, GPS coordinates if available, any care notes) and treats the on-device record as the source of truth until a background sync confirms it reached your backend and, from there, the state aggregator.

This is a genuinely different engineering discipline from a typical connected mobile app, with its own failure modes — conflict resolution when a device syncs a batch of records after being offline for days, ensuring a caregiver can't accidentally submit the same visit twice once connectivity returns, and giving the caregiver clear on-device confirmation that a record queued successfully even with zero bars of signal. We cover the general architecture — local-first data models, sync engines, and the tradeoffs between rolling your own and using an existing sync framework — in detail in our offline-first mobile architecture guide; treat it as required reading before scoping a caregiver app's data layer, not optional background.

EVV's location-tracking requirement has drawn sustained criticism from disability-rights advocates, and it's worth building with that criticism in mind rather than treating GPS check-in as a purely technical, uncontested requirement. The Center for Democracy & Technologyhas argued that EVV's geographic tracking threatens the privacy and dignity of both the disabled people receiving care and the professional caregivers providing it, since the same GPS data that verifies a visit also creates a detailed, ongoing location record of activity inside a private home.

That tension surfaced concretely in Ohio's 2026 legislative session, where House Bill 795 proposed extending standard GPS-based EVV to previously-exempt live-in caregivers — family members or others who reside with the person they care for full-time. Opponents argued, in testimony before the state's House Medicaid Committee, that tracking a caregiver who never leaves the home produces no fraud-prevention signal EVV is meant to catch, while extending location surveillance into a private residence where a family lives, sleeps, and (in the specific framing used in that testimony) worships. Whatever the ultimate outcome in a given state's legislature, the underlying disagreement — whether GPS-based verification is a proportionate fraud safeguard or a surveillance overreach into family caregiving specifically — is unresolved and worth designing around rather than dismissing.

"Cures 2.0" comes up constantly in industry commentary on this topic, and it's worth being precise about what that phrase actually refers to: the original Cures 2.0 Act was introduced in the 117th Congress as H.R. 6000in 2021 and did not become law. What people mean by "EVV after Cures 2.0" today is an unresolved policy conversation, not a change already in effect — one line of proposals in that conversation would prohibit geographic tracking and biometric data collection within Medicaid EVV systems specifically on privacy grounds, while a separate line pushes toward more consistent national technical standards, including biometric identity confirmation, to address visit-verification fraud. Neither direction is current law. Build against your state's actual current requirements, and revisit this section's premise periodically rather than assuming it's settled.

A home health or senior care app handling protected health information for a HIPAA-covered agency needs the standard control set: encryption in transit and at rest, role-based access control, comprehensive audit logging of who accessed which patient's data and when, and a signed Business Associate Agreement between your development team or platform and the agency if you're building as a vendor rather than as the agency's own internal team.

One layer specific to this vertical is worth knowing before it surprises a build: behavioral health and substance-use-disorder services often need meaningfully different handling than standard personal-care visits, because 42 CFR Part 2's confidentiality protections for substance-use-disorder treatment records are stricter than HIPAA's general rule and don't automatically authorize the same location and visit data sharing with a state Medicaid aggregator that a standard EVV submission assumes. A number of states exclude behavioral health visits from standard EVV data flows, or route them through separate, more restrictive handling, for exactly this reason. If any part of your caseload touches behavioral health or substance-use treatment, confirm your specific state's carve-out directly rather than assuming one data pipeline correctly serves your entire caseload — this is a common gap between an app that's "HIPAA compliant" in the general sense and one that's correctly compliant for this specific service category.

Established home care platforms — AlayaCare, WellSky Personal Care, HHAeXchange, AxisCare, MatrixCare, and several others in the same space — already bundle scheduling, EVV, billing, payroll, and caregiver management into one system, and for an agency whose workflow fits a fairly standard shape, buying is very often the right call. Building a custom app makes sense when your care model genuinely doesn't fit that standard shape — a specialized clinical protocol, a distinctive family-communication or care-coordination workflow a generic platform can't replicate, or integration with proprietary remote-monitoring or medical-device hardware — or when the app itself is the product you intend to sell to other agencies rather than internal tooling for your own.

Pricing across the established platforms varies enormously and is rarely published directly by the vendors themselves. Third-party comparison sites have reported figures from roughly $99 a month at the low end to enterprise implementations with $20,000 to $400,000 in setup fees alone, and one comparison cited AlayaCare specifically at around $1,650 a month plus a $5,000 one-time fee — we're naming these as third-party-reported figures rather than independently verified list prices, since none of the major vendors in this category publish a public rate card, and actual pricing depends on caseload size, module selection, and negotiated terms you'd only get from a direct quote.

A middle path worth considering seriously: buy an established platform for the back-office functions (billing, payroll, HR) where a generic, mature system genuinely is better than anything worth building from scratch, and build a custom caregiver-facing mobile app only for the specific visit-verification and care-documentation workflow where your agency's actual field conditions — connectivity, caseload type, verification method mix — don't fit what a one-size-fits-all platform assumes.

Consider, as an illustrative scenario rather than a claimed client outcome, a personal care agency with 40 caregivers serving a mixed Medicaid and private-pay caseload across one open-model state, currently on a generic scheduling app with no built-in EVV and a separate, manual process for submitting visit data to the state's Sandata aggregator.

The agency's actual pain isn't scheduling — it's that manual EVV submission, done by two back-office staff re-keying visit data from paper and app-exported spreadsheets, produces enough transcription errors and late submissions to generate real claim-denial volume every month, on top of the staff time itself. A single-platform custom build in the $28,000–$70,000 band — a caregiver app with GPS check-in, telephony fallback for the agency's several rural clients, offline queuing, and a direct API integration to the state's Sandata aggregator — replaces both the manual re-keying step and the current app's gaps in one build. Worked arithmetic on the actual tradeoff: if two staff members currently spend a combined 15 hours a week on manual EVV data entry and denial follow-up at a fully loaded cost of roughly $35/hour, that's roughly $27,000 a year in labor cost alone, before counting the revenue actually lost to denied claims that never get corrected and resubmitted — a build in the $28k–$70k range pays for itself inside two to three years on the labor savings alone, before any reduction in claim denials is counted, which is exactly the kind of arithmetic worth doing with your own numbers before committing to either a platform subscription or a custom build.

Limitations of this guide, stated plainly.EVV requirements are set and enforced state by state on top of a fixed federal core, and several of the specific claims here — the 2026 shift toward "hard edit" enforcement, the exact current status of Ohio's HB 795, and third-party-reported platform pricing — are drawn from industry commentary and vendor comparison sites rather than a single authoritative national source, because no such single source exists for state-by-state EVV implementation detail. We named every place a figure or claim came from a secondary or vendor source rather than a state Medicaid agency directly. Confirm your own state's current EVV model, aggregator, and accepted verification methods directly with your state Medicaid agency before finalizing any build's technical scope — this guide is a map of the terrain, not a substitute for your specific state's current published requirements. Nothing here is legal advice; a qualified healthcare compliance attorney should review your specific data flows before you handle real patient information.

If you're weighing a custom build against an established platform, the same logic from our healthcare and HIPAA app development guide generally applies: understanding your specific compliance surface before any code gets written is worth doing carefully, and the engineering work that follows — a correctly architected offline-first sync layer, a state aggregator integration that surfaces rejections clearly, and privacy-transparent handling of location and biometric data — is where a team that has built this before earns its fee.