Introduction: EVV Is a Submission Problem, Not a Capture Problem
Recording a clock-in and a clock-out is straightforward. Getting that visit accepted by a state aggregator, matched to an authorization, and converted into a paid claim is where the actual engineering sits. This is where agencies discover that EVV integration is a revenue system, not a compliance checkbox.
Before any of this can be scoped, one question needs an answer for each state involved: which EVV model does the state operate? In a closed or state-mandated model, an agency may be required to use the state’s own system for capture, which limits what gets built there. In an open or provider-choice model, the agency’s own system can serve as the source of capture, as long as it submits data the aggregator will accept, and this is the model where custom software development actually earns its place, since the agency controls the capture layer end to end.
This article covers capture methods, aggregator submission, rejection handling and reconciliation, payroll sync, and the family portal layer. It also covers failure handling that keeps it all trustworthy, much of which lives inside a well-built caregiver app. State models, aggregator specifications, and onboarding requirements should always be confirmed directly before any architecture gets fixed in place.
Capture Methods: Mobile, Telephony, and Fixed Devices
Three capture methods exist because three different real-world situations exist. An agency serving a real population needs all of them, not just the one that looks best in a demo.
Mobile app capture records the clock-in and clock-out, with location captured at those two points. Two design details matter here. First, location gets captured at the verification events themselves, not continuously. CMS guidance has already addressed this: continuous tracking isn’t required. Second, the app has to work offline. It should queue the visit and submit it once the signal returns.
Telephony capture uses the client’s own phone. The caregiver calls a number at arrival and again at departure, and the calling number verifies the location. This method serves clients whose homes have no reliable mobile signal, and caregivers without a suitable device. It’s not a legacy option. It stays genuinely necessary.
Fixed visit verification uses a small device placed in the client’s home. It produces codes that the caregiver records and later submits. This method covers the cases the other two can’t reach.
There’s a design consequence to all of this. The visit record itself has to be method-agnostic. Downstream logic, including authorization matching, aggregator submission, billing, and payroll, shouldn’t need to know how a visit was verified. That means the caregiver capture app needs to normalize all three methods into one internal representation before anything downstream touches the data. Queuing a visit offline and normalizing it against telephony and fixed-device records is the harder half of custom mobile app development in this vertical.
Aggregator Feeds: Sandata, HHAeXchange, and the State Model
This is the highest-value section in this article, and it starts with a question that has to be answered before anything else.
Establish the Model Before the Integration
States operate different EVV models. Some run closed or state-mandated vendor systems. Others run open provider-choice models. Some offer an open model with a free state-provided option. Others use an MCO-choice model. This determination decides whether a custom platform can serve as the EVV system at all for Medicaid visits in that state, or whether it has to hand off to a designated system instead. This needs to get confirmed with the state Medicaid agency, on a per-state basis, before any scoping begins. It’s the single most consequential unknown in this vertical. Getting the answer wrong can turn a planned build into a much smaller integration than expected.
Submitting to the Aggregator
Where a provider-choice model applies, the platform transmits visit records to the state’s aggregator. Sandata publishes an alternate-EVV specification for third-party systems. HHAeXchange operates its own onboarding path. Netsmart, CareBridge, Therap, and Fiserv’s AuthentiCare appear in other states. Each aggregator has its own specification, its own testing process, and its own certification or approval step. Current requirements, timelines, and any fees need direct confirmation. Onboarding sits squarely on the critical path here, not off to the side.
Multi-State Agencies Multiply Everything
An agency operating in four states may face four different EVV models, potentially several aggregators, and different data expectations for what is technically the same visit type. This is the largest structural cost multiplier in the entire vertical. It should get established before any estimate goes out, not discovered partway through one.
Rejection Handling and Reconciliation: Where the Money Is
Submitting a visit is not the same as having it accepted. In many states, a visit that fails validation cannot be billed. That makes the rejection queue a revenue queue, not a technical footnote.
Rejections tend to arrive for predictable reasons. A caregiver identifier might not match the state’s record. A client identifier might mismatch. A service code might not correspond to the authorization on file. Visit times might overlap another visit. A visit might get submitted outside its permitted window. Or a required element might simply be missing.
The platform needs to handle each of these well. Every rejection should surface with a plain-language reason and a clear owner. There should be a correction path that resubmits cleanly, without creating new errors. And there should be an aging view, so nothing sits past the window in which it can still be fixed. Those queues and views sit in the office console delivered through custom web application development.
Reconciliation itself should be routine, not investigative. Visits scheduled should reconcile against visits captured. Captured should reconcile against submitted. Submitted should reconcile against acceptance. Accepted should reconcile against billed. Each gap in that chain carries a dollar value, and each one should be visible daily, not discovered at month end.
The metric worth designing toward is straightforward: the proportion of delivered visits that reach an accepted state on first submission, tracked by state and by branch.
Caregiver Payroll Sync
Payroll integration in home care works a little differently than in most industries. The visit record is simultaneously the billing source and the wage source, but the two calculations aren’t the same. Billable time and payable time diverge routinely. Travel between clients is generally payable but rarely billable. Training and meeting time is payable, not billable. An unauthorized visit may still be payable, even if it can’t be billed.
Because of this, the platform needs a pay calculation layer that stays distinct from the billing layer. It should apply rates by client and service, along with differentials, holiday rules, overtime calculated across the full week, mileage, and travel time.
From there, the platform needs to export to the agency’s payroll provider, whether that’s ADP, Paychex, Gusto, QuickBooks, or another system. A review and approval gate should sit before anything transmits. The platform should also keep a record of exactly what was sent, so a caregiver’s payroll question can be answered without reconstructing the whole calculation from scratch.
Design for the correction case too, since it’s common. A visit adjusted after payroll has already run needs a defined retroactive path. It shouldn’t come down to a manual note to the bookkeeper.
Wage-and-hour rules carry real legal weight, and they should be reviewed with employment counsel. The platform’s job is to implement the agency’s determinations, not to make those determinations itself.
Family Portal APIs and Notifications
The family portal is mostly a read surface over the same visit and care data the agency already has. That makes access control the real design problem here, not data access. It comes down to per-person permissions, a record of who authorized each person’s access, and the ability to reflect the client’s own preferences about what gets shared.
Notification delivery needs to work across email, SMS, and push, with per-person preferences and clear opt-out handling. Getting the volume right matters a lot. Families want to hear about real changes, not every routine event. Over-notification trains people to ignore the channel that eventually carries the important message.
Payment integration matters for private-pay families too. Card-on-file handling should keep card data off the agency’s own systems entirely, which also minimizes PCI scope.
If the portal gets exposed as an API, whether for a mobile app or a referral partner, it needs its own authentication, its own rate limiting, and its own audit logging. It shouldn’t just inherit the back office’s assumptions.
State count and EVV model turn out to be the dominant cost variables in a build like this, and that’s covered in full in Cost to Build a Custom Home Health and Caregiver EVV Platform. [Link to C4]
Holding It Together: Queues, Failure, and Daily Reconciliation
The chain from scheduled visit to paid claim, and eventually to paid caregiver, has several places where a record can quietly stop moving. A visit might get captured on a device that never synced. It might sync but never submit. It might submit but get rejected. It might get accepted but never billed. Or it might get billed but never posted.
Each of these failure points needs its own queue, with an age attached and a named owner. It shouldn’t depend on someone running a report when the numbers start looking wrong.
Daily reconciliation across the full chain is what keeps a mixed-state, mixed-payer operation honest. That means checking scheduled against captured, captured against submitted, submitted against accepted, accepted against billed, billed against paid, and separately, paid against paid to the caregiver. In an agency running thousands of visits a week, even a small silent failure rate adds up to a large number by year-end.
Final Thoughts
Everything in this article comes back to a few core decisions. Settle the state model question before scoping anything. Design capture to be method-agnostic from the start. Treat the rejection queue as a revenue queue, with a real owner attached. Build payroll as a calculation distinct from billing, not a byproduct of it.
Agencies and product teams that get these decisions right end up with a platform where the visits delivered are the visits paid. That holds true in both directions: caregivers get paid accurately, and the agency gets billed accurately too.
If EVV sits at the center of your operation, establishing your state’s model and your aggregator’s onboarding requirements before anything gets estimated is what keeps the integration work from becoming the reason the project slips. It’s the kind of groundwork NewAgeSysIT walks agencies through before a single line of code gets written. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.
