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 link Sandata visits to existing Betasky visits (then bill from Ready for Billing)
How to use imported Verified visits on New Claim

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

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.
Link a Verified Sandata visit to an existing Betasky EMR visit (same patient, same scheduled calendar date), update check-in/out from Sandata, then bill that EMR visit from Ready for Billing.
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
Creating schedule visits from Sandata	Linking requires an existing Betasky visit with check-in

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

35.2 Who Can Use It

Role	Access
Agency Administrator	All Sandata Migration permissions (default)
Biller	All Sandata Migration permissions (default)
Scheduler / clinician (typical)	No access — menu hidden; APIs return 403
Custom roles	Only if you check the boxes under Sandata Migration in Roles & Permissions

Permission checkboxes (Settings → Roles & Permissions)

Permission	Allows
View Sandata Migration	Open the page, list visits, stats, audit log, read payer mappings
Upload Sandata files	Upload Visits & Claims Verification workbooks
Match, link & map payers	Match / ignore / rematch / reset, link or unlink Betasky visits, edit payer mappings
Use Sandata visits on claims	Attach Ready-to-claim visits on New Claim (External EVV — Sandata)

Keys (for support): evv-import:view, evv-import:upload, evv-import:match, evv-import:use-on-claim.

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

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.

Size guidance: keep uploads under 15 MB and ideally under ~25,000 visit rows per file. Prefer weekly (or shorter) exports rather than multi-month dumps.

35.5 Reading the List

Stats

TOTAL VISITS · MATCHED · UNMATCHED · READY TO CLAIM · HISTORY — these are all-time agency totals (not limited by the week filter on the table).

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
Linked to Betasky visit	Linked to an EMR visit — bill from Ready for Billing
History — billed in Sandata	Processed — keep for audit; do not bill

Filters

Search: Medicaid ID anytime; name / payer / HCPCS needs a selected Week. Match · Eligibility · Sandata status · Week (Mon–Sun; defaults to current week; clear = all weeks). Week filters on the visit Date column. Stats cards stay all-time.

Row actions

Link to Betasky visit · Unlink Betasky visit · 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 Link to a Betasky Visit

Use this when EVV lives in Sandata but the clinical visit already exists in Betasky.

On a Ready to claim Verified row, open ⋮ → Link to Betasky visit.
Review ranked candidates (same patient, same scheduled calendar date). Only Completed visits can be confirmed; In Progress / Scheduled may appear as “not ready.”
Compare Sandata times vs Betasky times, then Confirm link.
Betasky check-in/out (and scheduled time) are replaced with Sandata values; originals are kept for audit.
The Sandata row moves to History immediately (Linked to Betasky visit).
Bill later from Claims Center → Ready for Billing. In Review & Bill, the visit shows Linked from Sandata.

Unlink (⋮ → Unlink Betasky visit) is allowed only before the Betasky visit is billed. Unlink restores original times and can make the Sandata row Ready to claim again.

Do not also attach the same Sandata row on New Claim (External EVV) — the system blocks that after link.

35.8 Bill from Imported Visits (New Claim path)

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 or linked to a Betasky visit 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.9 Common Mistakes

Confusing Sandata Migration with EVV Center or EMR Migration.
Uploading before Ohio Medicaid Provider ID is set.
Expecting patients or schedule visits to be created from the file — register patients and schedule visits first, then match / link.
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.
Trying to bill the same Sandata hours twice (New Claim and Ready for Billing) — link locks the Sandata row.

35.10 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
Either: New Claim → Billing Source External EVV — Sandata → Use Visit
Or: Link to Betasky visit → Ready for Billing

Complete Patient Journey