PhantomBill — Wireframes for Designer

A1 · Idle / home

Encore CareEVV Terminal

Ready

Tap to begin your shift

Check In

Check Out

Online · MDM managed

A2 · Caregiver face scan (step 1 of 2)

Step 1 of 2Caregiver scan

Scanning...

Look at the camera

Keep face centred in the frame

A3 · Patient scan (step 2 of 2 — handed off)

Step 2 of 2Patient scan

Waiting for patient...

Please look at the camera

Hand this screen to the patient

Dev notes — A1 · A2 · A3

A1 — Kiosk mode: App runs in Android single-app lock. No home button, no status bar, no settings access. MDM (ManageEngine or Jamf) enforces and monitors this remotely.
A1 — Online/offline indicator: Status footer reflects MDM heartbeat. Show a warning state if MDM connection drops. "MDM managed" confirms device is enrolled.
A2 — Simultaneous capture: Front camera and GPS both fire the moment Check In is tapped. No secondary user action needed. GPS coordinates are captured silently in the background.
A2 — Biometric SDK: Must work fully offline on Android and meet HIPAA standards. Shortlist to confirm: Amazon Rekognition (cloud), FaceSDK or similar on-device option. Dev team to decide before build.
A3 — No patient interaction: Screen transitions to patient mode automatically after caregiver scan passes. Patient does not tap anything — camera detects face passively. 30s timeout with no face detected triggers retry prompt.
A3 — Accessibility requirement: Patient-facing instruction must use large font (20px+), high contrast, and zero small UI targets. Designed for elderly users with limited dexterity or vision.

A4 · Check-in confirmed (success)

Check-in confirmed

✓

Shift started

9:04 AM · March 29

CaregiverMaria S.

PatientRobert J.

Location✓ Verified

Biometrics✓ Both confirmed

Returns to idle in 5s

A5 · Scan failure / flagged state

Scan incomplete

Patient scan failed

3 attempts reached. Shift logged and flagged.

Add note and continue

Retry

A6 · Offline mode

Encore CareOffline

No internet connection

Check In

Check Out

Offline · 3 scans queued

Dev notes — A4 · A5 · A6

A4 — Auto-dismiss: Success screen returns to idle after 5 seconds. No tap required. Screen must clear all patient-identifiable data from view on dismissal — nothing persists on the tablet UI.
A4 — Record sealing: On confirmed success, the shift record is sealed as immutable in the backend. No edits permitted after this point. Coordinator overrides are a separate action with their own audit trail.
A5 — Attempt logic: 3 scan attempts maximum. Each failed attempt logged individually with timestamp and reason. After 3 failures, the shift record is created and flagged — caregiver is never blocked from proceeding.
A5 — Note required: Caregiver must enter a free-text note before the failure screen dismisses. Note is immutable once submitted and appears in the coordinator's flagged shift review view.
A6 — Offline-first architecture: Tablet must function fully without internet. All biometric data and GPS stored locally in AES-256 encrypted storage. Auto-syncs when connectivity is restored. Queued scan count shown in footer.
A6 — Timestamp integrity: Timestamp is recorded at moment of scan, not at moment of sync. This is an EVV compliance requirement — state aggregators require the actual visit time, not the upload time.

B1 · Visit history (home screen)

Maria Santos

Caregiver · Active

This week

32h

This month

128h

Recent shifts

Robert J.

Today · 9:04 AM – 1:30 PM · 4h 26m

Verified

Clara M.

Yesterday · 2:00 – 6:00 PM · 4h

Verified

John B.

Mar 27 · 9:00 AM – 12:00 PM

Flagged

Helen K.

Mar 26 · 10:00 AM – 2:00 PM

Pending

B2 · Flagged shift detail + note submission

Shift detail

John B. · Mar 27

Flagged

Flag reason: Patient biometric failed at check-out. All 3 gates failed.

Check-in9:02 AM

Check-out12:04 PM

Duration3h 02m

GPSClean trail

Patient scanFailed (3x)

Add a note for coordinator

Patient was asleep at check-out. Attempted 3 scans.

Submit note

B3 · Caregiver onboarding — face enrollment

Face enrollment

Step 3 of 4 · One-time setup

Angle: Front ✓ · Left · Right

Follow the prompts to scan 3 angles

Dev notes — B1 · B2 · B3

B1 — Data source: Visit history is pulled from the backend, not from local tablet storage. Status badges (Verified / Flagged / Pending) reflect the live state of each shift record.
B1 — Hours calculation: Weekly and monthly totals are calculated server-side from sealed shift records only. Flagged or unresolved shifts are excluded from totals until a coordinator resolves them.
B1 — GPS sync status: App should surface a passive indicator when GPS data is queued vs synced — this helps caregivers know connectivity is working before they need it at check-out.
B2 — Note immutability: Once a caregiver submits their note it cannot be edited. Coordinator sees the note alongside the full evidence package (GPS trail, biometric attempt log, timestamps).
B3 — Enrollment is one-time: 3–4 face angle captures on the caregiver's own phone. The resulting facial embedding is stored server-side as encrypted data — not as a raw image, not on the device.
B3 — Coordinator activation: Caregiver account is inactive until a coordinator reviews and activates the profile. Caregiver cannot use the tablet until activation is confirmed.
B3 — Compliance: Biometric data storage must comply with HIPAA and applicable state biometric privacy laws (check Illinois BIPA and any Ohio/PA equivalents).

C1 · Digital intake form (family completes)

Patient intake

Sent by Encore Care · Step 1 of 3

Patient full name

Date of birth

Home address

Emergency contact

Continue →

C2 · Patient photo upload (step 2 of 3)

Patient photo

Step 2 of 3 · Used for identity verification

Take a clear photo of the patient's face.

Tap to take photo or upload

Upload photo →

C3 · Family portal (optional, read-only)

Family portal

Robert Johnson · Shift history

Caregiver arrived today at 9:04 AM ✓

Today · Maria S.

9:04 AM – 1:30 PM · 4h 26m

Verified

Yesterday · Maria S.

2:00 – 6:00 PM · 4h

Verified

Mar 27 · Maria S.

9:00 AM – 1:00 PM · 4h

Verified

Dev notes — C1 · C2 · C3

C1 — No app download: Form is a mobile-optimised web link sent via SMS or email. Family completes on their own device with no app install required.
C1 — Pre-fill from intake: Fields that are already captured by the coordinator (name, DOB, address) can be pre-filled and locked — family only fills in gaps.
C2 — Photo as provisional baseline: The submitted photo is the starting biometric profile. On the patient's first real shift, the tablet captures a live scan which upgrades the profile automatically. No coordinator action needed for the upgrade.
C2 — Photo quality requirements: Photo must be well-lit, face clearly visible, no sunglasses, no heavy obstructions. Quality check is done by coordinator — not automated. If rejected, a re-submission request is sent to the family.
C3 — Permissions hard limit: Family portal is strictly read-only. Family cannot add approved locations, edit care plans, approve or reject shifts. These restrictions are enforced at the API level, not just the UI.
C3 — Push notifications: Family can opt into arrival and departure push notifications. These fire on check-in confirmed and check-out confirmed events respectively.

D1 · Main dashboard — daily overview and flagged queue

Dashboard

Sunday, March 29, 2026

Last sync: 2 min ago

Active shifts

Right now

Verified today

Auto-approved

Flagged

Needs review

Offline devices

Reconnecting

Flagged — action required

View all

Caregiver	Patient	Date / time	Flag reason	Status
John M.	Helen K.	Today · 8:05 AM	Patient biometric failed (3x)	Review needed
Sara P.	Marcus T.	Today · 10:22 AM	GPS gap 45 min — no note	Review needed
David R.	Louise W.	Yesterday · 2:00 PM	All 3 checkout gates failed	Pending note
Amy C.	Frank N.	Mar 27 · 9:00 AM	Shift duration 2h outside schedule	Warning

Recent verified shifts

View all

Caregiver	Patient	Time	Duration	Verification
Maria S.	Robert J.	9:04 – 1:30 PM	4h 26m	Auto-approved
Carlos D.	Joan F.	8:00 – 12:00 PM	4h	Auto-approved
Nadia B.	Peter S.	7:30 – 11:30 AM	4h	Auto-approved

Dev notes — D1 (main dashboard)

KPI tiles: All four metrics are real-time pulls. "Active shifts" = check-in confirmed with no check-out yet. "Verified today" = auto-approved only, not coordinator-overridden. "Flagged" badge on sidebar nav also updates in real time.
Flagged queue: Sorted by urgency — "Review needed" rows first, then "Pending note", then "Warning". Clicking a row opens the flagged shift review screen (D2). Coordinator cannot approve their own shifts.
Offline devices: Pulled from MDM heartbeat. Clicking the tile opens the Devices view showing which tablets are offline, queued sync count, and last known GPS.
Reports section (nav): Should surface exportable data for billing reconciliation and state compliance audits — date-range filters, CSV export, evidence package download per shift.

D2 · Flagged shift review — coordinator decision screen

Flagged shift review

John M. → Helen K. · March 29, 8:05 AM

Needs review

Check-in

8:05 AM

Confirmed

Check-out

12:10 PM

Flagged

Duration

4h 05m

Scheduled 4h

Flag details

Patient biometric failed (3 attempts). Caregiver note: "Patient was unresponsive, appeared to be sleeping."

Evidence

✓ Check-in GPS ✓ Caregiver biometric ✓ GPS trail clean ✓ Check-out GPS ✗ Patient biometric

Approve shift

Reject shift

Download evidence package

Mark patient biometric-exempt

Dev notes — D2 (flagged shift review)

Decision audit trail: Every coordinator approval or rejection is logged with the coordinator's ID, timestamp, and an optional written reason. These entries are immutable and included in the evidence package.
Evidence package: Auto-generated PDF containing: check-in and check-out timestamps, GPS coordinates and trail map, biometric match scores (or failure codes), caregiver note, and coordinator decision. Must be downloadable for any disputed Medicaid claim.
Biometric-exempt flag: If coordinator marks a patient as exempt, all future shifts for that patient skip the patient scan step and are routed to supervisor spot-check protocol instead. Exempt flag is stored on the patient profile, not the shift record.
Manual shift close: Coordinator can also close a shift manually (e.g. caregiver forgot to check out). Manual close requires a written reason and is flagged differently from a biometric-failed shift in reports.
Permissions enforcement: A coordinator cannot approve a shift where they are also listed as the caregiver. This must be enforced at the API level.

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

How a verified shift becomes a paid Medicaid claim

Four phases. Each arrow is a data handoff. Internal systems left; external systems right.

Phase 1 — Capture (on-device)

Tablet APK

Face scan + GPS

Stored locally, encrypted

→

Caregiver phone

GPS breadcrumb trail

Passive ping every 15–30 min

→

Offline queue

Local encrypted storage

Auto-syncs on reconnect

Phase 2 — Verification engine (Encore Care backend)

Biometric SDK

Face match service

Matches against stored profiles

→

Rule engine

3-gate checkout logic

GPS → approved list → patient scan

→

Decision

Auto-approve or flag

Record sealed as immutable

Phase 3 — EVV aggregator (state middleware)

EVV export

Formatted visit record

FHIR / EDI 837P with 6 required fields

→

State aggregator

Ohio / PA EVV system

Sandata, HHAeXchange, or Direct Submit

→

Acknowledgement

Aggregator confirms receipt

Logged back in PhantomBill

Phase 4 — Billing and payment

Billing system

Claim generation

EVV-confirmed shifts trigger 837P

→

Medicaid MCO

Claim adjudication

Ohio Medicaid / PA DHS

→

Remittance

835 ERA returned

Payment mapped to shift record

Dev notes — E1 (back-office and Medicaid data flow)

EVV compliance — 6 required fields: The 21st Century Cures Act mandates EVV for all Medicaid personal care and home health services. The six required data points are: (1) type of service, (2) individual receiving service, (3) date, (4) location of service, (5) individual providing service, (6) time in and time out. PhantomBill's biometric dual-scan captures all six at the moment of care.
Ohio aggregator — confirmed: Sandata is Ohio's sole EVV aggregator. All Ohio patients (fee-for-service and MCO) route to Sandata. PhantomBill must be certified as an Alternate EVV Vendor against Sandata's Ohio-specific technical specs before going live.
Pennsylvania aggregator — split by payer: PA uses two aggregators. Fee-for-service and most waiver patients (ACT150, DDD) route to Sandata via PA DHS. MCO-managed patients (AmeriHealth, UPMC, Highmark Wholecare, Health Partners Plan, PA Health & Wellness, United Healthcare) route to HHAeXchange. PhantomBill needs both integrations and routing logic to send each visit to the right one.
Sequence enforcement: The verified shift record must reach the state aggregator and receive acknowledgement before a claim is submitted. PhantomBill must block claim generation programmatically until the aggregator ack is logged against the shift record.
835 ERA mapping: When payment remittance comes back from Medicaid, map it to the original shift record in PhantomBill (paid / denied / short-paid + reason code). This closes the loop from biometric scan to cash in the bank and is essential for billing reconciliation and dispute resolution.
Billing system integration: PhantomBill does not need to be the billing system — it passes verified, aggregator-acknowledged shift data to Encore Care's billing platform (e.g. Waystar, AdvancedMD, or similar). Confirm that integration point early — it determines how the 835 ERA gets returned.
Payment tracking is required: PhantomBill should track the full payment status per shift: pending → aggregator acknowledged → claim submitted → paid / denied / short-paid. Without this, billing disputes are blind. See Section F for the complete routing and payment tracking logic.

F1 · Which aggregator does each patient's data go to?

Aggregator routing — confirmed for Ohio and Pennsylvania

The patient's state and payer/plan determines which aggregator PhantomBill sends their visit record to. This is captured at patient intake and drives an automatic routing rule — no one has to decide manually per visit.

Ohio — all patients route to Sandata

Ohio · Fee-for-service

Billed directly to ODM

Aetna, Buckeye, CareSource, Humana, Molina, United

→

Aggregator

Sandata (Ohio)

Ohio's sole EVV aggregator — all payers route here

→

Billing

Ohio Medicaid / MCO

Claim denied if no matching EVV record in Sandata

Pennsylvania — routing splits by payer type

PA · Fee-for-service + waivers

Billed to PA DHS (PROMISe)

Also: ACT150 and DDD waiver patients

→

Aggregator

Sandata (Pennsylvania)

PA DHS EVV aggregator — same vendor, different state config

→

Billing

PA DHS via PROMISe

Claims denied without matching EVV visit in Sandata

PA · MCO-managed patients

AmeriHealth · UPMC · Highmark

Also: Health Partners Plan · PA Health & Wellness · United

→

Aggregator

HHAeXchange (Pennsylvania)

All PA MCOs have partnered with HHAeXchange for EVV

→

Billing

PA MCO adjudication

HHAeXchange also transmits to Sandata for DHS reporting

How PhantomBill knows which aggregator to use

Patient intake (C1)

Payer / plan recorded

State + plan type captured at onboarding — required for billing regardless of EVV

→

Routing rule

Lookup: plan → aggregator

Ohio = Sandata. PA fee-for-service = Sandata. PA MCO = HHAeXchange.

→

Automatic dispatch

Correct API called per shift

No manual decision needed. Routing is set on the patient profile.

Ohio GPS consent note: Ohio law requires written patient consent before capturing GPS coordinates. This consent must be obtained at intake (add to the C1 intake form) and renewed annually. Without consent, location must still be recorded as "home" or "community" — GPS coordinates are optional but require the signed consent form (ODM 10375).

Dev notes — F1 (aggregator routing logic)

Patient profile field required: Add a "Payer / Plan" field to the patient record at intake (C1 form). Minimum data needed: state, payer name, payer type (fee-for-service / MCO / waiver). This field drives aggregator routing for every shift — it must be set before the patient's first visit.
Routing lookup table: Build a simple internal mapping: Ohio + any plan = Sandata Ohio. PA + fee-for-service or waiver = Sandata PA. PA + MCO (AmeriHealth, UPMC, Highmark, Health Partners, PA Health & Wellness, United) = HHAeXchange. This is a small config table, not complex logic.
Two separate API integrations to build: Sandata (covers both Ohio and PA fee-for-service with state-specific configs) and HHAeXchange (PA MCO patients only). Both vendors have developer documentation and sandbox testing environments specifically for alternate EVV vendors.
HHAeXchange also reports to Sandata: For PA MCO patients sent to HHAeXchange, HHAeXchange will forward the data to Sandata for DHS-level reporting. You do not need to double-submit — sending to HHAeXchange is sufficient for PA MCO patients.
Payment tracking — close the loop: PhantomBill must track shift status across the full payment lifecycle. Recommended status field per shift: Verified → Aggregator submitted → Aggregator acknowledged → Claim submitted → Paid / Denied / Short-paid. Denial reason codes from the 835 ERA should be stored on the shift record so billing staff can identify and fix the issue without leaving PhantomBill.
Denial workflow needed: When a claim is denied, the billing team needs to know: which shift, what reason code, what to fix. PhantomBill should surface denied shifts in the coordinator/admin dashboard with the ERA reason code and a path to resubmit the corrected claim.

F2 · Alternate EVV vendor certification — how PhantomBill gets approved to go live

Certification path — becoming an approved Alternate EVV vendor

This is required before PhantomBill can transmit live EVV data in Ohio or Pennsylvania. It's a testing process, not a licensing board — you're proving your API sends data correctly.

Ohio certification (Sandata + ODM)

Step 1

Contact ODM early

Reach out to Ohio ODM EVV team while still building. Get in the queue. Email: evv@medicaid.ohio.gov

→

Step 2

Build to Sandata spec

Ohio Alternate EVV technical specifications published on ODM EVV webpage. Follow exactly.

→

Step 3

Test in sandbox

Sandata opens vendor testing environment. Submit test visit records, resolve all exceptions.

→

Step 4

Certified — go live

ODM confirms certification. PhantomBill can transmit live Ohio EVV data to Sandata.

Pennsylvania certification (Sandata + HHAeXchange + PA DHS)

Step 1

Sandata (PA)

Build to PA Sandata spec

Same vendor as Ohio but different state config. PA DHS aggregator specs published on pa.gov EVV page.

→

Step 2

HHAeXchange

Build to HHAeXchange API

Contact: integrations@hhaexchange.com. They coordinate directly with vendors building alternate EVV connections.

→

Step 3

Test both sandboxes

Run test visit records through both systems. Sandata and HHAeXchange each have their own test environments and exception reports.

→

Step 4

Certified — go live PA

PA DHS confirms. PhantomBill routes PA patients to the correct aggregator based on their plan.

Recommended launch sequence: Certify Ohio first (one aggregator, simpler). Learn from the process. Then certify Pennsylvania (two aggregators, more coordination). Going state by state reduces risk and means Encore Care can start billing in Ohio while PA is still being set up. Budget 2–4 months per state for the certification process — it's not instantaneous.

Dev notes — F2 (certification path)

Start contact early: ODM and PA DHS certification queues have wait times. Reach out to both state EVV teams while the app is still being built — not after. Ohio: evv@medicaid.ohio.gov or call 855-805-3505. Pennsylvania: Provider Assistance Center 800-248-2152.
Ohio Sandata sandbox access: Register at sandatalearn.com using provider ID 9999999 as a placeholder during the testing phase. Update with the real Medicaid ID once received from ODM.
HHAeXchange integration contact: Email integrations@hhaexchange.com to initiate the alternate vendor setup. They will assign an integrations team member to coordinate the testing process.
What certification tests: You're proving that PhantomBill transmits all 6 required EVV data fields correctly, in the right format, for a range of visit scenarios — standard visit, missed visit, manual edit, offline sync, exception handling. It's an API conformance test, not a legal audit.
Ohio: launch first: Ohio is one aggregator (Sandata), all payers unified. Simpler to certify. Go live in Ohio first, generate real revenue, then layer in Pennsylvania.
Do not go live uncertified: Submitting live EVV data before certification is approved risks visit records being rejected by the aggregator, which means claims cannot be paid. Encore Care should not accept Ohio or PA Medicaid patients on PhantomBill until certification is confirmed for that state.