This system map is part of the claim denial routing guide. It is for billing operations consultants who need to say, at metadata level, whether a client's denial history can be joined line by line across its tools.
The systems and what each one knows
An unpaid claim passes through at least four systems, often five. Each one holds a different part of the story and shares at least one key with the next.
| System | Records it holds | Linking key | Usual owner |
|---|---|---|---|
| Billing system (practice management) | Claims, lines, 835 files with reason and remark codes per line, claim edit history, corrected claims | Claim number and line number | Billing operations |
| Work-queue tool | Cases, queue assignments and reassignments, resolution codes and notes, the rule that fired | Case ID, linked to claim number | Work-queue team leads |
| Rule configuration | Routing rules, their versions, the mapping from codes to queues | Rule ID and version | Revenue cycle analyst team |
| Authorization tracker | Authorization requests, numbers and work queue entries | Authorization number, linked to claim or visit | Authorization team |
| Ticket tracker (often) | Rule change requests with reasons and approvers | Change ticket number, referencing rule ID | Revenue cycle head |
The billing system is the anchor because it receives the payer's 835 file. Everything else hangs off the claim number, but only some systems also store the line number, and that is where most joins fail.
The keys, one hop at a time
Claim and line number. The billing system stores both. Many denial case managers open one case per claim, so two causes on two lines share a case. Ask whether cases are per claim or per line.
Reason codes per line. The adjustment and remark codes as the payer sent them. The work-queue tool usually stores a mapped category chosen by the rule, not the original codes, so the billing system is the only place the payer's own wording survives. A test for completeness follows below.
Rule ID and version. The work-queue tool may record which rule fired, and sometimes its version. If rules were edited in place, old versions are gone and only the current logic survives.
Case ID and timestamps. Assignment and reassignment times show how long a line sat in each queue. Manual reassignments recorded only in free-text notes are hard to join.
Remittance per line. The next 835 file for each line is the checked result. Cases closed on resubmission, before the payer pays, lose that link.
One fully joined case (Illustrative)
A fictional 410-person billing company working claims for physical therapy practices. A single-line claim for a course of therapy comes back unpaid for a missing authorization. This time the routing was right; the question is whether the company can still show why the authorization was missing and how long the fix took. The table follows the keys from system to system.
| Hop | From | To | Key | What the join adds |
|---|---|---|---|---|
| 1 | Billing system | Work-queue tool | Claim number | Case opened the day the 835 file arrived |
| 2 | Work-queue tool | Rule configuration | Rule ID and version | Rule version 6 sent the line straight to the authorization team |
| 3 | Work-queue tool | Authorization tracker | Claim number and visit date | Request logged one day after the first visit, approved for later visits only |
| 4 | Authorization tracker | Billing system | Authorization number | Retroactive approval after the payer's review, with the clinic's note as the reason |
| 5 | Billing system | Billing system | Claim and line number | Corrected claim with the new authorization number |
| 6 | Billing system | Work-queue tool | Claim and line number | Paid on the next 835 file; case closed with resolution code "late request" |
Every hop found its key, so the case is fully joined: the unpaid line, the rule that routed it, the late request that caused it, the fix and the payment. Hop 3 is the one most often missing, because many authorization tools store the patient and visit date but not the claim number, so the join depends on matching dates. A case where the rule itself was wrong, worked step by step, is in the claim denial routing exception examples.
Two checks on the reason codes
X12 maintains both code lists. Claim Adjustment Reason Codes (CARCs) explain why a line was paid differently from how it was billed, and Remittance Advice Remark Codes (RARCs) add detail. CARC 16 requires at least one remark code, so a line stored with CARC 16 and no remark means part of the 835 file was not kept. CARC 197 points to missing precertification or authorization, which is why hop 2 above sends the line to the authorization team.
RARCs also carry start and stop dates on the X12 list, so a code on a six-year-old 835 file may be retired today. A reconstruction needs the list that applied when the 835 file arrived. Both checks can be answered by the billing administrator without opening a claim.
Where joins break
| Hop | Common gap | What to note |
|---|---|---|
| Claim to case | Case opened per claim, so two causes share one case | Whether cases can be split by line, and from which year |
| Codes to category | Mapping table changed without a log | Whether the mapping has its own history |
| Case to rule | Rules edited in place, old versions lost | Year rule versioning began, if ever |
| Reassignment | Manual moves recorded only in notes | Whether reassignment is a logged field |
| Case to outcome | Case closed on resubmission, before payment | Whether closed cases link to later 835 files |
| Routing outside the tool | Payer exceptions kept in side files | Which side files exist and who keeps them |
Export capability varies by product, version and contract. The company's administrators should confirm what history each system can produce and whether case-to-claim links survive a system change; a partner records their answers, not assumptions.
Questions for the revenue cycle head
Keep the conversation at metadata level: systems, years, keys and owners. Do not ask for 835 files, case exports or logins: they identify patients. A billing company works on behalf of its provider clients, so their agreements decide what it may do with claim-level records, and anything patient-level would need de-identification before any review. Rule tables and change tickets often identify no patient at all; operational data without patient identifiers explains why that matters.
The revenue cycle head convenes; authority to discuss licensing sits with the CEO, with the COO or general counsel advising. The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. What stays unknown until SourceX reviews it: buyer interest, the rights result for each client's data, the de-identification required and any offer.
For the wider category, see billing company data; for an owner weighing a sale, selling a billing company; and for agencies that run their own claims, home health agency data.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the map shows a billing client can join claims, lines, rule versions, queue history and later 835 files for several years, register as a partner, confirm the company against who qualifies and read the program terms before you introduce the revenue cycle head.