School Based Medicaid Claiming Software: Why Your Documentation Fails the Audit and Not the Service

Why school Medicaid claiming breaks once a district gets large

It is late February. A letter arrives from the program integrity unit at your state Medicaid agency asking for supporting documentation on 60 randomly selected claims from two school years ago. Your billing vendor filed those claims. The underlying evidence is scattered: the speech language pathologists logged in the vendor portal, the occupational therapists kept paper because the portal timed out on a hallway iPad, the school nurses documented in the health module of your student information system, and one physical therapist was a contractor from a staffing agency whose license effective dates nobody kept. The parental consent forms are in a filing cabinet at a campus that was rezoned last summer.

The money is not theoretical. Your CFO budgets school based Medicaid as revenue: fee for service claims for IEP prescribed health services, administrative claiming through the random moment time study, and an annual cost settlement that trues up interim payments against actual expenditure. A finding does not arrive as a discussion. It arrives as a recoupment against a future payment, sized on an extrapolation from the sample, landing in a fiscal year when the people who could have explained the documentation have moved on.

The tooling around this is real software doing real work. Frontline Medicaid Services and PCG EasyTrac both file claims competently and both carry state specific configurations. Your IEP system is probably PowerSchool Special Programs, Frontline IEP, SEIS or Embrace. Attendance and enrollment sit in Infinite Campus, PowerSchool or Skyward. Credentials sit in HR (Human Resources). Consent sits in a cabinet. Every one of those systems holds exactly one fact the auditor wants, and the join between them is a person with a spreadsheet and a deadline.

Problem 1: the service log does not know what the IEP prescribed

An IEP says 30 minutes of direct speech therapy, twice weekly, in a group of no more than three, in the special education setting. The log says 30 minutes on Tuesday. Whether those two facts agree is the entire compliance question, and nothing checks it at the moment the therapist taps save. It gets checked at audit, years later, by someone with no interest in your explanation.

Claiming platforms take a log and turn it into a claim. What they do not reliably do is reconcile that log against the prescription sitting in a different vendor's IEP system, because the integration between them is usually a nightly extract where the service arrives as text and minutes. So under service, over service, missed sessions and makeup sessions all become a quarterly reconciliation exercise that a compliance coordinator performs by eye. The revenue leak and the compliance risk are the same defect viewed from two directions: sessions that happened but were never billable, and sessions that were billed but cannot be defended.

What a custom build does: the prescription becomes a first class object imported from the IEP system, carrying frequency, duration, group size, setting, provider type and the service date range. Logging happens against a prescription line, never free floating. At the point of entry the app tells the therapist that this student is four sessions behind the prescribed frequency, or that the log collides with a full day absence, or that the group has six students and the IEP says three. The therapist fixes it in ten seconds while the memory is fresh, which is the only moment fixing it is cheap.

Problem 2: consent and eligibility are the first two things checked

Under IDEA Part B at 34 CFR 300.154, a district must obtain one time written parental consent before it first accesses a child's public benefits, and must provide written notification annually after that. If the consent record does not cover the date of service, the claim is not billable regardless of how immaculate the therapy log is. Auditors know this, which is why it is the first thing they pull.

Medicaid eligibility is the second, and it moves monthly. A student eligible in September may not be eligible in March. Districts that treated eligibility as a checkbox rather than a set of dated spans learned this the hard way through the post pandemic redetermination period, when coverage changed for large numbers of families in a short window. A flag in a database says nothing about the date of service.

What a custom build does: consent is stored as a dated record with the scanned artifact attached, the language it was delivered in, the staff member who obtained it, and the annual notification history. Eligibility is stored as spans imported from the state eligibility file or checked through 270 and 271 transactions, never as a boolean. Claim generation then produces claims only for the intersection of five things: an active prescription, a qualified provider on that date, consent covering that date, eligibility covering that date, and the student actually being in attendance. Everything outside the intersection goes to a work queue with the reason attached rather than into a claim file that you will regret.

Problem 3: the time study and cost settlement live in a consultant's spreadsheet

Administrative claiming runs on a random moment time study. Each quarter you submit a participant list by cost pool, moments are sent to sampled staff, responses are coded to activity categories, and the resulting percentages drive both the administrative claim and the annual cost report. In most districts the participant list is handed over as a spreadsheet, moments go out from a vendor system, and non responses are chased by a coordinator sending reminder emails. A quarter with a weak response rate does not produce a smaller claim. It produces an invalid sample and a claim you may not be able to file at all.

Cost settlement is the same shape of problem with more zeros. Interim payments reconcile to actual cost using salaries and benefits by cost pool, contracted therapist invoices, the time study percentages and a Medicaid eligibility ratio. That workbook is usually built by a consultant who is not on your payroll and who rebuilds it from raw exports every year.

What a custom build does: the staff roster by cost pool comes from HR by position code rather than from a manually maintained list, so a mid year hire lands in the right pool automatically. Moments are scheduled, delivered by email and SMS, escalated to a supervisor at defined intervals, and coded through a form that shows the activity definitions inline rather than assuming the sampled nurse remembers them. Payroll and contractor invoice data flows into a cost report workspace continuously instead of being reassembled each September. You probably still want the consultant for methodology, not for data assembly.

Problem 4: the audit packet takes three weeks and still has gaps

For a single sampled claim the auditor wants the IEP page prescribing the service, the session log, evidence the provider held the required credential on that date, the parental consent, the eligibility record for that month, attendance for the day, and the claim and remittance. That is seven artifacts from up to seven systems, multiplied by the sample size.

What a custom build does: one action produces a packet per claim as an indexed PDF with every artifact attached and a cover sheet showing the chain. Underneath, the log is an append only event record, so a log edited three days after the session shows as an edit with a timestamp and an author rather than silently overwriting history. The ability to prove that nothing was retrofitted is what turns a potential finding into a paragraph.

What a build has to include

• Prescription import from your IEP system with change tracking when an IEP is amended mid year.
• Offline capable mobile logging, because therapists work in hallways, portables and buses where wifi is fiction. An offline queue is not a nice to have here.
• Group session logging: one entry covering several students with the ratio recorded, since group size drives billability.
• A provider credential registry with license type, NPI, effective and expiry dates, and supervision relationships for assistants, so a COTA or SLPA session carries its supervising clinician on the record.
• Consent and eligibility as dated spans, refreshed on a schedule, with artifacts attached.
• 837P claim generation in your state's coding, modifiers and rate structure, plus 835 remittance posting and a denial work queue that routes back to the person who can fix the underlying record.
• Time study administration and a cost report workspace.
• Unclaimed service dashboards by campus, provider and service type, which is where the CFO finds the money that funds the build.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category has a consistent shape. A focused first release, meaning prescription linked logging with offline support, credential and consent enforcement, eligibility spans and claim file generation, runs $70,000 to $150,000 and ships in 12 to 18 weeks. Adding time study administration, cost settlement support, denial management, audit packet generation and analytics takes the total to $180,000 to $450,000 phased across 6 to 12 months.

What pushes the number up in this specific category: the number of distinct source systems, since a district that consolidated two IEP platforms after a merger is paying for two integrations. Contracted providers from staffing agencies, because their credentials, supervision and invoice reconciliation are a second data model. States with unusual claiming methodology, particularly those that have adopted the expanded claiming allowed after CMS rescinded the free care policy, because billing for services delivered outside an IEP means a whole additional eligibility and documentation path.

What keeps it down: starting with the three highest volume service types and one campus cohort, running parallel with your existing vendor for a quarter, then expanding.

When buying is the right answer

Buy if your state education agency provides a claiming system at no cost to districts, which several do. Buy if you are under about 5,000 students, or if annual Medicaid revenue is under roughly $300,000, because at that level the license fee for Frontline Medicaid Services or PCG EasyTrac is far cheaper than anything we could build.

Build when two or more of these are true. Your annual claiming revenue is over $1M and the CFO treats it as budgeted income. You have had a finding, or a neighbouring district has, and the board asked whether you would survive the same review. Your therapists refuse to use the current logging tool, so logs are entered in batches from memory at the end of the month, which is the single most common root cause of an indefensible claim. You use contracted providers at scale. Or your state changed its methodology and your vendor's configuration is a year behind your reality.

How to choose a developer for school Medicaid systems

Ask them to whiteboard the difference between a prescription, a session log and a claim before you sign anything. A developer who has done this work draws three objects with different lifecycles and knows that one prescription generates many logs and that some logs never become claims. A developer who draws one table called services is going to learn this on your audit.

Ask specifically how consent is modelled. If the answer is a checkbox on the student record, they will bill services delivered before the consent date and you will repay them. The answer you want mentions dated spans and blocked claim generation.

Ask whether they have generated an 837P and posted an 835, and to which clearinghouse or state portal. This is a specific competence, not a general integration skill, and the state portals are frequently unpleasant.

Ask about records retention and access logging, since these records carry both FERPA obligations and state Medicaid retention requirements running years past the date of service. Then get code ownership in writing before kickoff: the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the district owns everything from the first commit.