PhantomBill — Wireframes for Designer

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.

Dev notes — A4 · A4b · A5 · A6

A4 — Flash screen only: The check-in confirmed screen is a 5-second flash — it confirms success and transitions automatically to the active shift view (A4b). It does not return to idle after a successful check-in. Idle is for when no shift is active.
A4b — Active shift state: After check-in, the tablet switches to a persistent "clocked in" view. Running timer counts up from check-in time. Caregiver name and patient name shown as context. This screen stays up for the duration of the shift — it is the default tablet state while a shift is in progress.
A4b — Check Out placement: Check Out only appears on this screen, not on the idle home screen. A caregiver cannot trigger Check Out unless a shift is actively running on this tablet. This prevents accidental or fraudulent check-outs.
A4b — Timer display: Timer is display-only — calculated from check-in timestamp stored in the backend, not a client-side counter. If the tablet restarts, the timer resumes correctly from the backend value on reconnect.
A4b — GPS active indicator: Footer shows GPS is pinging. If GPS signal is lost mid-shift, footer should switch to an amber warning state so the caregiver is aware.
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 4

Patient full name

Date of birth

Home address

Payer / insurance plan

Emergency contact

Consenting party

Continue →

C1b · Consents (step 2 of 4)

Consents required

Step 2 of 4 · Must be completed to proceed

Biometric data consent

I consent to the patient's face being scanned at each visit for identity verification, and the resulting biometric data being stored securely by Encore Care for this purpose only.

GPS / geolocation consent

I consent to GPS coordinates being recorded at check-in and check-out, and to passive location tracking by the caregiver's device during the shift, for Medicaid EVV compliance.

HIPAA Notice of Privacy Practices

I acknowledge receipt of Encore Care's Notice of Privacy Practices explaining how patient health information is used and protected.

I agree — continue →

C2 · Patient photo upload (step 3 of 4)

Patient photo

Step 3 of 4 · 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

Step 4 of 4 · Optional access

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 (patient and family onboarding)

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 already captured by the coordinator (name, DOB, address, payer/plan) should be pre-filled and locked — family only fills in the gaps. Payer/plan field is required here as it drives aggregator routing for every future shift.
C1 — Biometric consent (required): The intake form must include an explicit, plain-language consent section for biometric data collection. The patient (or their legal guardian/POA) must consent to: (1) their face being scanned at each visit check-in and check-out, (2) their facial embedding being stored in Encore Care's secure system, and (3) the biometric data being used solely for shift verification purposes. Consent must be signed or digitally acknowledged — a checkbox with a timestamp is the minimum. This is a legal requirement in many states and a HIPAA best practice regardless. Consent must be renewed if the patient's legal guardian changes.
C1 — GPS / geolocation consent (required, Ohio mandatory): The intake form must include a separate, explicit consent for GPS location capture. In Ohio, this is mandated by ODM (form 10375 equivalent) — GPS coordinates cannot be recorded without signed patient consent. In Pennsylvania, GPS consent is also required before coordinates can be captured. Consent covers: location being recorded at check-in and check-out, and GPS breadcrumb data being generated by the caregiver's phone during the shift. Without GPS consent, PhantomBill must fall back to logging location as "home" or "community" only — coordinates cannot be stored or transmitted to the aggregator. Flag this patient record as GPS-consent-pending so the system handles their visits correctly.
C1 — HIPAA Notice of Privacy Practices: The intake form must include acknowledgement of Encore Care's HIPAA Notice of Privacy Practices (NPP). This explains how patient ePHI is used, stored, and shared. Acknowledgement must be timestamped and stored. This is a federal requirement before any ePHI is collected.
C1 — Legal guardian / POA handling: If the patient lacks capacity to consent (cognitive impairment, dementia), a legal guardian or Power of Attorney must sign all consent sections. The form should include a field to identify the consenting party and their relationship/authority. Store documentation of their authority (POA form or guardianship order) in the patient record.
C1 — Consent storage: All signed consents — biometric, GPS, HIPAA NPP — must be stored as immutable records in the patient profile with timestamps. They are ePHI and must be encrypted at rest, access-controlled, and included in audit logs. Retention minimum: 6 years per HIPAA, or longer per state law.
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. Coordinator reviews and approves quality — not automated. If rejected, a re-submission request is sent to the family with specific guidance. The biometric consent obtained in C1 covers this photo submission.
C2 — Photo storage and conversion: Raw photo should not be retained long-term. Convert to a facial embedding on upload and delete the original image in line with HIPAA data minimisation principles. Confirm this approach with legal counsel before implementation.
C3 — Permissions hard limit: Family portal is strictly read-only. Family cannot add approved locations, edit care plans, approve or reject shifts. These restrictions must be enforced at the API level, not just in the UI.
C3 — Push notifications: Family can opt into arrival and departure push notifications during the intake process. These fire on check-in confirmed and check-out confirmed events. Opt-in is separate from the required consents — it is a preference, not a legal requirement.

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.

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.

G1 · What data goes where — biometrics vs EVV fields

Biometrics stay internal. Only the six EVV fields go to the aggregator.

This is a critical architectural boundary. Biometric data is PhantomBill's internal proof mechanism — it generates the confidence to submit a GPS-verified visit record. It never leaves Encore Care's system.

What PhantomBill captures internally

Caregiver biometric

Face match score

Proves caregiver identity at check-in and check-out. Stored internally as an encrypted embedding. Never transmitted to aggregator.

Patient biometric

Co-presence confirmed

Proves patient was physically present. Stored internally. Not a required EVV field — not sent to aggregator.

→

Verification engine

Shift approved internally

Biometric match + GPS gives PhantomBill the confidence to mark the visit as verified and submit the EVV record.

What gets transmitted to the aggregator — the six required EVV fields only

1 · Service type

Type of care provided

PHI — linked to medical care plan

2 · Recipient

Patient Medicaid ID

PHI — direct patient identification

3 · Date

Service date

PHI when linked to healthcare service

4 · Location

GPS coordinates

PHI — geographic identifier. Requires written patient consent in Ohio before capture.

5 · Caregiver

Staff member ID

PHI — linked to patient care delivery

6 · Time

Clock-in / clock-out

PHI — temporal identifiers tied to healthcare service

All six fields are PHI. Every transmission to the aggregator is a transfer of protected health information. HIPAA encryption, access control, and audit logging requirements apply to the full data pipeline — from tablet to PhantomBill backend to aggregator.

Dev notes — G1 (EVV data boundaries)

Biometrics are internal only: Face match scores, facial embeddings, and biometric attempt logs are never transmitted to the state aggregator. They are PhantomBill's internal verification layer. The aggregator receives only the six EVV fields listed above.
GPS coordinates = PHI: Location data linked to a healthcare service is a PHI identifier under HIPAA. It must be encrypted in transit and at rest, access-controlled, and audit-logged with the same rigor as any other ePHI in the system.
Ohio GPS consent requirement: Ohio law requires a signed patient consent form (ODM form 10375) before GPS coordinates can be captured. This consent must be obtained at intake (C1 form) and renewed annually. Without consent, location must still be logged as "home" or "community" — but coordinates cannot be recorded.
Near real-time transmission required: As of early 2026, aggregators are auto-rejecting claims that lack real-time GPS-verified data. Offline-synced visits must transmit to the aggregator promptly on reconnect — timestamp at scan time (not sync time) is what satisfies the near real-time requirement, but extended offline periods risk exception flags.
Aggregator response handling: After submission, the aggregator returns a status: accepted, not accepted (with specific error codes), or pending. PhantomBill must parse and store the aggregator response per visit and surface any "not accepted" visits in the coordinator dashboard with the error detail so exceptions can be corrected and resubmitted.

G2 · HIPAA technical safeguards required for PhantomBill

HIPAA Security Rule — technical requirements for EVV systems (2026)

Every item below is a legal requirement, not a recommendation. These apply to the tablet app, caregiver phone app, backend, and all data pipelines.

Core technical safeguards

Encryption

At rest + in transit

AES-256 minimum at rest. TLS 1.2+ in transit. Applies to tablet local storage, backend database, and all API calls to aggregators.

Access controls

Unique IDs + MFA

Every user (coordinator, supervisor, caregiver) has a unique login. MFA required for dashboard and admin access. No shared credentials.

Audit logs

Immutable access trail

Permanent, unalterable record of who accessed what data and when. Applies to every ePHI record — shift records, patient profiles, biometric data.

Auto-logout

Inactivity timeout

Tablet app and caregiver phone app must auto-lock after inactivity period. Prevents unauthorized access if device is lost or stolen.

Updated requirements — HIPAA Security Rule revision effective May 2026

Asset inventory

Technology asset register

Maintain a detailed, current inventory of all technology assets that store or transmit ePHI — tablets, servers, cloud services, third-party integrations.

Incident response

72-hour restoration window

In the event of a security incident, systems handling ePHI must be restored within 72 hours. Requires a documented incident response plan.

Annual testing

Pen testing + vulnerability scans

Annual penetration testing and vulnerability scanning of all systems that store or process ePHI. Results must be documented and remediated.

Required compliance milestones — plan for these before launch

HIPAA Risk Assessment

Required before go-live

Mandatory comprehensive review identifying threats, vulnerabilities, and risks to ePHI confidentiality, integrity, and availability. Must be completed and documented before handling any live patient data.

→

BAAs in place

Business Associate Agreements

Required with every third-party vendor that handles ePHI on your behalf — biometric SDK provider, cloud hosting, MDM vendor, aggregators, billing platform.

→

SOC 2 Type II

Independent security audit

Independent auditor attestation of security, availability, integrity, confidentiality, and privacy controls over 6–12 months. Required by enterprise clients and state agencies. Begin audit period as early as possible.

Build for compliance from day one. Retrofitting encryption, audit logs, and access controls after launch is expensive and risky. Every architectural decision — database choice, cloud provider, API design, session management — should be made with HIPAA compliance as a baseline requirement, not an afterthought. Engage a HIPAA compliance consultant alongside the dev build, not after.

Dev notes — G2 (HIPAA technical safeguards)

Encryption — specifics: Tablet local storage: AES-256 encrypted (Android Keystore or equivalent). All API calls (tablet → backend, backend → aggregator): TLS 1.2 minimum, TLS 1.3 preferred. Backend database: encrypted at rest. Biometric embeddings: encrypted with a separate key from visit records.
MFA scope: Required for all coordinator, supervisor, and admin dashboard logins. Caregiver phone app should require MFA at account setup and on new device logins. Tablet is MDM-managed and kiosk-locked — MFA at the app level is not needed, but MDM admin access requires MFA.
Audit log requirements: Every read and write on a patient record, shift record, or biometric profile must generate an immutable audit log entry: user ID, action, record ID, timestamp. Logs must not be editable by any role including admin. Retention minimum: 6 years per HIPAA.
Auto-logout timers: Coordinator dashboard: 15-minute inactivity timeout recommended. Caregiver phone app: 30-minute inactivity timeout. Tablet: returns to idle screen (no patient data visible) after successful scan or 60-second inactivity — already part of the scan flow design.
Technology asset inventory: Maintain a living document listing every system that touches ePHI: tablets (serial numbers, MDM enrollment status), cloud servers, biometric SDK vendor, aggregator connections, billing platform, any third-party analytics or logging tools. This is now a legal requirement under the May 2026 HIPAA Security Rule update.
BAAs — do not skip: A Business Associate Agreement is legally required with: the biometric SDK vendor, cloud hosting provider (AWS/GCP/Azure all offer BAAs), MDM provider (ManageEngine or Jamf), Sandata, HHAeXchange, and the billing platform. If a vendor won't sign a BAA, they cannot be used in the PhantomBill stack.
HIPAA Risk Assessment — do before go-live: This is not optional and cannot be done retroactively. Engage a qualified HIPAA consultant to conduct the assessment during the build phase. Output is a documented risk register with mitigation actions. Budget approximately $5,000–$15,000 for an external assessment.
SOC 2 Type II — start the clock early: The audit period must be 6–12 months of demonstrated controls. The sooner you begin operating under documented security policies, the sooner you can complete the audit. Engage an audit firm (e.g. Vanta, Drata, or a traditional CPA firm with SOC 2 practice) as soon as the system is in staging. Budget $20,000–$50,000 for first-time SOC 2 Type II.
Incident response plan: Document and test a written incident response procedure covering: detection, containment, 72-hour restoration, breach notification (60-day HIPAA notification window for patients, HHS notification). This plan must exist before handling live ePHI.

PhantomBill — Wireframes

Ready

Look at the camera

Please look at the camera

Shift started

Patient scan failed

Maria Santos

Recent shifts

Shift detail

Face enrollment

Patient intake

Consents required

Patient photo

Family portal

Dashboard

Flagged — action required

Recent verified shifts

Flagged shift review

Flag details

Evidence