Vera

Vera is a workspace for small home care agencies: one place to manage visits, caregivers, and the record of care each patient receives. Every visit is backed by evidence (who was there, when, and what care was delivered), so the moment a visit is verified, the claim is ready to submit. No chasing paperwork, no double data entry.

Live demo: vera-homecare.vercel.app

Small home care agencies mostly run on software that is broad, expensive, and disconnected. From interviews with agency owners in Philadelphia, their top pain points were managing caregiver onboarding documents, knowing when caregivers are actually with patients, and collecting patient signatures. Vera focuses on one clean, connected flow from scheduled visit to billable record, built caregiver-first, because caregivers are the bulk of the workforce and the source of every record the office depends on.

The visit verification core is modeled on Electronic Visit Verification (EVV), which is federally required for Medicaid-funded home care under the 21st Century Cures Act.

Demo disclaimer: this is a portfolio MVP inspired by EVV. It is not certified EVV software, it makes no HIPAA claims, and all data is fictional. Data lives in memory and resets on refresh by design.

For the administrator:

• Dashboard: every visit with its pipeline status, needs-review visits first
• Visit detail: check-in and check-out times, assessment, and signature; a flagged visit derives and lists exactly what evidence is missing
• Billing: ready-to-bill visits with hours worked and estimated cost, one-click mock claim submission, and a submitted-claims register with claim references
• Caregivers: team roster, add-caregiver form, and a per-caregiver onboarding document checklist (signed, pending, expiring) with a derived cleared-to-work badge; pending documents accept a cursive signature capture

For the caregiver (phone-width surface, one primary action per screen):

• Check in on arrival; the system stamps the time and records the device's location when the caregiver allows it. A refused or unreachable location is recorded as unavailable, with the reason, and never blocks the check-in
• Check out with a visit assessment and the patient's typed signature
• Checking out without a signature warns first, then flags the visit for review instead of blocking the caregiver from leaving
• Missing evidence can be supplied later, which is the only way a flagged visit becomes billable

Around the app:

• Home: product intro and a simulated sign-in (no account needed)
• About: the home care industry in numbers, from cited primary sources
• Responsive layout: tablet breakpoint, and a phone breakpoint where the sidebar collapses behind a menu button

scheduled → in progress → ready to bill → billed
                        ↘ needs review ↗

Every transition has a cause: check-in, check-out with an evidence check, evidence supplied, claim submission. Three rules are enforced in the service layer:

1. A visit is billable only when all four pieces of evidence exist: check-in time, check-out time, assessment, signature. Anything missing routes it to needs review.
2. Only supplying the missing evidence clears a flag. There is no admin override, because clicking a button does not create a signature.
3. Timestamps are stamped by the system when the event happens, never typed by a user. A typed timestamp would be fabricated evidence.

• Vite + React (JavaScript), React Router, CSS Modules. No UI libraries.
• All data access goes through a service layer (src/services). Components never import mock data directly. The services expose async functions with realistic latency, so a real backend can replace the mock internals without changing a single component.
• Mutations are domain verbs (checkInVisit, checkOutVisit, supplyEvidence, submitClaim, addCaregiver, signDocument), and state transition rules live inside them, not in components.
• Derived state over stored flags: the missing-evidence panel and the cleared-to-work badge are computed from the data at render time, so they can never disagree with the record.
• locationService sits alongside the data services but is a device adapter, not a repository: no backend will ever replace it, because the device is the only authority on where it is. It resolves a result object rather than rejecting, since a refused permission is an ordinary outcome of a real check-in and not an exception.

npm install
npm run dev

Production build: npm run build.

Automated testing was out of scope for this phase, so testing is a scripted manual pass run before each merge:

• A distinct status between verified and billable once payer and authorization rules arrive with a real backend
• Persistence: localStorage first, then a real API behind the same service contracts
• Location at check-out as well as check-in, and a review surface that surfaces visits whose location was never captured
• Drawn signature capture
• Document expiration dates, with the expiring status derived from them and a renewal flow
• A caregiver home screen ("my visits today") and role-based views
• Patient records: standing concerns, and prescriptions under a future skilled-care path
• Real claim submission and remittance (837 and 835) to a payer or clearinghouse, replacing the mock
• Stripe test-mode collection for private-pay clients
• Automated tests: Vitest and React Testing Library for services and components, Playwright for the visit flow end to end