Revenue cycle management
RCM software built for the claim that comes back denied
A clean claim is the easy 80%. The software that earns its cost is the one that reads a denial, finds the fix, and gets the corrected claim back out before the payer's deadline closes.
What an RCM buyer should ask any vendor
4 things that decide this
- 01Ask how the system handles the 837 claim and the 835 remittance. These X12 transaction sets are the actual data contract between a provider and a payer, and software that treats them as a black box cannot explain its own denials.
- 02Ask what happened after the Change Healthcare breach. The February 2024 incident at a UnitedHealth-owned clearinghouse froze claims processing for thousands of practices nationwide, and it is the reason single-clearinghouse dependency is now a design question, not an afterthought.
- 03Ask where a denial goes when the reason code is ambiguous. A carrier adjustment reason code is a starting point, not a verdict, and a system with no human review queue will resubmit the same mistake.
- 04Ask who owns the appeal deadline. Most payers give 90 to 180 days to appeal a denial, and a platform that cannot show you the clock per claim will let some run out quietly.
Denial management is a document pipeline wearing a clinical label
A claim leaves the practice as an 837 file: procedure codes, diagnosis codes, the payer's own formatting rules. It comes back as an 835, either paid or denied with a reason code attached. Everything between those two events is where revenue cycle software earns its keep, or does not.
Most billing tools treat a denial as an event to log. The harder problem is reading the denial, mapping the reason code to an actual fix, and drafting the appeal before its deadline closes. That is document extraction, rules validation and deadline tracking. It is the same shape of problem we build in other regulated, paperwork-heavy industries.
Clearinghouses like Availity sit in the middle of this exchange. They translate and route 837s and 835s between practice systems and payers. Software that talks to one payer's portal and ignores that layer is building for a smaller, more fragile world than the one billing teams actually work in.
Named context, not our numbers
Why denial management is the hot problem in RCM right now
Feb 2024
When the ransomware attack on Change Healthcare, a UnitedHealth/Optum clearinghouse, disrupted claims processing across the US healthcare system
837 / 835
The X12 transaction sets every claim and remittance flows through, whichever clearinghouse or payer sits on the other end
90–180 days
The typical payer window to appeal a denial before the claim is written off, varying by payer and plan type
The RCM work we take
Built around the document and the deadline, not a generic billing dashboard.
Denial reading and reason-code mapping
Parsing the 835 remittance and the carrier adjustment reason code, then routing to the specific fix: a resubmission, an appeal, or a write-off, instead of one undifferentiated worklist.
Document AI on the claim packet
Extracting fields from superbills, EOBs and payer correspondence that were never designed for a parser, the same problem shape as reading a payroll report in an insurance audit.
Appeal drafting with a human sign-off
A drafted appeal that cites its source figures and the policy or contract clause behind them. Billing staff edit and submit; the system does not send anything on its own.
Deadline and status tracking across payers
One record showing where each claim sits and how many days remain to appeal it, instead of that clock living in someone's memory or a spreadsheet.
Clearinghouse integration, not single-point dependency
Connecting to Availity or another clearinghouse as one integration among several, so an outage at one vendor does not stop every claim in the building.
Eligibility and prior authorization checks
Verifying coverage and authorization status before the claim goes out, which prevents a category of denial rather than managing it after the fact.
- EncounterCodes assigned at the visit.
- 837 submittedThrough a clearinghouse, to the payer.
- AdjudicatedPayer applies its own rules.
- 835 returnedPaid, or denied with a reason code.
- Denial triagedReason code mapped to a fix, or not.
- Appeal or write-offDeadline-driven, often missed.
Most billing software instruments the first two steps well and the last two barely at all. That is where the recoverable revenue sits.
A confident denial reading is not the same as a correct one
An AI model can read a remittance advice and suggest an appeal in seconds. It can also be confidently wrong about which contract clause applies. A payer rejects an appeal citing the wrong basis just as fast as it rejects the original claim.
PremiumAudit.io, our insurance audit platform, hit the same problem with policy figures. A model returns a confidence score, and confidence is not the same thing as correctness. The fix was validating every extracted figure against the source document and the applicable rule, rather than accepting the model's number alone.
- Cite the source line from the remittance in every drafted appeal, alongside the conclusion.
- Validate the reason code against the specific payer contract, not a generic lookup table.
- Route anything the system cannot map with certainty to a person, before it goes out.
Document-heavy audit and validation systems we have shipped
Denial logging against denial management
Most billing tools do the first column well. The second is where recoverable revenue actually lives.
| Criterion | Denial logging | What production RCM requires |
|---|---|---|
| The 835 | Marked paid or denied and filed. | Reason code parsed and mapped to a specific fix. |
| The appeal | Drafted from memory by billing staff. | Drafted from the source figures, staff review and submit. |
| The deadline | Tracked in a spreadsheet, if at all. | Visible per claim, with time remaining shown. |
| Clearinghouse outage | Every claim stops. | One integration among several keeps moving. |
| Ambiguous cases | Resubmitted the same way, denied again. | Routed to a person with the context attached. |
The stack this work runs on
Document AI
Data
Integration
What billing teams and RCM vendors ask us
01Can AI actually reduce claim denials, beyond just reporting them?
Yes, when it acts before submission and after, not only after. Eligibility and authorization checks before the 837 goes out prevent a category of denial. On the 835 side, mapping the reason code to a specific fix turns a denial into a recovered claim rather than a filed one. Drafting the appeal from the source document is what makes that mapping actionable.
02How does this connect to a clearinghouse like Availity?
Through the same X12 837 and 835 transaction sets the clearinghouse already routes. Where volume justifies it, we build the integration as one connection among several. A single clearinghouse outage should not stop every claim in the building, which is the lesson of the February 2024 Change Healthcare incident.
03What does the Change Healthcare breach mean for how we should build RCM software?
It means clearinghouse dependency is a design decision, not a vendor detail. A system built to speak to one clearinghouse only inherits that clearinghouse's downtime as its own. We design the integration layer so a second connection is a configuration change, not a rebuild.
04Can AI draft an appeal without a human reviewing it first?
We do not build it that way. A drafted appeal that cites its source figures and the applicable contract clause is what billing staff need to review and submit quickly. Sending an appeal with no human review risks citing the wrong basis, which a payer rejects just as fast as the original claim.
05We already have a billing system. Can you build denial management on top of it?
Usually yes. Most practice management and billing systems expose the 837 and 835 data even when they do not do much with it. We build the extraction, validation and routing layer on top, rather than replacing a system your staff already know.
Go deeper
- Healthcare software development →The wider constraints: audit trails, drift, and human-in-the-loop clinical AI.
- HIPAA-compliant development →The controls a build needs before protected health information reaches any system.
- PremiumAudit.io →Document parsing, figure validation and exception routing in a regulated money workflow.
- How do you build HIPAA-compliant AI? →Where PHI can and cannot reach a model, and what a BAA actually covers.
