EVV Integration for Home Care Software
Your caregivers verify visits in the field. Now that data has to reach your state's aggregator, in the right format, before the deadline.
We build the EVV layer — the mobile capture, the data mapping, and the connection to your state's system — so visits get accepted instead of rejected.
What EVV actually requires
Under the 21st Century Cures Act, Medicaid-funded personal care and home health services must be verified electronically. Every visit record needs six things:
- Type of service performed
- Who received it
- Date of service
- Location of service delivery
- Who provided it
- When the visit started and ended
Miss any of those and the record can be rejected. In many states, a rejected visit is an unpaid visit.
Every state is different
Collecting the data is the easy part. There is no national standard on the other end.
- Every state picks its own aggregator, or lets providers choose their own vendor
- Every state publishes its own data dictionary, file format, and rounding rules
- Closed models require the state's vendor; open models let you submit from your own platform
- Deadlines, rejection handling, and correction windows differ by state
How we start an aggregator integration
The work starts well before any integration code.
1. Map the data
Your service codes, payer identifiers, and rounding rules, mapped to the state's data dictionary.
2. Confirm the channel
REST API, SOAP, or a delimited file over SFTP. We've worked with all three patterns.
3. Build and test
Against the aggregator's sandbox where one exists, and a local emulator where it doesn't.
4. Test the ugly paths
Correction and resubmission, not just the happy path. That's where integrations fail.
What takes the time isn't the transport. It's the data mapping and the exception handling around it.
What we build
Mobile visit verification
GPS check-in and check-out with geofencing, offline capture that syncs when the device reconnects, and a telephony fallback where GPS won't resolve.
Aggregator submission
API or file-based submission mapped to your state's specification, with reconciliation reports so you can see what landed.
Exception handling
Missed clock-ins, manual edits with reason codes, and supervisor approval flows that hold up in an audit.
Rejection recovery
We parse the aggregator's response, surface rejected visits in a work queue, and support resubmission before the correction window closes.
Compliance reporting
Dashboards that tie visit data to payroll and billing, so the office isn't reconciling by hand.
Supporting the mobile side
If you don't already have a caregiver app, we build the capture layer too. See caregiver app development.
The things that usually break
- GPS drift inside apartment buildings and care facilities
- Time zones and daylight saving across a multi-state operation
- Rounding rules that differ from state to state
- Backdated edits that need a clean audit trail
- Caregivers working in areas with no signal
- Duplicate submissions when a retry fires twice
- Payer and service code mapping on the aggregator side
- Visits that pass locally but get rejected after submission
How an EVV engagement runs
- Discovery — we confirm your state, your model (open or closed), and pull the aggregator's current specification
- Data mapping — your service codes, payers, and rounding rules mapped to the spec
- Build and test — against the aggregator's sandbox where available, and an emulator where it isn't
- Go live — with reconciliation reports and a rejection work queue from day one
We sign a BAA before touching any PHI. You own the code.
What we don't have yet
We haven't integrated with a US state aggregator. Our EVV work has been on care platforms operating in China, and this would be our first US integration.
What transfers is the part that takes the most time: visit exception handling, GPS tolerance, offline capture, audit trails, and data-mapping discipline. What doesn't transfer is your state's specification — we'd build that from the current documentation, with your team, before committing to a timeline.
Common questions
Have you integrated with US state aggregators before?
No. Our EVV work so far has been on care platforms operating in China, and US state aggregators are new to us. We're telling you up front because you'd find out on the first call anyway.
What transfers is the part that actually takes time: visit exception handling, GPS tolerance, offline capture, audit trails, and data-mapping discipline. What doesn't transfer is your state's specific specification. We'd build that from the current documentation, with your team, before committing to any timeline.
Do you guarantee we'll be compliant with our state?
No, and be careful with anyone who says they do. Compliance and attestation sit with the provider. We build to the specification, test against the aggregator's sandbox where one is available, and give you the audit trail to demonstrate it.
Can you integrate with our existing agency software?
Usually. If your system already captures visits, the work is mostly mapping and submission. If it doesn't, we add the mobile capture layer too.
We're a healthtech company, not an agency. Can you help?
Yes. We build EVV as a module inside your product, including the multi-state and multi-aggregator handling that agencies will ask you for.
How long does an integration take?
A single-state integration usually runs 8–14 weeks. Multi-state is longer. It depends on whether the aggregator provides a sandbox and how clean your service and payer mapping is. We'll give you a written estimate after we've read your state's specification.