EOB Data Extraction: The Fields Worth Capturing

EOB data extraction should capture fields at three levels: the payment header, each claim, and each service line under it. Amounts and codes must stay attached to their line. Check the results with balancing rules that add lines up to claims and claims up to the payment, and link every value to its spot on the page.

EOB data extraction field list: header, claim and service line

An EOB data extraction field list has three levels. The header describes the payment: payer, payee, check or EFT number, date and total. The claim level identifies the patient and the claim. The service line level holds the procedure, dates, amounts and adjustment codes. Each level needs its own fields and its own checks.

The levels follow how an explanation of benefits (EOB) is built. The CMS guide to the explanation of benefits lists the facts an EOB carries, including the patient, the plan, the provider and service dates, a claim number, the payee, the provider's charges and what the insurer paid. A provider EOB groups many such claims under one payment, so the header sits above them all.

The table below is a starting schema of fifteen fields. Every example value is fictional. The validation rule is the test a value must pass before it is accepted.

Remark codes, units, modifiers and the rendering provider are common additions. Add them when your posting process uses them. A field you never post or check is a field you pay to capture and never use.

The adjustment row is really a repeating group. One line can carry several group code, reason code and amount sets, and each needs its own row in the output. A schema with one adjustment column per line will lose the second code.

Which EOB fields need line-level extraction?

EOB fields need line-level extraction when they describe one service rather than the whole claim: procedure code, date of service, billed, allowed, adjustments, patient share and paid. These values only make sense attached to their line. Captured as a loose list for the claim, they cannot be posted, because the billing system posts payment line by line.

Consider a fictional claim for Jordan Ellis with two lines. Line one is a 99214 visit billed at $275.00 and paid $148.00. Line two is a lab draw billed at $45.00, denied with CO-97 and paid $0.00. If the extraction returns "billed: $275.00, $45.00; paid: $148.00, $0.00" with no line link, a poster has to guess which payment goes with which service.

Adjustment codes are the strongest case for line-level capture. CO-97 on line two means the lab draw's benefit is included in another service. Attached to line one by mistake, it would suggest the visit was bundled, and the poster would write off the wrong charge.

Some fields can appear at either level. A remark code may apply to a single line or to the whole claim. Capture it where it was printed and record which level that was. Chapter 22 of the Medicare Claims Processing Manual on remittance advice treats the electronic version the same way, with separate places for line-level and claim-level remark codes.

A good test for any field: if the payer could print a different value for each line, extract it per line.

Checking extracted EOB amounts against totals

Checking extracted EOB amounts against totals means adding values up the levels and confirming each sum. Each line's billed amount minus its adjustments should equal its payment. Each claim's line payments should equal the claim total. The claim totals, plus any provider-level adjustments, should equal the check or EFT amount in the header.

The same principle governs the electronic remittance. Chapter 22 of the Medicare manual says remittances "must balance at the service, claim, and provider levels," and that "the total paid amount is equal to the total submitted charges plus or minus payment adjustments." Paper EOBs are a printout of the same logic, so the same rules apply to data extracted from them.

The checks, in order:

1. Line: billed minus the sum of all adjustment amounts equals paid.
2. Line: allowed minus patient responsibility (PR) amounts equals paid, where the payer prints an allowed amount.
3. Claim: the sum of line payments equals the claim's paid total.
4. Page: where the EOB prints page totals, the sum of claims on the page equals the page total.
5. Payment: the sum of claim payments, plus or minus provider-level adjustments, equals the header total.

Run them in that order. A failure at the line level points to one line. A failure only at the payment level, with every claim balancing, usually means a provider-level adjustment was missed. These are amounts such as recoupments of earlier overpayments or interest, which change the check without belonging to any claim. Chapter 22 calls them provider level adjustments and notes they are explained with their own reason codes.

A worked example, with fictional values: the header shows $4,318.60. The claim totals add to $4,393.60. The $75.00 gap matches a recoupment printed at the end of the EOB for an earlier claim. Once that adjustment is captured, the payment balances.

The balancing rules do not tell you which value is wrong. They tell you where to look. That is enough to send one line to a reviewer instead of the whole document. Validation rules and review queues in general are covered in the human review category.

How do you trace extracted EOB data back to the source page?

You trace extracted EOB data back to the source page by storing, with each value, the page number and the position where it was read. A reviewer can then open the original image with the field highlighted. Pair that link with an audit history of who approved or changed each value, and when.

The page link answers the first question anyone asks about a suspect number: what does the paper say? Without it, a reviewer has to find the right page of a forty-page EOB, find the right patient, and find the right line. With it, they click and see the value in place.

The audit history answers the second question: who decided this value was right? When a balance is disputed months later, the record should show whether a person approved the amount, corrected it, or let it pass on a high score. Each change should keep the old value as well as the new one.

Every Schema Care field comes back with a confidence score and a link to where it appears on the page. Reviewers see the field highlighted on the original, and each approval or correction is logged with who made it and when, as the human review workflow shows.

Keep the source image as long as you keep the extracted data. A page link that points to a deleted file is no link at all. Your retention schedule should cover both together.

EOB data extraction on multi-claim pages: keeping lines with the right patient

EOB data extraction on multi-claim pages has to detect where one claim ends and the next begins. A provider EOB can hold several patients on one page and split a claim across a page break. If the boundary is missed, a service line is posted to the wrong patient, and both accounts end up wrong.

Each claim block usually starts with a patient line: name, member ID, patient control number and payer claim number. That line is the boundary marker. Every service line after it belongs to that patient until the next patient line appears.

Page breaks complicate this. A claim that starts at the bottom of page three may continue at the top of page four, often with no repeated patient line. The extraction must carry the current patient forward across the break rather than starting fresh.

Claim totals are the check. When a claim's line payments add up to its printed total, the boundary was right. When a claim seems to have one line too many and the next claim one line too few, a line crossed the boundary.

Here is a fictional case. Page two ends with two lines for Jordan Ellis. Page three starts with one more line, then a new patient line for Priya Natarajan. The extraction assigns the first line on page three to Priya. Jordan's claim total is now $40.00 short and Priya's is $40.00 over. Moving the line back to Jordan balances both.

Bulk EOBs from some payers need splitting before extraction even starts. The post on splitting a bulk EOB by patient using page markers and claim breaks covers that step.

Extracted EOB values that balance but are still wrong

Extracted EOB values can balance and still be wrong when two errors cancel or when values land in the wrong fields with the same totals. Balancing proves the arithmetic is consistent. It does not prove each number is in its right place. A swapped pair of columns, or two offsetting misreads, passes every sum.

Swapped columns are the common case. Suppose a line's patient share is $37.00 and the plan payment is $148.00. If extraction swaps them, the line still balances against billed and adjustments, because the sum of the two is unchanged. The claim total of patient shares and payments shifts, but if the claim has one line, the claim balances too. The patient is now billed $148.00.

Offsetting misreads are rarer but real. One line's $35.00 is read as $85.00 and another line's $95.00 is read as $45.00. The claim total is unchanged. Each line fails its own check, though, so line-level balancing catches this case. The danger is a setup that checks only claim or payment totals.

Several checks catch what balancing misses:

• Allowed versus paid: a paid amount larger than the allowed amount is a sign of a swap.
• Group code logic: PR adjustment amounts should match the patient share field. If they do not, the columns may be crossed.
• Billed amount match: the billed amount should match what your system sent on the claim.
• Spot checks: compare a small sample of balanced lines with the page image each week, because no rule catches every swap.

Column drift and other reading errors are covered in where explanation of benefits OCR slips. For the step after extraction, the post on EOB processing from mailroom to posting shows how clean fields reach the posting desk. When payers send electronic files instead of paper, the post on ERA 835 processing explains the same data in its electronic form.