Experian Health's 2025 State of Claims survey put the industry's first-pass denial rate at 11.8%. Behind that number sits a system that either caught an error before a claim went out, or let it slide through.
Medical billing software development exists to close that gap. The software flags a bad code or a missing modifier before a claim leaves the building, rather than three weeks after a payer bounces it back.
For a practice running a few thousand claims a month, that gap is worth more than almost any other line in the tech budget.
What medical billing software development looks like in practice
A practice management system handles scheduling and charts. Downstream of it sits a billing system that turns a finished visit into cash in the bank.
That chain runs through a handful of modules that most platforms build in some form, whether a practice buys a package or has one built around its own workflow:
- Patient registration and insurance eligibility checks, run before the visit happens
- Charge capture, where a visit's codes and modifiers get attached to the claim
- Claim scrubbing, which checks the claim against payer rules before it ever leaves the building
- Submission to a clearinghouse, which routes the claim to the right payer in the right format
- Remittance posting, where a payer's response gets matched back to the original claim
Skip or under-build any one of those and the weak link shows up downstream, usually as a denial that lands weeks after the visit instead of a flag that catches the problem the same day.
Keeping that patient and insurance data clean matters just as much on the billing side as it does in a dedicated healthcare CRM, since both systems work off the same underlying record.
What 837s and 835s actually do in the claims cycle
X12 EDI was mandated as the data exchange standard for healthcare claims under HIPAA, and the number in front of each transaction tells you what it does.
A claim starts life as an 837: the 837P covers most of the volume, since it's what non-hospital providers like physicians and therapists file, built around CPT procedure codes with a unit count and a charge on each line.
Hospitals file the 837I instead, which uses revenue codes to identify a department or service and can skip procedure codes altogether.
Dental claims get their own version, the 837D, built on the same frame with tooth and oral cavity fields added, according to a breakdown of healthcare's EDI transaction types.
None of that tells a practice whether it got paid. That's what the 835 is for: the payer's remittance advice, matched back against the original claim line by line.
A full system also needs the 270/271 pair for real-time eligibility checks before a visit, plus the 276/277 pair for checking where a submitted claim actually stands.
| Transaction | Direction | What it carries |
|---|---|---|
| 837P / 837I / 837D | Provider to payer | The claim itself: codes, charges, patient and provider details |
| 270 / 271 | Provider to payer, and back | An eligibility check before the visit, and the payer's answer |
| 276 / 277 | Provider to payer, and back | A status request on a submitted claim, and the payer's answer |
| 835 | Payer to provider | Remittance advice: what was paid, adjusted, or denied, and why |
Why claim denials are the real cost of a weak system
That first-pass denial rate comes from a survey of 250 healthcare revenue cycle leaders.
The report traces most denials back to three recurring causes: missing or inaccurate data on the claim itself, authorization problems, and incomplete information collected from the patient at intake.
None of those are exotic failures. They're exactly the kind of thing a billing system is supposed to catch before a claim ever leaves the building, not after a payer has already processed and rejected it.
Catching them matters because the money involved isn't small. Experian put the industry's total claims-processing waste at $265 billion.
A system built to flag a missing modifier or an unverified eligibility check before submission is attacking exactly the point where that money disappears.
What HIPAA requires from the software, not just the practice
HIPAA's Privacy Rule governs who can see a patient's billing information and why.
The Security Rule governs how the system holding that information has to be built, covering administrative, physical, and technical safeguards, according to HIPAA Journal's breakdown of billing compliance requirements.
In practice, that means role-appropriate access, workstation and session controls, and credential practices that stop one shared login from becoming the weak point in the system.
If billing work ever leaves the building, the rules get stricter, not looser. An outsourced billing service is treated as a business associate under HIPAA. A signed business associate agreement has to exist before a single claim or patient record changes hands.
The same logic applies to a vendor's software: if it touches protected health information, somebody has to be accountable for how that data is handled.
Breach notification is the part teams forget until they need it. The rule requires documented policies for reporting a breach, and some states layer stricter timelines on top of HIPAA's own.
Building that reporting path in from the start costs far less than retrofitting it after an incident.
Where AI is actually changing billing operations
Photo by Willfried Wende on Pexels
The HFMA's May 2025 poll of 101 healthcare organizations found that 63% are already using AI or automation somewhere in revenue cycle operations.
Documentation and coding draw the heaviest use so far, and leaders expect denials and underpayment recovery to see the next wave of investment, which tracks: that's the part of the cycle most directly tied to cash.
Adoption is real, but it hasn't paid off everywhere yet. The same poll found only a small share of current users could point to a clear financial return.
Most cited IT infrastructure limits or budget constraints as what's holding the rest back.
That gap between where organizations are investing and where they're actually seeing results is normal for a technology this new.
A system built with claim scrubbing or denial prediction from the start has room to outperform one that bolts AI on after the fact, since most of the field hasn't closed that gap either.
We see the same pattern in our own AI and automation work across other back-office functions: the fastest wins come from narrow, rules-heavy tasks, not sweeping overhauls.
Building, buying, or customizing: what should decide it
Off-the-shelf practice management platforms cover the basics well: eligibility checks, 837 generation, remittance posting, patient statements.
For a single-specialty practice running standard CPT-coded claims, that's often enough, and building from scratch would mean solving a problem someone already solved.
The calculation changes once a practice's claims stop fitting a standard template, or once billing needs to share data with a member portal nobody sells as one package. A compliance requirement outside a generic vendor's roadmap tips the same way.
That's when custom software development starts to make sense, not because it's cheaper on day one, but because it's the only path to a system built around how the practice actually works.
We've built that kind of connected platform before. For OptimalMD, we designed and built the website, the member portal, and the mobile app as one product, rather than stitching separate tools together after the fact.
The same principle carries over to billing: a system built around the actual workflow outperforms one assembled from parts that were never meant to talk to each other.
For a broader look at planning a build like this, our complete guide to healthcare software development walks through the steps that apply beyond billing specifically.
Whichever path a practice takes, the EDI standards and the HIPAA safeguards covered above apply either way. Buying a platform doesn't exempt a practice from understanding them, and building one doesn't let it skip any of them.
Frequently asked questions
Does billing software need its own Business Associate Agreement?
If the software or the vendor behind it touches protected health information, yes. HIPAA treats an outsourced billing service as a business associate, and a signed agreement needs to be in place before patient data changes hands, whether that's a billing company or the system itself.
What do the 270 and 271 transactions actually check?
They're the eligibility pair: the 270 asks a payer whether a patient's coverage is active and what it covers, and the 271 is the payer's answer, sent back before the visit happens. Running that check up front is what keeps a practice from treating a patient and finding out afterward that the claim won't be covered.
Cover photo by cottonbro studio on Pexels
