Read your EDI data
Upload 835 remittances and 837 claims (or read what your SFTP feed delivers), then read every table of the EDI pages, the denials and payment-variance analyses, and a verified dataset's checks, one tool each.
Your 835 remittances and 837 claims are on Data Sources → EDI in the app: the batches and SFTP feeds, Browse EDI data, and the verified datasets a study reads. Through the MCP server your assistant reads the same data from a conversation, and anything it uploads lands in the same place.
Say something like:
Upload these October remits and tell me our top denial reasons and which payers underpay us.
The server knows the steps. Your assistant calls edi_next_step() and the batch tools carry next_step.
Getting the data in
- Upload.
edi_create_uploadreturns a 15-minute link for a.zipof X12 835 / 837 files. A local assistant (Claude Code) runs the returnedcurl; a browser assistant gives you an upload page. The file never passes through the conversation. A team whose SFTP feed is on already has its batches: skip toedi_list_batches. - Parse.
edi_add_batchturns the zip into an EDI batch and parses it the way the app does (the parse queue). The upload is deleted once it is read. A file read before is not read twice (duplicate: true). - Wait.
edi_get_batch(oredi_list_batches) reports the status; a batch takes a minute or two.edi_reparsetries a batch again.
Reading it
Every table, card and chart the EDI pages show is its own tool, returning the same figures the server computes for the page. Every read leaves duplicate claims and remits out (a file re-sent in a new envelope counts once).
| Component | Tool |
|---|---|
| EDI tab: the batches table (status, files, transactions, validated tag) | edi_list_batches |
| EDI tab: one batch | edi_get_batch |
| EDI tab: the feed rows (receiving / quiet / needs attention / waiting / paused) | edi_feeds |
| EDI tab: a feed's files | edi_feed |
| Browse EDI data: By payer (835) | edi_remits_by_payer |
| Browse EDI data: By payer (837) | edi_claims_by_payer |
| Browse EDI data: Remits | edi_remits |
| Browse EDI data: Claims | edi_claims |
| Browse EDI data: Download (CSV, workbook, zip of CSVs) | edi_export |
| Chat: top denials (CARC, CO / PR split, likely cause) | edi_denials_top |
| Chat: denials trend (this window vs the one before) | edi_denials_trend |
| Chat: payment variance headline, leak and root cause | edi_variance_summary |
| Chat: payment variance by payer | edi_variance_by_payer |
| Chat: payment variance by code | edi_variance_by_code |
| Chat: ask anything of the EDI data | edi_ask |
edi_ask is the chat's EDI explorer: a model writes one SQL query for your question, the server checks it (one read-only SELECT over the EDI tables, nothing else allowed) and runs it as a read-only database role that only sees your team's rows. It answers what no other tool does; prefer the tools above when one fits.
No result carries a patient identifier: the EDI tables hold none. A claim or remit is named by the same de-identified key the app shows.
Verified datasets
A dataset is a slice of your EDI data checked step by step and signed off, so a study (an underpayment study) reads verified data. edi_create_dataset makes one (batches, service dates, payers), edi_get_dataset shows each step's verdict, edi_dataset_verdict records one (good / problem / unsure / later) and edi_dataset_sign_off signs it off once every step is judged and none is a problem.
| Step | Tool |
|---|---|
| 1. Population and dates | edi_dataset_population |
| 2. Files read completely | edi_dataset_integrity |
| 3. Payer Mix | edi_dataset_payers |
| 4. Claims Answered | edi_dataset_match |
| 5. Paid vs charges | edi_dataset_ratios |
| 6. Months and lag | edi_dataset_lag |
| 7. Denials | edi_dataset_denials |
| 8. Providers and locations | edi_dataset_providers |
| 9. MA and Medicaid | edi_dataset_plans |
| 10. Medicare baseline | edi_dataset_medicare |
| 11. CMS benchmark | edi_dataset_cms |
| 12. Questions for the hospital | edi_dataset_summary |
| 13. Analysis data | edi_dataset_analysis |
| The page's filter values | edi_filter_options |
| The Report step | edi_dataset_report |
Each step tool takes the page's filters (service dates, payers, with or without an 835) and a card to read one card or table of the step alone. edi_dataset_report_add adds a card (or a block of your own text) to the dataset's report, and edi_dataset_report_pdf returns the report as a branded PDF behind a one-hour short link.
Plans
Your EDI data is yours: uploading, parsing, the EDI tables, denials, edi_ask, the datasets and the exports are on every plan (the free plan's daily call limit applies; the setup and bookkeeping calls don't count against it). Payment variance prices remits against your contracted rates, so without the Underpayments service each variance tool is a preview (five rows, no dollar figures) with a link to upgrade.
Run an Out-of-Network Analysis
What happens to revenue if a practice drops a payer and bills its full charge instead - set up the study from your assistant, read every table, chart and PDF section as data, and get the client PDF.
Your data (Data Sources)
The team's own data from a conversation - providers and health systems, rate tables and CDMs, volume and cost datasets, payers, fee-schedule import audits, contracts and files, one tool per component.