01 — Full specification and component decisions

Encore EVV — complete component and decision matrix

Master spec · April 2026
Area Component / Decision Implementation approach Notes Status
Core architecture
Architecture model Split-data biometric model Biometric data (facial embeddings, match scores, attempt logs) stays internal on Encore's system. Only the 6 federally required EVV fields transmit to the state aggregator. Each visit carries a Biometric Success ID linking the internal biometric record to the aggregator visit record for audit. Aggregators are not equipped to ingest biometric templates. Biometrics are the internal proof layer — EVV fields are the compliance submission layer. Confirmed
Build approach Offline-first · React Native hybrid Single React Native codebase for Android tablet APK and caregiver phone app. Full functionality without internet. All data stored locally in AES-256 encrypted storage and synced when connectivity is restored. Timestamp recorded at scan, never at sync. Timestamp-at-scan is a hard EVV compliance requirement — aggregators require actual visit time, not upload time. Confirmed
Backend Node.js / NestJS + PostgreSQL NestJS structured module architecture appropriate for compliance-heavy requirements. PostgreSQL with AES-256 encryption at rest. Encryption keys stored separately from visit records. All API and aggregator transmissions TLS 1.2 minimum, TLS 1.3 preferred. Confirmed
Verification logic 3-gate checkout logic At check-out, three gates run in sequence: (1) GPS matches patient's registered home address → auto-approve, (2) GPS matches an approved location from the care plan → auto-approve, (3) patient biometric confirms co-presence regardless of GPS → auto-approve. Any single gate passing clears the shift. All three failing triggers a flagged evidence package for coordinator review. Non-blocking by design. Caregiver is never prevented from proceeding — shift is logged and flagged. Confirmed
Sequence enforcement Aggregator ACK gates claim Claim generation is programmatically blocked until the state aggregator's acknowledgement is logged against the shift record. Cannot be manually bypassed. Prevents claims being submitted without verified EVV data — the root cause of most EVV-related denials. Confirmed
Biometric system
Biometric SDK FaceSDK — on-device FaceSDK processes biometric capture fully offline on the Android tablet and caregiver phone. Raw photos converted immediately to encrypted mathematical embeddings on-device. Raw images never stored — not on device, not on backend. Embeddings stored server-side, encrypted. On-device processing required for offline-first architecture. BAA to be executed with FaceSDK vendor before any live patient data is handled. Confirmed — FaceSDK
Caregiver enrollment 3-angle face enrollment One-time facial enrollment on caregiver's personal phone prior to first shift — front, left, right angles. Raw images converted to encrypted embeddings immediately, originals deleted. Account remains Inactive until a coordinator manually activates the profile. Coordinator activation gate prevents unauthorised device access. Must comply with HIPAA and applicable Ohio/PA biometric privacy laws. Confirmed
Patient biometric Provisional photo → live upgrade Family uploads baseline photo at intake — immediately converted to embedding, original deleted. On the patient's first real shift, the kiosk captures a live scan that automatically upgrades the profile to high-fidelity. No coordinator action needed for the upgrade. HIPAA data minimisation: raw images are never stored long-term. Coordinator reviews initial photo quality before first shift. Confirmed
EVV verification method code BIO code — pending confirmation Sandata's Alt-EVV V5.0 schema includes a VerificationMethod field. If Ohio supports a BIO code, Encore EVV submits with it. If BIO is not yet supported, visits submit as MVV (GPS/Mobile Visit Verification) — satisfying the GPS compliance requirement — while the biometric match is retained as an internal audit flag only. Action required: confirm with Sandata / Ohio ODM which VerificationMethod codes are supported before build. Email: [email protected] Open — confirm Sandata
Hardware and device management
Tablet hardware Android kiosk tablet · one per caregiver Dedicated Android tablet per caregiver. Wintouch A10 or equivalent. MDM-locked to single-app kiosk mode. Caregiver carries the tablet to every visit — tablet never lives at the patient's home. 10,000mAh power bank standard issue. Spare tablet pool maintained at the office. See tablet procurement section for pricing and MOQ details. Front camera required for biometric scan. Caregiver-carries model confirmed. Confirmed
MDM platform ManageEngine (recommended) or Jamf MDM enforces Android single-app kiosk lock. Blocks home button, status bar, quick settings, and notifications. OTA updates pushed overnight. Zero-touch enrollment via Android Zero-Touch portal — tablets auto-configure on first Wi-Fi connection. MDM heartbeat feeds coordinator dashboard with live device status. Remote wipe, lock, and location tracking enabled. See MDM comparison below. ManageEngine recommended for initial Ohio fleet. Revisit at scale. Decision required
EVV aggregator integration
Ohio routing All patients → Sandata Ohio Ohio's sole EVV aggregator. All Ohio patients regardless of payer (FFS, Aetna, Buckeye, CareSource, Humana, Molina, United) route to Sandata. EVV data formatted to Sandata Ohio Alt-EVV technical spec and transmitted in near real-time. Ohio is the target go-live state. Single aggregator — simpler certification path. Contact ODM immediately to enter the certification queue. Confirmed
Pennsylvania FFS FFS + waivers → Sandata PA PA fee-for-service and waiver patients (ACT150, DDD) route to Sandata under PA DHS configuration. Same vendor as Ohio, separate state configuration and separate certification. PA is the second certification phase after Ohio is live and stable. Confirmed
Pennsylvania MCO MCO patients → HHAeXchange PA MCO-managed patients (AmeriHealth, UPMC, Highmark, Health Partners, PA Health & Wellness, United) route to HHAeXchange. HHAeXchange automatically forwards to Sandata for PA DHS reporting — no double-submission needed. Contact: [email protected] to initiate alternate vendor setup. Confirmed
Routing logic Payer-driven automatic routing The payer/plan field captured at patient intake permanently determines which aggregator receives every future shift for that patient. No manual routing decision per visit. Routing table: Ohio + any plan = Sandata Ohio. PA + FFS/waiver = Sandata PA. PA + MCO = HHAeXchange. Payer/plan is a required field at intake. Must be set before patient's first visit. Confirmed
835 ERA mapping Remittance mapped to shift records When the 835 ERA returns from Medicaid/MCOs, Encore EVV maps payment status (Paid / Denied / Short-paid) and denial reason codes back to the original shift record. Denied claims surfaced in the dashboard with reason code and correction path. Eliminates blind billing disputes. Billing team resolves EVV-related denials directly from the dashboard. Confirmed
Billing platform AxisCare — billing only AxisCare retained as billing backend only — not the EVV capture system. Data flow: Encore EVV → Sandata/HHAeXchange → AxisCare billing/claims submission. Confirmation required from AxisCare that their billing module can accept externally verified EVV records before build scope is finalised. Pending AxisCare API confirmation
Consent, compliance and legal
Biometric consent Explicit consent at intake — required Patient intake must include explicit, timestamped digital acknowledgement for: facial scanning at each visit, facial embedding storage in Encore's encrypted system, and biometric data used solely for shift verification. Checkbox with timestamp is minimum. Stored as immutable ePHI, 6-year minimum retention. Legal requirement in many states. HIPAA best practice regardless. Consent renewed if legal guardian changes. Confirmed
GPS consent Ohio ODM mandatory — separate consent Ohio requires signed patient consent before GPS coordinates can be captured (ODM form 10375 equivalent). Without consent, location logged as "home" or "community" only — no coordinates captured or transmitted. Patient record flagged as GPS-consent-pending. Consent renewed annually. Pennsylvania also requires GPS consent. Covers location at check-in/out and caregiver GPS breadcrumb data. Confirmed
HIPAA NPP Notice of Privacy Practices — at intake Federal requirement. Intake form includes acknowledgement of Encore Care's HIPAA Notice of Privacy Practices before any ePHI is collected. Timestamped and stored as immutable ePHI, 6-year minimum retention. All three consent types (biometric, GPS, HIPAA NPP) captured in step 2 of the patient intake flow. Confirmed
Proxy / POA handling Coordinator review gate For patients lacking capacity, a legal guardian or POA completes all consent sections. Coordinator reviews and uploads POA document or guardianship order in the patient record, then manually activates the patient profile. Patient cannot have first visit scheduled until coordinator marks proxy documentation as reviewed and on file. Coordinator review gate closes the loophole of unverified proxies completing a web form. All proxy consents stored as immutable ePHI. Confirmed
Exception handling and fraud prevention
Scan failure 3 attempts → flag and mandatory note Maximum 3 biometric scan attempts. After 3 failures: shift is logged and flagged. Caregiver must submit a mandatory, immutable free-text note before screen dismisses. Note becomes part of the coordinator evidence package. Caregiver is never blocked from proceeding — care is never interrupted. Shift continues as flagged. Surfaces in coordinator queue for review with full evidence package. Confirmed
Biometric exemption Coordinator-set patient exemption flag Coordinator can mark a patient profile as biometric-exempt (e.g. severe physical limitations). All future shifts for that patient skip the patient scan step and route to supervisor spot-check protocol. Exempt flag stored on patient profile, not the shift record. Exempt shifts reported separately from biometric-failed shifts in all compliance reports. Confirmed
Internal fraud prevention Coordinator cannot approve own shifts Hard API-level constraint prevents any coordinator from approving a flagged shift where they are also listed as the active caregiver. Enforced at API level — cannot be bypassed by frontend manipulation. Essential for internal fraud prevention and Medicaid audit integrity. Confirmed
Family anti-collusion Read-only family portal — API enforced Families can view verified shift histories and opt into arrival/departure notifications. Hard API limits prevent families from adding approved locations, editing care plans, or approving/rejecting shifts. Prevents coordination between caregivers and families to fabricate visits. Confirmed
HIPAA and security
Encryption AES-256 at rest · TLS 1.3 in transit AES-256 for tablet local storage, backend database, and biometric embeddings. Encryption keys stored separately from visit records. TLS 1.2 minimum, TLS 1.3 preferred for all transmissions. Every EVV transmission is a transfer of ePHI — encryption applies end-to-end. Confirmed
Access control MFA + RBAC + auto-logout Unique user IDs and MFA for all coordinator/admin access. RBAC enforced at API level. Auto-logout: 15 min dashboard, 30 min phone app, 60s kiosk tablet. Auto-logout timers required for devices handling ePHI in patient homes. Confirmed
Audit logging Immutable audit logs · 6-year retention Every read and write action involving ePHI generates an immutable audit log: user ID, action type, record ID, timestamp. Cannot be edited or deleted by anyone including admins. All coordinator decisions permanently appended to evidence packages as immutable entries. Confirmed
May 2026 HIPAA updates Asset register + 72hr incident response Living inventory of every asset touching ePHI — tablet serial numbers, MDM status, cloud servers, SDKs, APIs. Documented and tested 72-hour system restoration and breach notification plan. Annual pen testing infrastructure built in from day one. New mandates effective May 2026. Must be architected for compliance from the first sprint. Confirmed
HIPAA Risk Assessment Third-party external assessment Mandatory third-party HIPAA Risk Assessment must be completed before any live patient data is handled. Cannot be self-certified. Completed against the staging environment before Ohio go-live. Cost paid to external assessor firm ($5K–$15K). Budgeted separately from build cost — see costs table. Required pre go-live
SOC 2 Type II External audit — begin at staging Engage external audit firm when staging is live. 6–12 month observation window required before certification can be issued. The clock starts when controls are in place — not when the decision is made. Cost paid to external audit firm ($20K–$50K). Starting the observation period early is the only way to compress time to certification. Required — begin at staging

MDM platform — ManageEngine vs Jamf

Decision required before tablet procurement

Both platforms support Android zero-touch enrollment, kiosk lock enforcement, OTA updates, remote wipe/lock, and MDM heartbeat APIs. The decision is primarily cost vs enterprise depth.

ManageEngine MDM

Recommended · Lower cost
✓
Lower cost — ~$3–5/device/month vs Jamf's $7–10
✓
Adequate Android kiosk enforcement for this use case
✓
Zero-touch enrollment and OTA push supported
✓
REST API available for heartbeat integration into coordinator dashboard
✓
Faster onboarding for mid-size fleets (50–500 tablets)
✗
Less robust compliance reporting depth compared to Jamf
✗
Smaller support organisation — longer resolution times for edge cases

Jamf Pro

Alternate · Enterprise-grade
✓
Industry-leading enterprise policy management and enforcement depth
✓
Stronger compliance reporting — better positioned for SOC 2 audit trail
✓
Larger support organisation, dedicated customer success
✓
Better long-term scalability for large caregiver fleets
✗
Higher cost — $7–10/device/month (~$4,200–$6,000/yr at 50 devices)
✗
Longer initial configuration and onboarding time
Recommendation
Start with ManageEngine for the Ohio launch. At initial scale, ManageEngine delivers adequate control at materially lower cost. Architecture supports a migration to Jamf later without rebuilding — the MDM heartbeat API integration in the coordinator dashboard is vendor-agnostic. Revisit when fleet exceeds 300 devices or when SOC 2 audit requirements create a case for Jamf's reporting depth.
02 — Technology stack

Confirmed technical decisions

All layers confirmed
Frontend — Tablet + Phone
React Native (hybrid)
Single codebase for Android tablet APK and caregiver phone app. MDM kiosk lock runs at OS level.
Backend + API
Node.js / NestJS
Encrypted PostgreSQL database. Structured module architecture for compliance-heavy requirements and multi-role access control.
Biometric SDK
FaceSDK — confirmed
On-device facial recognition. Fully offline on Android. Raw photos never stored. HIPAA-compliant. BAA required before go-live.
MDM Platform
ManageEngine (recommended)
Android zero-touch, kiosk profile, OTA updates, heartbeat API. Final decision required before tablet procurement.
Patient portal + Family
Mobile-optimised web
No app download. SMS/email link. Pre-filled from coordinator intake. Accessibility-first.
Encryption
AES-256 · TLS 1.3
Local storage, backend database, and embeddings all AES-256. Keys separated from records. TLS 1.3 preferred in transit.
Aggregator integration
Sandata + HHAeXchange
FHIR / EDI 837P formatted payloads. 6 EVV fields only transmitted. Biometrics never leave Encore's system.
Tablet hardware
Wintouch A10 · ~$75–85/unit
Android-based. Front camera required. One per caregiver. Initial batch for Ohio launch.
Billing backend
AxisCare (billing only)
Retained for claims processing. Encore EVV replaces AxisCare's EVV capture module only. API confirmation pending.
03 — Platform modules — full spec
Module A

Tablet app — kiosk, caregiver-facing (Android)

  • App runs in Android single-app kiosk lock enforced by MDM. No home button, status bar, or settings access. Remote wipe and lock available via MDM.
  • MDM heartbeat feeds coordinator dashboard. Footer shows "Online · MDM managed" or amber warning if MDM connection or GPS drops.
  • Check In triggers simultaneous front camera biometric capture and background GPS — no secondary user action required.
  • After caregiver scan confirms, screen transitions automatically to patient scan. Patient looks at camera — no tapping. 30-second timeout triggers retry prompt. Large font (20px+), high contrast, zero small touch targets for elderly users.
  • Successful dual scan triggers 5-second confirmation flash. Shift record is sealed as immutable at this exact moment. No edits permitted after sealing.
  • Active shift screen (A4b): Persistent display of caregiver name, patient name, running timer (server-calculated — survives tablet restart). Check Out only on this screen, not on idle home screen.
  • 3 biometric scan attempts maximum. After 3 failures: shift logged and flagged, caregiver must submit mandatory immutable note before screen dismisses. Caregiver never blocked from proceeding.
  • Offline mode: AES-256 encrypted local storage, auto-syncs on connectivity restore. Timestamp at scan, not at sync.
  • GPS breadcrumb trail captured passively every 15–30 minutes via caregiver phone app throughout the shift.
Module B

Caregiver phone app — personal device

  • One-time biometric enrollment: 3 face angle captures on caregiver's own phone. Raw photos immediately converted to encrypted embeddings server-side. Raw images never retained.
  • Account remains Inactive until a coordinator manually activates the profile. Caregiver cannot use the kiosk tablet until activated.
  • Visit history from backend. Status badges (Verified / Flagged / Pending) reflect live record state. Weekly/monthly hours calculated server-side from sealed verified shifts only — flagged shifts excluded until adjudicated.
  • Passive GPS sync indicator shows whether data is queued locally or synced to backend.
  • Flagged shift detail: shows exact flag reason, timestamps, GPS trail. Caregiver submits mandatory note. Note locked on submission, becomes part of coordinator evidence package.
Module C

Patient intake and family portal — mobile web

  • SMS or email link — no app download required. Fields pre-filled from coordinator intake, family completes the gaps.
  • Payer/insurance plan field is required and drives all future aggregator routing for this patient.
  • Three mandatory consents — timestamped, immutable ePHI, 6-year retention: biometric data consent, GPS/geolocation consent (Ohio ODM mandatory), HIPAA NPP acknowledgement.
  • Proxy/POA flow: Coordinator reviews and uploads POA documentation, then manually activates patient profile. First visit cannot be scheduled until proxy documents are marked as reviewed and on file.
  • Photo upload: converted to facial embedding on upload, original deleted. Coordinator reviews photo quality before first shift is activated.
  • Family portal: strictly read-only. API-enforced — families cannot add approved locations, edit care plans, or approve/reject shifts.
Module D

Coordinator and admin dashboard — web

  • Four real-time KPI tiles: Active shifts, Verified today (auto-approved only), Flagged (action required), Offline devices (from MDM heartbeat).
  • Flagged queue sorted by urgency: Review needed → Pending note → Warning.
  • Evidence package auto-generated per flagged shift: timestamps, GPS trail, biometric match scores or failure codes, caregiver note. Downloadable as PDF for disputed Medicaid claim defence.
  • Coordinator decision generates immutable audit log: coordinator ID, timestamp, optional written reason. Permanently appended to evidence package.
  • API-level constraint: coordinator cannot approve a shift where they are also the active caregiver.
  • Biometric-exempt flag, manual shift close, MDM device monitoring, compliance reports with date-range filters, CSV export, bulk evidence package download.
  • 835 ERA remittance: payment status mapped to individual shift records. Denied claims surfaced with reason code and correction path.
04 — Back-office architecture and EVV data pipeline

End-to-end — from scan to paid Medicaid claim

4 phases · each gates the next
Phase 1 — Capture

On-device data collection

Tablet captures face biometric and GPS simultaneously on Check In. GPS breadcrumb trail captured every 15–30 min via phone app. If offline: AES-256 encrypted local queue, auto-syncs on reconnect. Timestamp at scan, not at sync.

Phase 2 — Verification engine

3-gate logic + immutable decision

FaceSDK match service processes captured face data against stored profiles. Rule engine runs 3-gate checkout logic. Any single gate passing → auto-approve. All three failing → flag with auto-generated evidence package. Decision sealed as immutable.

Phase 3 — EVV aggregator export

6 fields transmitted · near real-time

Verified shift records formatted to FHIR / EDI 837P payloads containing exactly the 6 mandated EVV fields. Transmitted to Sandata or HHAeXchange per payer routing. Encore EVV awaits acknowledgement, logs it against shift record. "Not Accepted" visits surfaced with error codes.

Phase 4 — Billing and payment

Aggregator ACK unlocks claim

Aggregator acknowledgement unlocks claim generation. Data passed to AxisCare for submission to Ohio Medicaid / PA DHS / MCO. When 835 ERA returns, payment status mapped back to the original shift record. Full loop: biometric scan to cash received.

Open — VerificationMethod code
Confirm with Sandata / Ohio ODM whether the BIO VerificationMethod code is supported in the Ohio Alt-EVV schema before build begins. If BIO is not available: submit as MVV (GPS), retain biometric match as internal audit flag only. Contact: [email protected]
AxisCare integration
Confirmation required from AxisCare that their billing module can accept externally verified EVV records from Encore EVV. AxisCare is the billing backend only. Without API confirmation, Phase 4 scope cannot be fully defined. Pre-build blocker.
05 — Aggregator routing and certification path

Routing logic — set at intake, automatic per shift

No manual routing decisions per visit
StatePayer typeAggregatorNotes
Ohio All — FFS and MCO (Aetna, Buckeye, CareSource, Humana, Molina, United) Sandata (Ohio) Ohio's sole EVV aggregator. All payers unified under one integration. Target go-live state.
Pennsylvania Fee-for-service + waivers (ACT150, DDD) Sandata (PA DHS) Same vendor as Ohio, separate state config and separate certification process.
Pennsylvania MCO (AmeriHealth, UPMC, Highmark, Health Partners, PA Health & Wellness, United) HHAeXchange HHAeXchange forwards to Sandata for DHS reporting automatically. No double-submission needed.

Certification path — Ohio first, then Pennsylvania

Required before live data transmission
Ohio — step 1

Contact ODM immediately

Reach out to Ohio ODM EVV team while build is still in progress. Email: [email protected] · Phone: 855-805-3505. Wait times exist — getting in the queue early is critical.

Ohio — step 2

Build to Sandata Ohio spec

Follow Ohio Alternate EVV technical specifications on the ODM EVV webpage. Register at sandatalearn.com using provider ID 9999999 as placeholder during testing.

Ohio — step 3

API sandbox testing

Submit test visit records across all scenarios: standard visit, missed visit, manual edit, offline sync, exception handling. API conformance test — not a legal audit.

Ohio — step 4

ODM confirms → Ohio go-live

ODM certification confirms Encore EVV can transmit live Ohio EVV data. Budget 2–4 months from first ODM contact to confirmed certification.

Pennsylvania — Sandata PA

PA DHS — separate state config

Build to PA Sandata spec (separate from Ohio). PA DHS Provider Assistance Center: 800-248-2152.

Pennsylvania — HHAeXchange

Alternate vendor integration

Contact [email protected]. They assign an integrations team member. Run test records through the HHAeXchange sandbox in parallel with Sandata PA.

Certification timeline
Budget 2–4 months per state from first contact to confirmed go-live. This process runs in parallel from Week 3 of the build — not sequential to it. ODM and PA DHS queues have wait times. Ohio certification contact must be initiated at Week 3, not after the build is complete. Do not communicate go-live dates to patients, staff, or stakeholders without factoring this timeline in.
06 — HIPAA compliance — 2026 requirements

EVV data boundaries — what stays internal vs what transmits

Biometric transmission requirements — to be verified with states
Data typeSystemTransmitted to aggregator?
Facial embeddings (caregiver + patient) Encore EVV — internal To be verified with Ohio and PA aggregators
Biometric match scores Encore EVV — internal To be verified with Ohio and PA aggregators
Biometric attempt logs Encore EVV — internal audit trail To be verified with Ohio and PA aggregators
Type of service Encore EVV → Aggregator Transmitted — EVV field 1
Recipient Medicaid ID Encore EVV → Aggregator Transmitted — EVV field 2 · PHI
Date of service Encore EVV → Aggregator Transmitted — EVV field 3 · PHI
GPS location coordinates Encore EVV → Aggregator Transmitted — EVV field 4 · PHI · requires written consent
Caregiver staff ID Encore EVV → Aggregator Transmitted — EVV field 5 · PHI
Time in / time out Encore EVV → Aggregator Transmitted — EVV field 6 · PHI
Biometric transmission — open question
The current architecture assumes biometric data stays internal and only the 6 EVV fields transmit to aggregators. However, individual state requirements for biometric data handling and optional transmission need to be confirmed with Ohio ODM (Sandata) and Pennsylvania DHS (Sandata PA / HHAeXchange) before the Phase 3 data pipeline is finalised. The VerificationMethod field in the Sandata schema may or may not support a BIO code in each state's configuration. Confirm this before Sprint 3 begins.

Technical safeguards — required at launch

Encryption

AES-256 at rest · TLS 1.3 in transit

AES-256 for tablet local storage, backend database, and biometric embeddings. Keys stored separately from visit records. TLS 1.2 min, TLS 1.3 preferred for all transmissions.

Access control

MFA + RBAC + auto-logout

Unique user IDs and MFA for all coordinator/admin access. RBAC at API level. Auto-logout: 15 min dashboard, 30 min phone app, 60s kiosk tablet.

Audit logging

Immutable logs · 6-year retention

Every ePHI read/write generates an immutable audit log. Cannot be edited or deleted by anyone including admins.

May 2026 HIPAA updates

Asset register + 72hr incident response

Living inventory of every asset touching ePHI. Documented 72-hour restoration plan. Annual pen testing built in from day one.

Pre go-live requirements
Two external compliance requirements before live patient data is handled: (1) BAAs executed with all vendors — FaceSDK, cloud host, MDM vendor, Sandata, HHAeXchange, and billing platform. (2) Third-party HIPAA Risk Assessment completed against staging environment. Both are scoped and costed separately from the development build — see the additional costs table in Section 8.
07 — Project timeline — build through go-live

28-week build timeline + aggregator certification to Ohio go-live

4 weeks UI/UX · 20 weeks build · 4 weeks buffer · Certification parallel from Week 5
1
Weeks 1–4 · UI/UX phase
User journeys and design system
Full UI/UX user journeys completed before development begins. Deliverables: all screen user journeys for tablet app (A1–A6, all states), caregiver phone app (B1–B3), patient intake web portal (C1–C3), and coordinator dashboard (D1–D2). Component library, interaction states, design tokens file for developer handoff — all in Figma, production-ready. Development does not start until all UI/UX is signed off. These are hard gates, not soft targets — building against incomplete designs creates rework and scope drift.
UI/UX user journeys Figma handoff Component library
2
Weeks 5–6 · Architecture phase
Technical architecture and pre-build sign-off
Architecture deliverables: ER diagram, API schema, database structure, FaceSDK integration plan, MDM configuration spec, aggregator API integration plan (Sandata Ohio + HHAeXchange), 835 ERA mapping plan. All finalised and signed off by Encore Care before code is written. Simultaneously: contact Ohio ODM EVV team ([email protected]) and HHAeXchange ([email protected]) to enter the certification queues. These contacts must happen at Week 5 — not after the build is complete.
Architecture sign-off Contact ODM + HHAeXchange
3
Weeks 7–12 · Sprint 1
Core infrastructure and tablet app
Backend setup (NestJS + PostgreSQL + AES-256 encryption + RBAC), MDM configuration (kiosk profile, zero-touch enrollment, heartbeat API), tablet APK build (kiosk lock, FaceSDK biometric integration, offline encrypted storage, GPS capture, 3-gate checkout logic). End of sprint: tablet check-in/check-out flow works end-to-end in development environment including offline mode and scan failure states.
Tablet appBackend foundationMDM integration
4
Weeks 13–18 · Sprint 2
Caregiver phone app, patient portal, coordinator dashboard
Caregiver phone app (enrollment flow, visit history, flagged shift detail, immutable note submission, GPS breadcrumb tracking), patient intake web form (three consents engine, proxy/POA flow with coordinator review gate, photo upload, payer/plan routing field), coordinator dashboard (real-time KPIs, flagged queue with urgency sorting, evidence package generation, immutable decision audit trail, MDM device monitoring, reports and CSV export). End of sprint: full user journey functional from caregiver enrollment through coordinator review.
Phone appPatient portalCoordinator dashboard
5
Weeks 19–22 · Sprint 3
Aggregator integration, billing pipeline, compliance layer
Sandata Ohio API integration, HHAeXchange API integration, aggregator routing logic, EVV field formatting (FHIR/EDI 837P), sequence enforcement (claim blocked until aggregator ACK), 835 ERA mapping, HIPAA audit logging, auto-logout timers, technology asset register, biometric exemption flag, manual shift close. Begin Sandata Ohio sandbox testing in parallel. Highest-risk sprint — aggregator API integration is where most EVV projects encounter unexpected delays. Buffer weeks 25–28 are reserved specifically to absorb any overrun here.
Aggregator integrationHighest-risk sprintSandata sandbox begins
6
Weeks 23–24 · QA and staging
Testing, security, and staging deployment
Full functional, regression, security, and end-to-end testing across all modules. Deploy to staging environment. Encore Care UAT with real coordinators and caregivers using test patient records. Execute all vendor BAAs. Complete third-party HIPAA Risk Assessment against staging. Fix all critical bugs. SOC 2 Type II observation period begins at staging deployment.
QA + UATHIPAA Risk AssessmentSOC 2 clock starts
7
Weeks 25–28 · Buffer
Buffer — aggregator integration, UAT fixes, and stabilisation
4 weeks of explicit buffer reserved for the highest-risk elements of the build. Primary use: resolving Sandata sandbox conformance exceptions (typically requires multiple iterations), UAT bug fixes from Encore Care team, any scope items that drifted during Sprint 3. Secondary use: additional security hardening, performance optimisation, documentation. If no major issues arise, this window is used to begin PA aggregator integration ahead of schedule.
Buffer weeksSandata exception resolution
8
Months 7–9 · Post-build · Parallel from Week 5
Sandata Ohio conformance testing and ODM certification
Complete Sandata Ohio API conformance testing. Prove all 6 EVV fields transmit correctly across all scenarios. Resolve all exceptions. Submit certification request to ODM. Ohio go-live only after ODM certification is confirmed. Estimated: 2–4 months from first Sandata contact. This process runs in parallel from Week 5 — it is not sequential to the build.
Sandata conformanceODM certification
9
Month 9–11 · Ohio go-live
Ohio production launch — live Medicaid patients
ODM certification confirmed. Deploy to production. Begin onboarding Ohio caregivers, patients, and coordinators. First live EVV records transmitted to Sandata. First 835 ERA remittances returned and mapped to shift records. Pennsylvania certification work continues in parallel.
Ohio live
10
Months 11–16 · After Ohio is stable
Pennsylvania certification and go-live
Sandata PA sandbox and HHAeXchange sandbox run simultaneously. PA DHS and HHAeXchange each have their own acceptance criteria. PA DHS + HHAeXchange approvals both required before PA go-live. SOC 2 Type II observation period continues throughout.
Sandata PAHHAeXchange
08 — Multi-tenant aggregator platform

Module E — Multi-tenant aggregator platform

New scope · must be designed in Sprint 1

Encore EVV is architected to serve not only Encore Care's internal operations but also external home care agencies. This section documents the additional technical layer required to operate as a certified multi-tenant EVV platform — allowing other agencies to use Encore EVV as their compliant system, with Encore routing and managing their aggregator submissions on their behalf.

Critical architecture decision
Multi-tenancy must be architected into the database schema, API layer, and auth system from Sprint 1. The tenant isolation model — whether schema-per-tenant, row-level security, or hybrid — determines the shape of every table, every query, and every API endpoint in the system. This cannot be retrofitted after single-tenant code is written without a near-complete rebuild. The dev team must confirm the tenancy model in the architecture phase (Weeks 5–6) before any application code is written.

E1 — Multi-tenancy architecture

Foundation — Sprint 1
Data isolation

Per-tenant data partitioning

Every agency is a tenant. Their ePHI is partitioned at the database level — no cross-tenant data access is architecturally possible. Tenant ID is embedded in every record, every query, and every API call. Options: schema-per-tenant (strongest isolation, higher ops overhead), row-level security (lower overhead, careful implementation required), or a hybrid. Hybrid is recommended for the EVV compliance context.

Auth + RBAC

Tenant-scoped access control

Every user — coordinator, caregiver, supervisor — is scoped to exactly one tenant. JWT tokens carry Tenant ID. API middleware validates tenant scope on every request. A coordinator at Agency A cannot read, write, or infer anything about Agency B. This is enforced at the API layer, not the frontend.

Aggregator credentials

Per-tenant aggregator identity

Each agency has their own Medicaid provider NPI and Sandata/HHAeXchange agency ID. These credentials are stored encrypted per tenant. When Encore EVV submits a visit record to Sandata or HHAeXchange, it uses the submitting agency's own credentials — not Encore Care's. Required by Sandata's schema and by Medicaid billing rules.

BAA requirement

Encore becomes a BA for every tenant

When Encore EVV handles ePHI for an external agency, Encore is a HIPAA Business Associate of that agency. A signed BAA is required before any agency's patient data can be onboarded. The BAA lifecycle must be built into the agency onboarding flow as a hard gate — not a manual side process.

Tenancy model options
Schema-per-tenant: Each agency gets their own PostgreSQL schema. Strongest data isolation, simplest query logic, highest operational overhead at scale.
Row-level security (RLS): Single schema, Tenant ID column on every table, PostgreSQL RLS policies enforce isolation. Lower overhead, requires careful implementation to avoid policy gaps.
Hybrid (recommended): Shared schema for non-sensitive operational data (agency config, routing tables), separate schemas or encrypted partitions for ePHI tables. Balances isolation strength with operational pragmatism.

E2 — Agency onboarding portal

New module · Sprint 2

A new admin layer above the coordinator dashboard. Accessible only to Encore platform admins. Handles the full lifecycle of provisioning a new agency tenant. All fields below are operationally required before a tenant can process any live visit data — the portal enforces this as a gated checklist.

Required at onboarding
  • ●  Agency legal name — as registered with Medicaid
  • ●  NPI number — national provider identifier
  • ●  Medicaid provider ID — Ohio and/or Pennsylvania
  • ●  State(s) of operation — Ohio, PA, or both
  • ●  Payer/plan list — drives aggregator routing for all patients
Aggregator + compliance config
  • ●  Sandata agency ID — issued per agency by Sandata
  • ●  HHAeXchange portal credentials — PA MCO agencies only
  • ●  Billing platform config — per-agency (AxisCare or equivalent)
  • ●  BAA execution confirmation — hard gate, cannot be bypassed
  • ●  Admin user account — first coordinator/admin login for the agency

E3 — Per-tenant aggregator credential routing

Sprint 3 · highest complexity

The existing aggregator routing logic routes by payer type. The multi-tenant layer adds a second dimension: routing by agency identity. Each agency's visit submissions must carry that agency's registered credentials — not Encore Care's. For every verified shift the transmission layer executes the following sequence:

Step 1
Resolve tenant identity
Shift record carries Tenant ID. Transmission layer looks up the agency's encrypted credentials: Sandata agency ID, NPI, Medicaid provider ID.
Step 2
Resolve aggregator target
Patient's payer/plan field determines aggregator: Ohio → Sandata Ohio. PA FFS/waiver → Sandata PA. PA MCO → HHAeXchange. Set at intake, automatic per visit.
Step 3
Submit under agency credentials
EVV payload formatted and transmitted using the agency's own NPI and aggregator credentials. Encore Care's credentials are never used for another agency's records.
Step 4
ACK stored under tenant scope
Aggregator acknowledgement logged against the shift record within that agency's tenant partition. Claim pipeline unblocked for that agency's billing only.

E4 — Agency-level compliance reporting and exception management

Sprint 3

Each agency needs the compliance visibility they would have in Sandata's native portal. This is a reporting module scoped at the agency admin level, above the coordinator dashboard. Exception management provides a structured workflow for rejected visit records from step through to resubmission.

Required reports per agency

Agency compliance reporting

Visit status by date range (Verified / Incomplete / Omitted) · State aggregation report (transmitted vs acknowledged) · Exception report (rejected records with error codes, plain-English explanation) · EVV compliance rate by caregiver · EVV compliance rate by patient · Manual edit rate (Medicaid monitors this as a fraud signal)

Exception management workflow

Aggregator rejection → resolution

When Sandata or HHAeXchange returns "Not Accepted" with an error code: (1) plain-English explanation surfaced in the agency exception queue alongside the raw code, (2) coordinator corrects the visit record or applies the appropriate exception code, (3) all edits logged immutably, (4) corrected record resubmitted. Full audit trail retained through all iterations.

Report access controls
Agency admin sees only their own tenant's data. Encore platform admin can view any tenant for support purposes — all such access is logged immutably as a Business Associate action and is disclosable to the agency under BAA terms. No cross-tenant data in any export under any circumstances.

E5 — Aggregator certification — platform scope

Parallel from Week 3

When Encore EVV certifies as an Alternate EVV Vendor with Ohio ODM and Pennsylvania DHS, that certification covers the entire platform — including all agencies using it. The certification is issued to Encore EVV as a system, not to individual agencies. Each tenant agency benefits from Encore's certification without needing to certify separately.

Ohio — Alternate EVV Vendor

Single certification · all Ohio tenants

Ohio ODM certifies Encore EVV as the platform. Any agency that signs up with their own Medicaid provider credentials can process Ohio visits through the platform immediately after certification is confirmed. Contact: evv@medicaid.ohio.gov — initiate at Week 3 of build. Budget 3–5 months from first contact to confirmed approval.

Pennsylvania — Alternate EDI Provider

Two certifications · Sandata PA + HHAeXchange

Sandata PA (FFS/waiver patients) and HHAeXchange EDI (MCO patients) must both be certified before any PA agency tenant can go live. Contact: integrations@hhaexchange.com and PA DHS Provider Assistance Center 800-248-2152. Run both sandboxes in parallel after Ohio certification is confirmed.

What certification tests
It is an API conformance test — not a legal audit or product review. The state/aggregator verifies that: (1) all 6 EVV fields transmit correctly in the right format, (2) timestamps are at scan time not upload time, (3) GPS consent flags are transmitted correctly, (4) exception codes are applied to non-standard visits, (5) acknowledgement responses are parsed and stored, and (6) resubmission flows work after rejection. Your split-data architecture, timestamp-at-scan, and aggregator ACK logic are already aligned with what certification tests for.

E6 — HIPAA and compliance implications of multi-tenancy

Compliance
Breach notification scope

Breach affects all tenants

A security incident involving the Encore EVV platform potentially exposes all tenants' ePHI. The breach notification plan must cover: identifying which tenants were affected, notifying affected agencies within the required window, supporting each agency's obligation to notify their own patients, and reporting to HHS. Each agency's BAA must specify these obligations explicitly.

HIPAA Risk Assessment

Multi-tenant scope required

The mandatory third-party HIPAA Risk Assessment must be scoped to the multi-tenant system — not just Encore Care's internal use. The assessor must evaluate tenant isolation controls, cross-tenant data access risks, credential storage security, and the BAA lifecycle management system. This expands assessment scope vs. a single-agency assessment.

SOC 2 Type II

Critical for enterprise agency acquisition

Enterprise agencies and state auditors will require SOC 2 Type II before signing on as tenants. The 6–12 month observation period begins at staging deployment — start it as early as possible. Multi-tenant scope makes the audit more complex but the certification more commercially valuable. Engage an audit firm at staging, not after go-live.

Dev team — Sprint requirements

Build order for Module E

Weeks 5–6: Confirm tenancy model. Sprint 1: Tenant ID in schema, API middleware validation, per-tenant credential encryption. Sprint 2: Agency onboarding portal with BAA gate. Sprint 3: Per-tenant credential routing in transmission layer, agency compliance reporting, exception management workflow. Pre go-live: Multi-tenant HIPAA Risk Assessment, SOC 2 observation period begins.

Section 01 — Spec table additions required
The component decision matrix in Section 01 should be updated to add a Multi-tenant platform group covering: Tenant isolation model (schema/RLS/hybrid — decision required), Per-tenant aggregator credential routing, Agency onboarding portal, Agency-level compliance reporting, Exception management workflow, BAA lifecycle management, and Platform-level aggregator certification scope.
09 — Tablet hardware procurement

Kiosk tablet specifications and procurement terms

Spec to be confirmed based on final quantity
Unit pricing

To be quoted

Wintouch A10 or equivalent Android tablet. Confirm unit price and volume tiers with supplier. Import fees, duties, and shipping must be budgeted separately based on country of origin and configuration.

Minimum order quantity

Confirm with supplier

MOQ and volume pricing to be confirmed with supplier. Initial procurement recommendation: size the first batch for the Ohio launch only, then scale with Pennsylvania certification.

Warranty

1-year manufacturer warranty

Standard 1-year warranty included with hardware. Coverage terms to be confirmed at order — verify what is included (screen damage, battery, hardware failure) and the RMA process for replacements during the warranty period.

Replacement units

Buffer stock recommended

A small number of replacement units will be provisioned and held at the office as a same-day swap pool. Recommended: 5–10% of fleet size. Replacement units are pre-enrolled in MDM and pre-loaded with the Encore EVV APK so a swap takes minutes, not days.

Hardware requirements

Android · front camera · GPS

Android operating system required for MDM kiosk enforcement and FaceSDK on-device biometric processing. Front-facing camera required for biometric face scan. GPS chip required for location capture. Minimum 32GB internal storage for offline encrypted queue.

Accessories per unit

Power bank + case

Each caregiver issued a 10,000mAh power bank for all-day operation between charges. Protective case recommended for field use in patient homes. Tablets charge nightly as documented policy. Accessories costed separately from unit price.

Procurement decision — quantity
Final tablet quantity must be determined before procurement is initiated. The recommended approach is to procure for the Ohio launch only (size based on the Ohio caregiver fleet), then place a second order timed with Pennsylvania go-live. This avoids committing to MOQ capital before Ohio operations are proven. Confirm unit pricing, MOQ, import fees, duties, and shipping with supplier before committing to any order quantity.
10 — Monthly maintenance and support

Post-launch maintenance — ongoing monthly engagement

Commences after staging deployment

Monthly maintenance covers the ongoing health, security compliance, and operational continuity of the Encore EVV platform after go-live. Scope is broken into four areas below. Monthly investment is based on a retainer model — scope and hours are agreed in advance each quarter and adjusted as the platform matures.

Infrastructure and security

Platform health and compliance upkeep

  • Cloud infrastructure monitoring and incident response
  • Security patch management — backend, SDK, and dependencies
  • AES-256 and TLS configuration maintenance
  • Technology asset register updates (May 2026 HIPAA mandate)
  • Annual penetration testing coordination and remediation
  • Quarterly HIPAA Security Rule compliance review
  • MDM fleet monitoring — offline device alerts, OTA update pushes
  • Backup verification and 72-hour incident response testing
Aggregator and billing operations

EVV pipeline stability

  • Sandata and HHAeXchange API monitoring and error handling
  • Aggregator schema updates — both aggregators update their specs periodically and the integration must be updated to match
  • 835 ERA mapping maintenance as payer remittance codes change
  • Denied claim investigation support for EVV-related rejections
  • AxisCare billing integration monitoring
  • Near real-time EVV transmission verification and alerting
Application updates

Feature maintenance and bug fixes

  • Bug fixes for issues surfaced in production
  • Android OS compatibility updates for tablet and phone apps
  • FaceSDK version updates as new versions are released
  • Minor feature enhancements agreed in the quarterly scope review
  • Coordinator dashboard data model updates as reporting requirements evolve
  • Patient portal consent form updates as regulatory language changes
Compliance and regulatory

Ongoing regulatory alignment

  • State EVV regulation monitoring — Ohio ODM and PA DHS policy updates
  • HIPAA Security Rule update monitoring and implementation
  • Biometric privacy law compliance monitoring (Ohio and PA)
  • Aggregator certification renewal coordination as required
  • SOC 2 Type II evidence collection support during observation period
  • Audit log retention and access control verification
Monthly retainer
Monthly maintenance investment is scoped and agreed separately from the build contract. A formal maintenance scope agreement is recommended before Ohio go-live, covering all four areas above with defined SLAs and response times. Multi-tenant operation expands maintenance scope — additional agencies on the platform increase aggregator pipeline monitoring, exception handling, and compliance reporting obligations.