Chapter 35: Sandata Migration

Chapter Overview

What You'll Learn:

What Sandata Migration is (and what it is not)
How to upload Sandata Visits Claims Verification Status files
How to match unmatched patients
How to use imported Verified visits on New Claim

Path: Sidebar → Agency tools → Sandata Migration → /dashboard/sandata-migration

Text-only. For Ohio agencies that capture EVV in Sandata and bill from those visits in Betasky (especially billing-only agencies).

35.1 What This Feature Is (and Is Not)

Where to find it

Left sidebar → section Agency tools (near the bottom, under Billing & revenue / Compliance) → Sandata Migration.
URL: /dashboard/sandata-migration.
Sits next to EMR Migration (different product).

What it is

Upload Sandata’s weekly Visits Claims Verification Status workbook into Betasky so billers can:

See a durable list of imported visits (matched / unmatched / history).
Build New Claim lines from Verified visits for patients already registered in Betasky.
Keep Processed visits as history only (already billed in Sandata — never claim again in Betasky).
After a visit is used on a claim, see the linked Claim {number} on the Sandata Migration list (visit cannot be billed twice).

What it is not

Do not confuse with	Difference
EVV Center (Alt-EVV)	Pushes Betasky Call In/Out to Sandata (Chapter 28)
EMR Migration	Axxess zip / patient–staff archives (Migration Guide)
Creating patients from the file	Unmatched Medicaid IDs stay in a match queue — Betasky does not auto-create patients

This import does not create schedule visits, clinicians, GPS EVV, payroll, or care orders.

35.2 Who Can Use It

Role	Access
Agency Administrator	View, upload, match
Biller	View, upload, match
Other roles	Hidden unless custom permissions include `evv-import:*`

Visible for full EMR and billing-only agencies (not sandbox-hidden by the nav flag).

35.3 Prerequisites

Before the first upload:

Ohio Medicaid Provider ID is set on Settings → Account Profile (Chapter 4). Upload is blocked without it.
Patients exist in Betasky with Medicaid / payer member IDs populated so auto-match can work.
You have the Sandata report named Visits Claims Verification Status (.xls or .xlsx).

On the first successful upload, Betasky locks the agency Sandata Account ID from the file banner. Later files from a different Sandata account are rejected.

35.4 Upload a Sandata File

Open Sandata Migration.
Click Upload Sandata file.
Select the Visits Claims Verification Status workbook (.xls / .xlsx).
Wait while the file uploads, then either Close or Stay & watch while processing runs in the background.
When finished: Import Complete (or Already imported if this exact file was uploaded before) → View Imported Visits.

What gets imported

Sandata status	In Betasky
Verified	Eligible to claim once the patient is matched
Processed	History — billed in Sandata (never claimable)
Other statuses	Skipped
ODA / ODAS payers	Excluded

Re-uploading the same file content is safe — Betasky detects it and does not create duplicates. Re-uploading an updated weekly file updates rows where needed and keeps existing patient matches / claim links.

35.5 Reading the List

Stats

TOTAL VISITS · MATCHED · UNMATCHED · READY TO CLAIM · HISTORY

Eligibility chips

Chip	Meaning
Ready to claim	Verified + matched to a Betasky patient
Needs patient match	Verified (or otherwise stored) but no unique patient link yet
History — billed in Sandata	Processed — keep for audit; do not bill

Filters

Search (name / Medicaid / payer / HCPCS) · Match (All / Matched / Unmatched / Ambiguous) · Eligibility · Sandata status (Verified / Processed).

Row actions

Match to Patient · Ignore · Reset to Unmatched
If a visit is already on a claim, the Claim {number} chip opens Claims Tracking.

35.6 Match Patients

Click Match Patients (badge shows unmatched count), or use Re-run auto-match.
Review name suggestions and search by name or MRN.
Link each row to the correct patient, or Ignore rows you will not claim.
Apply decisions (batch apply supports up to 100 at a time).

Auto-match prefers:

Payer member ID
Existing Sandata client link
Intake Medicaid number
High-confidence unique patient name (ties stay ambiguous)

Unmatched Medicaid IDs are kept here. We do not create patients from this file.

35.7 Bill from Imported Visits

Open Claims Center → New Claim (Chapter 27).
Select patient and a UNIT_BASED payer.
Set Billing Source to External EVV — Sandata.
In Available Sandata EVV Visits, click Use Visit for each Verified visit you want on the claim.
- Date and hours come from the Sandata visit when possible.
- The visit’s HCPCS must already exist as a service code on that payer (add it in Payer Setup first if missing).
Review lines → Create Claim.

Only Ready to claim visits appear in the picker. Visits already used on another claim are hidden. Processed / History visits cannot be attached.

What happens to the visit after Create Claim

The visit is linked to the new claim line and can no longer be used on another claim.
On Sandata Migration, the eligibility chip is replaced by a clickable Claim {number} chip (opens Claims Tracking).
READY TO CLAIM decreases; the visit counts toward HISTORY.
The imported row stays for audit — it is not deleted.
The claim then follows the normal Claims Center path (Ready to Submit → submit → tracking / payment).

35.8 Common Mistakes

Confusing Sandata Migration with EVV Center or EMR Migration.
Uploading before Ohio Medicaid Provider ID is set.
Expecting patients to be created from the file — register patients first, then match.
Trying to claim Processed visits — they are history only.
Uploading another agency’s Sandata file (Provider Medicaid ID / Sandata Account mismatch fails the batch).
Choosing the wrong Billing Source on New Claim — use External EVV — Sandata.

35.9 Quick Checklist

Ohio Medicaid Provider ID set; patients registered
Correct Visits Claims Verification Status file uploaded
Unmatched queue cleared (Match / Ignore)
Verified visits show Ready to claim
New Claim → Billing Source External EVV — Sandata → Use Visit

Complete Patient Journey