Create the first (administrator) account. You'll add your coworkers from Settings afterward.
Enter the 6-digit code from your authenticator app.
Setup key (manual entry):
Passwords must be at least 12 characters. If you were given a temporary password, set your own now.
| Loading... |
| Remit Date | Insurance | Amount | Received | Posted | Notes | View | |
|---|---|---|---|---|---|---|---|
| Loading... | |||||||
| Patient | DOB | Date of Service | Appointment | Insurance | Confirmed | EyeMed |
VSP |
Superior |
Spectera |
Stedi |
||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Loading... | ||||||||||||
Exams per doctor per full clinic day — the denominator for the Schedule Forecast %. It's multiplied by each doctor's scheduled availability for the week.
Every eligibility sheet adds its plan here: insurance, plan, sub plan and the exam / CL exam / Optos copays. Only distinct rows are kept, so a plan listed twice with different copays means they vary by patient. No patient details are stored.
| Insurance | Plan | Sub plan | Exam copay | CL exam copay | Optos copay | Network | Seen | Sheet | Notes | |
|---|---|---|---|---|---|---|---|---|---|---|
| Loading… | ||||||||||
Core KPIs for the practice or a single doctor, each month measured against its trailing 6-month average.
Dr. Douglas provides fill-in coverage only, without a standing weekly schedule — most months show little to no clinic activity, so these figures will look sparse by comparison.
Every claim on an imported remit that carried an exam code (92004 or 92014), counted once per claim by its date of service; reversals come off. Other exam codes the payer uses (92002, 92012, S0620, S0621) are shown beside it, not added in.
| Month of service | Exams (92004 + 92014) | 92004 | 92014 | Other exam codes | Claims with an exam code |
|---|---|---|---|---|---|
| Loading… | |||||
835s and cheat sheets you've generated, newest first. Click Copy to put the file itself on your clipboard - ready to paste wherever you need it - or Open to launch it directly.
Which patients? Only cells not yet answered are checked, payer by payer, one portal login each. You can watch progress and stop it from the window that opens.
Enter the patient — no need to know their insurance. This adds a row to the grid, then Fetch checks them against every payer at once and each column tells you whether they're a member.
Clears every column's answer and deletes the stored sheets - the patient stays on the grid, each column back to Check.
Takes the patient off the grid for this date of service (a Sync Schedule will add them back if Crystal still lists the appointment).
Puts typed member IDs, changed carriers, added plans and a corrected name/DOB back to Crystal's record right away. Notes are kept.
This runs on the server in the background — close this window and keep working; the header shows its progress and tells you when it's done. Open it again from there if a portal asks for a sign-in or a 2FA code: do that in the live view below and the run carries on by itself.
Live portal — sign in / clear 2FA here. 100%
Get a remittance into the tracker one of two ways - either way, it lands in your Superior downloads folder and is imported automatically. No separate "Import a batch" step needed.
Pick one 835 file you've already downloaded from InstaMed by hand. It gets renamed, filed, and imported automatically.
Opens a real browser window - you log in yourself - and pulls everything new in bulk, without downloading one at a time.
Spectera is set up in the tracker, but its remittance fetch isn't live yet — the Spectera portal login is still being fixed on their end. Once it's working, this is where you'll pull Spectera payments, the same way as the other payers. For now, Spectera invoices are still tracked on the invoice side.
Get a remittance into the tracker one of two ways - either way, the original RA PDF is kept untouched as the reference document (every claim's Remit button opens it) and each claim gets its own importable 835.
Pick one or several RA PDFs you've already downloaded from the EyeMed portal by hand. They're filed and imported automatically.
Opens a real browser window - you log in yourself - and pulls everything new in bulk, without downloading one at a time.
Pick one or several RA PDFs. Each is saved untouched, parsed, and every claim on it gets its own importable 835 - same crosswalks and write-off mapping as the standalone EyeMed tool.
Runs in the background on the server — close this window and keep working; the header shows progress and says when it's done, and you can reopen this window from there to sign in or see the log. This opens the EyeMed reports portal in a browser session and shows it below as a live view. Sign in there - by hand, or with one click if an admin has saved the login under Settings > Portal Logins; the session is remembered between fetches. After login it searches the date range, skips unfinalized rows (the negative, parenthesized amounts - those repeat until they turn positive), skips RAs already fetched, downloads the rest, and imports them automatically.
...through today.Status: —
Live portal view - the browser is running on the server. Click into it and type your login like normal; nothing you type is read or stored by this app. 100%
Runs in the background on the server — close this window and keep working; the header shows progress and says when it's done, and you can reopen this window from there to sign in or see the log. This opens the Eyefinity/VSPOnline portal in a browser session and shows it below as a live view. Sign in there - by hand, or with one click if you've saved the login under Settings > Portal Logins; the session is remembered between fetches. After login it walks the Explanation of Payment months in the range, downloads every EOP PDF not already fetched, and imports them automatically - each claim lands in Payments View with its own importable 835 (Eyezen combine and base-lens fold applied), reversals and denials go to 4. Complex, and the Remit button opens the original EOP.
...through today. VSP's portal lists EOPs by whole month, so the fetch covers every month from the one you pick forward - EOPs already fetched are skipped automatically.Status: —
Live portal view - the browser is running on the server. Click into it and type your login like normal; nothing you type is read or stored by this app. 100%
One remittance (835) file at a time. It's renamed to a date + trace number filename, filed in your Superior downloads folder, and imported automatically - the app also checks whether it looks like a claim you've already tracked before adding it.
Runs in the background on the server — close this window and keep working; the header shows progress and says when it's done, and you can reopen this window from there to sign in or see the log. This opens the InstaMed Provider Login in a browser session and shows it below as a live view. Sign in there - by hand, or automatically from the login you saved under Settings > Portal Logins. Each fetch now starts a fresh sign-in with that saved login, so a password change always takes effect right away; the "remember this device" 2FA trust is kept, so you're not asked for a code every time.
...through today.Pre-filled to pick up right where the last fetch left off - move it earlier to reach further back. Remittances already in the folder are detected by their contents and skipped automatically, so it's always safe to overlap or re-run a range. Long ranges are searched in smaller pieces automatically (InstaMed only shows up to 99 results per search). New files are imported automatically once the fetch finishes.
Status: —
Live portal view - the browser is running on the server. Click into it and type your login like normal; nothing you type is read or stored by this app. 100%
The code Crystal's Invoice Report uses for each payer (the "Ins" column) - used to reconcile invoices against tracked claims.
Any invoice whose Ins column matches none of these codes is tracked automatically too: a blank Ins column files under Self Pay, anything else under Medical / Other (showing the plan name from the report).
Goes on every generated 835's payee section - the name, NPI, and tax ID your payers have on file. A new practice must set these before importing anything into its posting software.
Appearance (per computer - takes effect immediately)
Account:
My Portal Logins - yours alone (each person saves their own; encrypted on the server). They power the "Fill saved login" button in the live portal view, so you never type credentials by hand. The password is never shown again or sent to any browser. Leave a portal blank to keep logging in manually.
Nightly auto-fetch - when a payer's switch is on, the app fetches its new remits automatically every night at 3:00 AM Central (using the remembered portal session, or the saved login of whoever turned the switch on) and imports them, so new payments are just there in the morning. If the portal demands 2FA or the password changed, that night's run fails safely and the Payments View shows an "auto-fetch failed" warning - running a manual fetch and signing in fixes it. Switches are off until someone turns them on.
Eligibility APIs - the Stedi and Spectera keys, the provider block and the carrier → payer ID mapping live on the Eligibility tab under ⚙ Eligibility Settings.
Crystal PM API - the practice's API credentials (Real office and API Sandbox), connection tests, report previews, and the per-patient verification tools live in their own window.
InstaMed SFTP (Matt, Oct 2 2026) - JPMorgan's direct file drop for Superior Vision's remittances, instead of the browser logging into the InstaMed portal. Enter the username and password from JPMorgan's email; Host:port defaults to their SFTP server below. Test connection only lists what's there. Pull new 835s downloads whatever is in the server's 835 folder that isn't already in the Superior remits folder (matched by each remittance's trace number, so overlap with the browser fetch never doubles one) and runs the normal Superior import on it. Files on JPMorgan's side are never deleted. Overnight: while this credential is saved, Superior's nightly auto-fetch pulls from here instead of the InstaMed browser; the browser fetch only runs as a fallback on a night the SFTP pull can't connect.
Users - each person gets their own login (never share accounts). New users get a temporary password from you and set their own password + two-factor at first sign-in.
Activity log - who did what, when (HIPAA audit trail).
Fetch Agent - lets this app's Fetch buttons open the payer-portal browser on the office computer. Run run_fetch_agent.command in the ClaimsTracker folder there and keep its window open.
Upload Crystal's Invoice Report - you can select several files at once (Crystal caps how much one export returns, so export in chunks and upload them all together). New invoices are added to Invoice View right away, and every claim's status is recomputed automatically from Crystal's own Ins Balance and Pat Balance - nothing here needs your review. A claim you'd manually set a status on is recomputed fresh too, so it won't stay stuck on a status the real numbers no longer support. Notes are never touched by an import.
| Patient | Payer | Was | Now |
|---|
Upload the check register export (Number, Date, Amount, Payee, Memo, Voided…). Each check is matched to an invoice on the sheet - by the Inv # in its memo, or by the payee's name (or, for a minor, the insured on their plan) plus the DOS in the memo. Review the matches, pick any the app couldn't decide, then post: one refund line per check on that invoice in Crystal, with the check number in the description. Voided checks are skipped; a check already posted is refused unless you tick it again. Writes go to whichever environment is selected in Settings › Crystal API; the real office only when "Allow posting to the real office" is switched on there.
| Check # | Date | Amount | Payee | Memo | Matched invoice | Result | |
|---|---|---|---|---|---|---|---|
| Choose the file and click Read the file. | |||||||
Cross-references a payer's remittance payments against the open insurance balances still on the invoice sheet. When a paid patient still shows an open balance, that payment probably was never actually posted into Crystal - even if it's marked posted here. Each remit date shows the share of its payments that look posted. Everything is matched inside the app by name; only the counts and percentages below ever leave it, so this screen is safe to share.
| Remit Date | Payments | Look Posted | Look Open | % Posted |
|---|---|---|---|---|
| Loading… | ||||
The Stedi column checks medical plans over Stedi's real-time eligibility API. Two key slots: the TEST key answers only Stedi's mock patients (never billed); the PRODUCTION key runs real checks against real payers, billed per check. Keys are shared, admin-only, stored encrypted and never shown again.
What Fetch all sends. Stedi bills per check, so the sweep only sends a patient whose Crystal plan is mapped to a Stedi payer and carries a member ID; everyone else shows not sent (the reason is the tooltip) and a single ↻ on that cell can still send it. Monthly soft cap for the sweep: checks
Each patient's primary plan from Crystal goes to its Stedi payer (see the Payer ID mapping tab) with the member ID - or with the insured as the policy holder when the patient is a dependent.
The Spectera column calls UnitedHealthcare Vision's Coverages API (V5) on the Optum gateway: a client id + secret gets a bearer token, then POST …/coverages/v5 searches by the subscriber ID on the patient's UHC/Spectera plan in Crystal + the patient's DOB, or by name + DOB + the ZIP from the address book. Two environments: Non-prod (Optum stage - knows only UHC's QA test members) and Production (real members). Save each environment's client id + secret in its box below, then pick the environment the column uses.
Look up one member by hand - UHC's QA test members on Non-prod, a known patient on Production. Subscriber ID + DOB is enough; otherwise first + last name + DOB + ZIP.
Run UHC's test member file - upload their QA workbook (Members / EHB-Dependents / Commercial-Dependents; fake members, no PHI) and look up a batch of them on the environment chosen above. Every answer lands in a table here and in an Excel (one row per member + the raw replies) - the way to see what each retail plan code comes back as.
The provider every API check is sent under - Stedi requires an NPI and a name. Two are kept: the practice's group NPI (sent with the organization name - Medicare always wants this one) and a doctor's individual NPI (sent with the doctor's name). Pick which one payers get by default here; a payer that needs the other (BCBS Texas, say) is switched per payer under Payer mapping, in its row's NPI column. Use the NPI the payer has enrolled (Medicare: the billing NPI active in PECOS and attested for HETS in the Stedi portal).
Each appointment's doctor comes from the Crystal schedule, and that doctor is the one each eligibility pull runs under: the practitioner / requesting-doctor pick on the EyeMed, VSP and Versant portals, and the individual NPI on a Stedi check (when that payer uses the individual NPI). The list fills in from Crystal on every schedule sync; an NPI typed here is kept even if Crystal's changes.
| Doctor | Crystal id | Individual NPI | NPI from | Active |
|---|
Crystal insurance → payer ID. Each carrier on the upcoming grid (any of a patient's three slots), the payer ID a Stedi check would use, and where that ID came from. Crystal's own IDs (the insurance list's ACCOUNT column) are used automatically; Change searches Stedi's network for a different ID, Skip leaves a carrier out (a vision plan checked elsewhere, for instance). To map a carrier that isn't on the grid yet, tick every Crystal insurance and type its name in the filter box - the list narrows to it.
Crystal's insurance list (Reports › Insurance list export) names the plans on the Eligibility tab and carries each carrier's payer ID; a copy from 9/18/2026 is built in, so upload one only when insurances are added or changed in Crystal.
Carrier map - what the workbook upload writes; edit here only for a one-off. One per line: #12 = 13305, Superior Vision (by Crystal ID), Superior Vision = 13305, Superior Vision (by name), or = skip to leave a plan out.
Two independent nightly clocks for the Eligibility grid, each on its own switch and time: the schedule pull that refreshes the 3-week block (new patients, everyone's plans, member IDs and insured), and the fetch protocol that checks eligibility across it (portals + Stedi). Runs against the real office only, with the shared Crystal API token. Looking for the invoice sync's nightly schedule? That moved to Sync from Crystal › Nightly schedule. Every run appends to data/crystal_sync.log - download the full log if the summary lines below aren't enough.
Upload a CrystalPM schedule export (.csv) by hand - each patient's name, DOB, appointment date and notes are added to the grid. Only needed when Sync Schedule on the Eligibility tab can't reach Crystal; the usual way to fill the grid is Sync Schedule or the nightly schedule pull above.
The last 150 eligibility runs - a single-cell Check or retry, Run Eligibility Check, a per-column Fetch, Fetch selected, and the nightly fetch protocol. Closing the status window stops a run early (same as the invoice sync popup), so this is where to check what a run actually did afterward. Each row's View log shows the same sign-in narration the status window showed live; Copy log copies just that row's log text, and Copy all below copies every run currently listed, newest first, in one paste.
Credentials come from the Crystal developer portal (developer.crystalpm.io › Tokens). Two are kept - one for the API Sandbox (office 10235, fake data, safe to experiment on) and one for the real office (office 8832). Both are shared, admin-only, stored encrypted like the portal logins, and never shown again or sent to a browser. Use read-only tokens (the .read scopes). Every query below runs against whichever environment is selected.
Each pull is read-only and comes back as an Excel file: one sheet per endpoint, Crystal's own field names as the column headers, nothing renamed or summed - so a column here is a field in the API. Open one, find the field you need, and tell me its column name.
The app's one write to Crystal: a refund line on an existing invoice (POST /invoices/{id}/transactions). Uses the one API token saved above for the environment selected (it needs billing.write among its scopes). Preview reads the invoice first and shows the exact line it would post; Post sends it once and reads the invoice back to prove it landed. Every post is logged, and the same refund is never posted twice by accident.
Each button below is a separate experiment on the account / invoice filled in above (use the test patient). Every click clears the last result first, and each attempt with Crystal's reply also goes in the ledger.
Refund line probe - posts the same refund in several shapes, one at a time, and stops at the first one Crystal accepts, so at most one line lands (void it in Crystal afterwards if it was a test).
Simpler writes - can the token write anything here? An invoice activity note, a patient comment, and a new empty invoice (delete it in Crystal afterwards).
Each refund line the app tried to post - by hand or from a check file - lands here with Crystal's reply. A red row is an attempt Crystal refused (its error message is the exact text Crystal sent back); nothing was written for it.
Pulls your current balances from Crystal and brings Invoice View up to date.
Ready whenever you are.
Check the rebuilt balances against Crystal's own Invoice Report: run the report, keep just the Invoice, Ins Balance and Pat Balance columns (CSV or Excel), and drop it here. Download what the sync computed if you'd rather compare in Excel.
Runs the same sync this button does, automatically, against the real office with the shared API token - a snapshot is taken first, so Roll back above still undoes it. Once a week it also re-reads every tracked patient; once a week it audits the whole office for balances that entered by no other door. Download the full nightly log if the summary below isn't enough.
Upload the patient export from the practice-management system (the one with ADDRESS1/CITY/STATE/ZIP and ACCTID columns). Addresses are matched to invoices by Account ID only - never by name - so patients who share a name can't get each other's address. Re-uploading refreshes addresses already on file and adds new ones; export in chunks and upload as many times as it takes until every patient-balance invoice below has an address.
These patient-balance / refund invoices have no address on file yet - pull another export that includes them and upload it here.
| Patient | Invoice # | Account ID | Status |
|---|
| Code | DOS | Charge | Paid | Patient | Adjustments |
|---|
Saves automatically when you close this box. Each new line is stamped with today's date and your initials, e.g. [09/22/26 MB] - older lines keep their original stamp.
Reveal it in Finder instead - select it there and press Cmd+C to copy it yourself.
Every import, with a link to that batch's reconciliation summary.
| Payer | Label | Imported | Claims | Summary |
|---|