What reviewers do with illegible fields is record that the value could not be read, not supply one. A reviewer marks the field unreadable, notes why, and checks whether the same value appears elsewhere in the packet. A field is blank only when the page truly shows nothing. A guess never goes into the record.
What counts as an illegible field for a reviewer?
An illegible field, for a reviewer, is one where the source page does not show a single value that two careful readers would both record. Hard to read is different: if zooming, adjusting contrast or reading the characters in context gives one clear answer, the field is legible. Illegible starts where a character could honestly be two things.
A simple test helps. Ask whether you could defend the value to a colleague by pointing at the page. "The third digit is a 3; you can see the flat top" is a defence. "It is probably a 3, because 8 would make the total too high" is a guess dressed as a reading. The second reviewer of the same field might choose 8 and be just as sure.
Causes on medical paperwork include faxed copies with broken strokes, a stamp or signature crossing a printed column, handwriting on intake forms, a fold or staple hole through a value, and dot-matrix print that has faded. The cause matters less than the result: the characters on the page do not settle the value.
Reviewers work from the field highlighted on the original page, not from the text the software extracted. The extracted text is a proposal. If the proposal reads cleanly but the page does not, the page wins, and the field is illegible. Software routing decides which fields reach a person in the first place; the post on routing unreadable medical scan fields to a person explains how a low confidence score sends a damaged field to review.
When most of a page is affected, the question changes from one field to the whole document. Deciding whether to rescan or request a new copy is covered in when to rescan a medical document instead of fixing it in OCR. This post deals with the single field a reviewer is looking at now.
Illegible field outcomes: unreadable flag, true blank or confirmed reading
Illegible field outcomes are the three values a reviewer may record: an unreadable flag, a true blank, or a confirmed reading. Each means something different downstream. An unreadable flag holds the field back for follow-up. A true blank says the page printed nothing. A confirmed reading says the reviewer can defend the value from the page or the packet.
Unreadable flag. The field has a value on the page, but it cannot be read. The record should hold the flag, the reason ("fax break through digits 4 to 6"), and nothing in the value itself. Downstream, a flagged field should not post, bill or feed a report until someone resolves it.
True blank. The box on the page is empty. This is a fact about the document, and it is safe to record. A true blank and an unreadable value must never share the same empty cell in your data, because one means "nothing was there" and the other means "something was there that we do not know". How validation rules should treat empty fields is explained in how validation treats missing and blank fields.
Confirmed reading. The reviewer can defend one value, either from the page itself or from another page in the same packet. If the value came from elsewhere, record where. "Member ID taken from page 2 header" lets anyone reviewing the field later check the same source.
Make the flag a real value in your system, not a note in a free-text box. A comment that says "couldn't read this" next to a filled-in value is the worst case: the value looks final, and the doubt lives somewhere a posting clerk will never see.
A decision table by field type
The table below uses fictional examples. Each illegible value is described, not shown, and every name and number is made up.
| Field | Fictional illegible example | Actions allowed | What gets logged |
|---|---|---|---|
| Member ID | Example ID "XKR4_0912" on a fax, fifth character broken | Flag unreadable; confirm from card copy or another page in the packet | Flag, reason, source page of any confirmed value, reviewer and time |
| Date of service | Line 2 date reads "10/_4/2026", tens digit of the day missing | Confirm from claim block or another line; otherwise flag | Final date and where it was found, or flag and reason |
| Allowed amount | Example amount "$1_8.00" with a stamp over the tens digit | Confirm only if a printed total proves it; otherwise flag | Final amount and the check used, or flag |
| CPT code | Five-digit code with the last two digits faded | Confirm from another copy of the claim; otherwise flag | Final code and source, or flag |
| Drug strength | Handwritten strength on a fictional prescription, units unclear | Flag unreadable and send for clarification; never confirm by inference | Flag, reason, request sent and to whom |
| Signature | Prescriber signature present but name cannot be read | Record signature present; flag the name as unreadable | Signature present, name flag, any signature log used |
The drug strength row is strict on purpose. A reviewer handles paperwork, not clinical judgment, and a strength is never worked out from what seems usual. If the page does not show it, the value goes back to the person who wrote it.
Why reviewers should not guess an illegible field's value
Reviewers should not guess an illegible field's value because a plausible guess looks exactly like a real reading once it is saved. On an amount, a code or a date, a wrong guess posts money to the wrong place, bills the wrong service or misses a deadline, while the record says a person checked it.
Consider three fictional cases. A reviewer guesses that "$1_8.00" is $148.00 because $148 is a common allowed amount on that payer's lines. If the true figure was $188.00, the account carries a $40.00 error and the variance surfaces weeks later during reconciliation, far from its cause. A guessed CPT code bills a different service than the one performed. A guessed day in a date of service can place a claim on the wrong side of a filing limit.
The second problem is trust. A field that a person approved is treated as checked. Teams reasonably skip re-checking approved fields, which is the point of review. A guess borrows that trust without earning it.
The third problem is consistency. Two reviewers guessing the same faint digit can guess differently, which shows up as noise when you measure how often reviewers agree. The post on inter rater reliability for document reviewers explains how to set apart splits caused by page quality from splits caused by unclear rules.
Guessing also hides the source problem. If every unreadable fax value gets quietly filled in, nobody counts how many came from one fax line or one payer, and the fix at intake never happens.
Recovering illegible fields from elsewhere in the packet
Recovering illegible fields from elsewhere in the packet means finding the same value printed clearly on another page, a related document or a total that proves it. A recovered value is a confirmed reading, not a guess, as long as the reviewer records where it came from and the source refers to the same patient, claim and service.
Good places to look on a single document come first. A member ID may appear in the page header, in the claim block and again on a remittance summary. A date of service may print once per line and again as a range at the claim level. A patient name may be typed in one place and handwritten in another.
A printed total can confirm an amount only when every other value in the sum is clear. If an EOB's line amounts must add to a printed claim total, and every other line is clear, the missing digit is fixed by arithmetic. That is a defensible reading. The technique, and its limits, is explained in arithmetic cross field checks on EOBs and bills. If two values on the page are unclear, the total no longer pins either one, and the field stays flagged.
Related documents can help when they describe the same event. A copy of the claim your practice sent supports a CPT code on the EOB that answers it. An insurance card copy in the intake packet supports a member ID. A prior visit's record supports a date of birth, but not a date of service, because the service is new.
Be strict about the match. The other document must refer to the same claim or encounter, not just the same patient. A procedure code from last month's claim is not evidence for this month's. When in doubt, flag the field and note the candidate source for whoever resolves it.
When should an illegible field go back to the sender?
An illegible field should go back to the sender when no other page settles it and the value affects payment, patient identity or the integrity of the record. Ask the payer, patient or practice for a corrected or clearer copy. Fields that only feed a report can wait, flagged, until the next document carries the value.
The sender depends on the document. A payer issued the EOB, so a reissued copy or a call to provider services settles a remittance amount. The practice that wrote a prescription clarifies a strength or quantity. The patient confirms intake details such as an address or an emergency contact. A billing service sends a clean copy of a claim it keyed.
Medicare's own reviewers use a similar route for illegible signatures. Chapter 3 of the CMS Medicare Program Integrity Manual, section 3.3.2.4 on signature requirements (section revision issued 12-18-24, read in October 2026), tells review contractors that when a required signature is illegible, the signature log process may be used to try to resolve it. It describes a signature log as a list of the typed or printed name of the author associated with initials or an illegible signature. That is guidance for CMS contractors, not a rule for your team, but it shows the same principle: when a mark cannot be read, the answer comes from the author's own documentation, not from a reviewer's inference.
The same chapter, in section 3.3.2.5, says the date and author of any amendment or correction to medical documentation should be identifiable. A corrected copy from the sender is worth keeping with its date and source for the same reason. Store it next to the original rather than replacing it.
Keep a short list of who to ask and how. A request that sits in one person's email stalls. A logged request with a date sent and a follow-up date gets resolved. Items waiting on an outside party should leave the active queue in a defined way, as described in how exceptions should leave the document review queue.
Illegible fields that block posting until resolved
Illegible fields that block posting until resolved are the ones where any value at all would be a risk: member IDs, drug strengths and allowed amounts lead the list. These cannot stay flagged in the background while the rest of the document moves on. The document waits, or the field is resolved first.
Member IDs. A wrong member ID can attach a payment or a record to the wrong person. Hold the document until the ID is confirmed from another page or from the sender. Do not post to the closest matching patient.
Drug strengths. A strength on a prescription or medication list is never recorded unless the page shows it clearly. A reviewer's job is to send it back for clarification, not to decide what it should be.
Allowed amounts. An allowed amount drives the contractual adjustment and the patient's balance. If it cannot be confirmed from the page or a printed total, the line should not post. Posting the rest of the EOB while one line waits can work, as long as the held line is visible and tracked.
Decide this list in advance and write it into the field rules. Reviewers should not have to judge, item by item, whether a flag is serious enough to stop posting. A fixed list also makes high stakes fields easy to route to a second person; the post on second level review for high risk fields covers how to set that up.
Schema Care sends fields under the threshold you set to a review queue, where the reviewer sees each one highlighted on the original page and approves or corrects it. Each of those decisions is logged with who made it and when, so each decision on a field carries its own history. The human review section on the homepage shows the four review steps.