Schema Care

Second Level Review for High Risk Fields: When to Add It

By Schema CarePublished Updated

Second level review for high risk fields means a second person checks a small set of extracted fields after the first reviewer finishes. Reserve it for fields where one wrong value moves money, attaches data to the wrong patient or misses a deadline, and trigger it by rule so the queue keeps moving.

What second level review adds after the first reviewer

Second level review adds an independent look at a field the first reviewer already approved or corrected. It catches errors a first reviewer makes while feeling sure: a transposed digit typed during a correction, a value taken from the wrong line, or a plausible proposed value approved without a close look at the page.

The first reviewer's errors have a particular shape. One source is the act of correcting, since typing a value creates a new chance to mistype it. Another is attention: a reviewer who has approved 50 clean fields in a row may read the 51st less closely. A second person, arriving fresh, does not share either habit for that field.

A second reviewer is not a better reviewer by default. The value of the check comes from independence and from focus on a short list of fields, not from seniority. A senior person who checks every field on every document soon becomes a bottleneck and starts approving quickly too. The habit of approving whatever is proposed has its own fix in training, described in training document reviewers not to rubber-stamp approvals.

Second level review also differs from quality sampling. Sampling looks back at a random slice of finished work to measure error rates, including fields that skipped review entirely; the reasons are set out in why sample fields that already passed the confidence threshold. A second level check happens before the value is used, on chosen fields, and its purpose is to stop the error, not to count it.

Which fields count as high risk for second level review?

High risk fields for second level review are the ones where a single wrong value causes harm that is costly or slow to undo. Three tests decide it: how much money the field moves, whether it changes what gets posted or to whom, and whether a later step relies on it without checking again.

Money. An allowed amount, a payment or an adjustment on a large line moves real dollars. A wrong digit on a $4,000 line costs more than on a $40 line, and the error may not show until reconciliation.

Posting impact. A member ID or patient account number decides where everything else on the document lands. A wrong value there spreads a single mistake across every line.

Downstream use. A diagnosis code may feed a claim, a report and an appeal. A date of service decides filing limits. Under federal rules at 42 CFR 424.44 in the eCFR, a Medicare claim for services furnished on or after January 1, 2010 must be filed no later than the close of the period ending 1 calendar year after the date of service, with listed exceptions. Other payers set their own limits.

A field that fails none of the tests does not need a second person. A provider phone number or a payer address can be wrong without moving money, and the next document may correct it.

Units of service are a borderline case worth calling out. CMS describes a Medically Unlikely Edit on its NCCI MUE page (last modified 08/31/2026) as the maximum units of service reported for a HCPCS/CPT code on the vast majority of appropriately reported claims by the same provider for the same beneficiary on the same date of service. A units field that was misread as 10 instead of 1 is the kind of value an outside edit may catch later, after the claim has gone out. A second look before then is cheaper.

Routing rules that send high risk fields to a second reviewer

Routing rules that send high risk fields to a second reviewer come in three forms: every time the field appears, only after the first reviewer corrected it, or only when its confidence falls below a second, stricter line your team sets. If your log shows first-level errors cluster in typed corrections, start with the correction trigger.

Every time. Use this only for fields that are rare and severe, such as a drug strength on a medication list. If the field appears on most documents, sending all of them doubles the work for that field.

After a correction. The second reviewer sees only fields the first reviewer changed. It focuses effort on new values that no machine has proposed, which also means no confidence score stands behind them.

Below a stricter line. You can also send a field to a second person when its score was very low, even if the first reviewer approved it. This is a working rule your team applies, using the score as one input. How to choose score cutoffs by field type is covered in tuning thresholds per field type: amounts, codes, names and dates.

An example routing table

The table below is fictional. The dollar line, the units cap, the deadline window and the minutes are example values for a team processing EOBs and claims. Minutes are per 100 documents.

FieldTrigger (example)Who reviewsDocuments triggered per 100Minutes per checkExtra minutes per 100 documents
Allowed amountAny line above $2,000Senior payment poster81.512
Drug strengthEvery value on a medication listLead reviewer5210
Member IDCorrected by first reviewerAny second reviewer10110
Units of serviceAbove 4 units on one lineCoding lead616
Date of serviceWithin 30 days of the payer's filing limitBilling lead326
Diagnosis codeCorrected by first reviewerCoding lead121.518
Total62

Each row is documents triggered times minutes per check: for example, 8 × 1.5 = 12 for allowed amounts. A document can trigger more than one row, so the documents column does not add to a count of distinct documents.

Product settings support this indirectly. Schema Care gives every field a confidence score, sends fields under the threshold you set to the review queue, and logs each approval and correction with who made it and when. On the Group plan, review thresholds can be set per document type, as listed on the Schema Care pricing plans. The second check itself is a team rule run on top of that record.

Blind vs informed second level review

Blind second level review hides the first reviewer's answer, so the second person reads the page from scratch. Informed review shows the first answer and asks for agreement. Blind review keeps the second reading independent, since nothing anchors the second reader, but it takes longer. Informed review is faster and works for fields where the check is quick.

The risk in informed review is anchoring. Shown a finished value, a busy reviewer can slide into confirming it. That is the same pull the first reviewer felt toward the software's proposal, now one step later. For an allowed amount on a dense EOB, an informed check can turn into a glance.

Blind review costs time because the second person must find the value on the page again. On a well-laid-out document with the field highlighted, the extra time is small. On a long medical record, it can double the check.

A practical split, offered as an example, is blind review for identity fields and amounts, where independence matters most, and informed review for codes, where the second reviewer is checking that a valid code was copied correctly. Whichever you choose, record which mode was used, because it changes how you read the results later.

Blind second checks also give you agreement data for free. Two independent decisions on the same field are exactly what inter rater reliability for document reviewers measures. Informed checks cannot be used that way.

How much time does second level review add per document?

Second level review adds the sum, over each high risk field, of how often it triggers times how long one check takes. Estimate it from your own correction log before turning anything on: count how often each trigger would have fired last month, time a handful of checks, and multiply.

Using the fictional routing table above, the six rules add 62 minutes per 100 documents, or 0.62 minutes per document. A team handling an example 400 documents a week would add 4 × 62 = 248 minutes, a little over 4 hours of reviewer time each week.

Time the checks rather than guessing. Ask two reviewers to do 20 second checks each for one field type and note the minutes. The figure will differ by document type: a units field on a clean claim form takes seconds, while finding a dosage on a long discharge summary takes longer.

Watch for hidden waiting time. A field that needs a coding lead waits until that person is free. If the document cannot post until the check is done, the delay matters more than the minutes. Batch second checks at set times of day so they do not interrupt first-level work.

Turning minutes into staff hours and coverage plans is covered in how many reviewers a review queue needs. Run that calculation with the second level minutes included, so the extra check does not quietly slow the main queue.

Illegible values deserve a note here. A first reviewer who flags a high risk field as unreadable should not pass it to a second reviewer for a better guess. The flag goes to the sender instead, as described in what reviewers do with illegible fields.

When second level review of high risk fields stops paying off

Second level review of high risk fields stops paying off when the second person almost never changes a value. Track the change rate per routing rule each month. If a rule fires hundreds of times and changes a handful of values, narrow it, move it to periodic sampling, or retire it.

Work out the cost per caught error. In a fictional quarter, the diagnosis code rule sends 600 fields to a second reviewer at 1.5 minutes each, which is 900 minutes, or 15 hours. If the second reviewer changed 3 of those values, each caught error cost 5 hours of review. Compare that with what one wrong code costs your team in rework and delay. If a wrong code costs more than 5 hours to fix, the rule pays for itself; if it costs less, narrow the rule.

Low change rates have more than one cause. The first reviewers may have improved, which is good news. The rule may be too broad, sending clean fields that never needed a second look. Or the second reviewers may be approving without checking, which a few planted errors can reveal.

When a rule is no longer worth running, narrow it before dropping it. Raise the dollar line, limit the trigger to one payer whose EOBs cause trouble, or keep only the correction trigger. If even the narrow version rarely finds anything, move the field into your periodic quality sample and let the sample tell you if errors return.

Revisit the list after any change upstream. A new payer layout, a new document type or a change to your confidence threshold can bring old errors back, and a rule you retired may need to return for a month while the change settles.

All posts in Human Review and Confidence