UB-04 OCR reads a paper institutional claim by locating its numbered form locators, reading the revenue code lines in FL 42 to 48 as rows, and capturing the coded blocks for conditions, occurrences and values as pairs. The output is reliable once the line charges add up to the 0001 total and the dates agree.
What makes UB-04 OCR harder than reading a CMS 1500?
UB-04 OCR is harder than reading a CMS 1500 because the institutional form packs far more data onto one page. It has 81 form locators, a revenue line area 23 rows deep, coded blocks that only make sense as pairs, and claims that span several pages. Each adds a way for a value to land in the wrong field.
The UB-04 is the paper institutional claim, also called the CMS-1450. The CMS Medicare Claims Processing Manual, chapter 25 describes it as a uniform institutional provider bill used with many payers, and notes that the National Uniform Billing Committee (NUBC) maintains the approved coding for the form. The chapter's layout summary runs from FL 01 to FL 81.
Four differences from the professional claim cause most of the extra work:
- Density. The 1500 has six service lines. The UB-04 layout gives FL 42 to 48 rows 1 to 23, and chapter 25 puts the page count and creation date on line 23.
- Paired codes. Condition, occurrence and value codes each sit in small boxes beside a date or an amount. Reading the code without its partner is useless.
- Codes with structure. FL 4, the type of bill, is a four-digit code where each position means something different. A dropped leading zero changes how the rest is parsed.
- Length. Chapter 25 says Medicare contractors accept claims of up to 450 lines, which on paper means up to nine pages.
The meaning of each locator, from the provider block to the stay dates, has its own guide. The walkthrough of UB-04 form locators 1 to 41 for provider, patient and stay details explains them one by one.
Scan quality matters as much here as on any claim form. The guide to why paper CMS 1500 forms are printed in red dropout ink explains how a scanner drops a form template so only the typed data is read.
How does UB-04 OCR read revenue code service lines?
UB-04 OCR reads each revenue line as one row across FL 42 to FL 48: revenue code, description, HCPCS or rate, service date, units, total charge and non-covered charge. The engine anchors each row on its four-digit revenue code in FL 42, then assigns the other columns by position on the same printed line.
The chapter 25 layout gives the reader fixed widths to test against: up to 14 characters in FL 44, a six-digit date in FL 45, up to seven digits of units in FL 46 and up to nine digits in each charge column. What each column means is covered in UB-04 service line locators 42 to 49.
The revenue code column is the reader's best anchor. Chapter 25 says providers list revenue codes in ascending numeric order and avoid repeating them on the same bill where possible. If the extracted codes on a page are not in ascending order, either the form was filled unusually or a row was misread or skipped.
The description in FL 43 is a useful cross-check but not a source of truth. Chapter 25 marks it as not required and says it assists clerical bill review. Software can compare a description such as "LAB" against the code range it expects, and flag a row where the two disagree.
Outpatient bills add repetition. Chapter 25 says hospitals report a line item date of service for every iteration of a revenue code on outpatient bills, so a service rendered five times appears on five rows. A reader that merges identical-looking rows loses charges.
The total line is the one row that is not a service. Chapter 25 says there is no fixed total line in the charge area; the provider enters revenue code 0001 and puts the sum of charges beside it in FL 47. A reader has to recognize 0001 as the total, not as a seventh service, and keep it apart from the line list.
Handwritten additions to a typed UB-04 need extra care, such as a units figure written in after printing. The guide to handwritten claim forms and OCR covers when those entries can be trusted.
UB04 data extraction of condition, occurrence and value codes
UB04 data extraction of the coded blocks in FL 18 to 41 means capturing each code with the date or amount that belongs to it. Condition codes stand alone, but occurrence codes need a date, occurrence spans need two dates, and value codes need an amount. Splitting a pair breaks its meaning.
Chapter 25 describes each block:
- FL 18 to 28, condition codes. Two-character codes entered in numerical order, one per box.
- FL 31 to 34, occurrence codes and dates. Each event code is two alphanumeric characters with a six-digit MMDDYY date. Chapter 25 says the "a" line of FL 31 to 34 is completed before the "b" line.
- FL 35 and 36, occurrence span codes and dates. A code with a from date and a through date.
- FL 39 to 41, value codes and amounts. Two-character codes with an amount of up to nine digits, on four lines labeled a to d, in ascending code order. Chapter 25 says negative amounts are not allowed except in FL 41.
The output should keep these as structured pairs, not flat text:
| Block | Example code | Paired value (example) | Stored as |
|---|---|---|---|
| FL 18 condition | 17 | none | code only |
| FL 31a occurrence | A3 | 010805 | code and date |
| FL 39a value | 80 | 3.00 | code and amount |
The occurrence example comes from chapter 25 itself, which uses code A3 with the date 010805 to show benefits exhausted on January 8, 2005. The other codes are sample values chosen for the table.
Value amounts carry a trap. Chapter 25 says whole numbers and non-dollar amounts are right justified, and that some values are reported as cents. A reader that adds a decimal point by habit can turn a count into a dollar figure. Store the digits as printed and apply the meaning of the code afterwards.
Empty boxes matter too. Most claims fill only a few of these locators. A reader should return an empty list for an empty block, not a blank pair, so a later check does not mistake a gap for a missing date.
Multi-page UB-04 claims and continuation pages
A multi-page UB-04 claim spreads its revenue lines across continuation pages, and the reader must stitch them back into one claim. Chapter 25 says the "PAGE ___ OF ___" entry and the creation date on line 23 are reported on all pages. Those two values tell software which pages belong together and in what order.
The stitching steps are simple to describe:
- Read line 23 on every page to get its page number, page count and creation date.
- Group pages that share a patient control number in FL 3a, a creation date and a page count.
- Order the group by page number and check that no page is missing.
- Join the revenue lines from every page into one list.
- Take the 0001 total from the page that carries it and check it against the joined lines.
Problems show up at each step. A page scanned upside down or out of order is easy to fix once its number is read. A missing page is not: the sum check will fail, and the reason is a gap, not a misread. Report it as a missing page so nobody spends time correcting values that are right.
Header locators may repeat on each page. When they do, compare them rather than reading them once. A patient control number that differs between page 1 and page 2 means two claims were scanned together.
Mixed scan batches make this worse. When several UB-04s arrive in one PDF with letters and attachments, the pages must be split into claims first. The guide to claims data extraction covers separating claims from the other documents in a mixed file.
Checking UB-04 OCR output against the claim's own totals
Checking UB-04 OCR output against the claim's own totals means using the form's arithmetic and dates to catch misreads before the data is used. The revenue line charges must add up to the 0001 total in FL 47, and every service date must fall inside the statement covers period in FL 6.
A fictional UB-04 extraction sample
Every value below is invented for the example. The three revenue codes fall in the 0300 to 0319 range that chapter 25 identifies as laboratory tests; the descriptions are sample text.
| FL 42 code | FL 43 description | FL 45 date | FL 46 units | FL 47 charge read |
|---|---|---|---|---|
| 0300 | LAB | 031426 | 1 | 120.00 |
| 0301 | LAB | 031426 | 2 | 65.50 |
| 0305 | LAB | 031426 | 1 | 64.25 |
| 0001 | TOTAL | 269.75 |
The three line charges as read add up to $249.75, but the 0001 line says $269.75. The $20.00 gap points to one misread, and the 0301 line is the likely one, since a printed 8 read as a 6 produces exactly that difference. A reviewer looks at that charge on the page, sees $85.50, corrects it, and the sum matches.
Without the total check, that claim would have moved on with the wrong charge and no error message. The same check works on non-covered charges: chapter 25 says FL 48 is summed on the 0001 line as well.
Other checks to run on the same claim:
- Service dates inside the stay. Each FL 45 date should fall between the from and through dates in FL 6.
- Revenue codes in order. Codes on each page should ascend, per chapter 25.
- Type of bill shape. FL 4 should be four characters with a leading zero.
- Diagnosis code shape. Chapter 25 says FL 67 holds the full ICD code without the decimal point, which is implied, and FL 66 says which ICD version is used.
- Billing provider NPI. FL 56 holds it; the CMS NPI check digit requirements describe a Luhn check digit, which fails whenever a single digit is misread.
These checks work regardless of how the form was read. A system built on fixed coordinates and one built on a layout model both need them, and the trade-offs between those two approaches are covered in template based vs AI medical document extraction.
Schema Care reads UB-04 fields along with CMS-1500 data, and any field it is not sure of waits in a queue for a person to confirm against the highlighted page, as the human review steps describe.