When you buy OCR with human review, look for five things: a confidence score on every field, a link from each value to its spot on the page, a review screen that highlights that spot, a threshold you set yourself, and a log of every approval and correction. Then test it on your own documents before real patient data.
What OCR with human review should include
OCR with human review should include a full review workflow, which is more than an editable results screen. A correction screen lets someone fix a value they happen to notice. A review workflow decides which values need a person, shows that person the evidence, and records what they decided. The difference shows up the first week real volume arrives.
A review workflow has parts that depend on each other. Optical character recognition (OCR) turns the scan into text, and extraction fills named fields such as a member ID or a paid amount. After that, a working product needs:
- A confidence score per field. A single score for the whole document hides the one bad field on an otherwise clean page.
- A source link per field. Each value points to the exact region of the page it came from.
- Routing by threshold. Fields under a set score go to a queue; the rest pass.
- A review screen with the page. The reviewer sees the value and the highlighted region side by side.
- A log. Every approval and correction is stored with who made it and when.
If a product has the first item but not the others, you will end up checking whole documents by hand, because you cannot tell which fields to trust. If it has a review screen but no log, you cannot answer later why a value changed.
A ten-item buyer checklist
Use this list in every demo and trial. Each item is something you can see working, not a promise.
- Per-field confidence scores, visible to reviewers and exportable.
- A source link from each field to its location on the page.
- Highlighted review: the value and the region shown together on the original page.
- A threshold you set, ideally per document type or field type.
- Logged corrections: the old value, the new value, the reviewer and the time.
- An export of that log you can hand to an auditor or a manager.
- A signed business associate agreement before any real patient data is sent.
- A trial on de-identified sample documents first.
- An accuracy test on your own documents, scored field by field.
- A clear list of the document types covered, such as EOBs, CMS-1500 claims, lab reports or intake forms.
What a correction log should hold, field by field, is covered in the post on what an audit trail for reviewer corrections should record.
Source-page highlighting in the OCR review screen
Source-page highlighting in the OCR review screen means the reviewer sees the extracted value with a box drawn around the place on the scanned page it came from. Without it, the reviewer either trusts the value blindly or goes looking for the paper. Both defeat the point of review, which is a fast, informed yes or no.
Consider a fictional example. An EOB for a fictional patient, Ray Sample, lists two service lines on the same date. The software reads the plan payment as $112.00 and flags it at 81%. With highlighting, the reviewer sees the box sits on line 1, not line 2, and that the printed amount is $142.00 under a fold mark. The fix takes seconds. Without highlighting, the reviewer sees "$112.00, 81%" and has to open the PDF, find the page, find the line and compare.
Highlighting also catches a class of error that a score cannot: a correct-looking value read from the wrong place. A date of service and a date the EOB was printed can both be valid dates. A highlight on the wrong one shows the reviewer at a glance that the field was pulled from the header instead of the service line.
When you test a product, open a multi-page document and check three things. The highlight should land on the right page. It should cover the value, not the label beside it. And it should still line up on a skewed or faxed scan, since those are the pages most likely to be in the queue.
Can you set your own review threshold in the OCR tool?
You should be able to set your own review threshold in the OCR tool, and a product that fixes the threshold for you is a warning sign. The threshold is the score a field must reach to skip review. Your team knows what an error costs in your workflow; the vendor does not, so the decision belongs with you.
A threshold trades review time for safety. Set it high and more fields go to the queue, including many that were right. Set it low and fewer fields wait, but more errors pass. The right point differs by field. A member ID on an EOB or a dose on a prescription can justify a higher bar than a payer's phone number.
That is why per-document-type or per-field thresholds matter in practice. One number for every field forces a compromise that is too strict for some fields and too loose for others. Ask whether the product lets you change the threshold without a support ticket, and whether you can see how many fields each setting would route before you save it.
How to pick the number once you have a tool, using test data, is a separate job covered in the guide to what a confidence threshold for extraction decides. The case for routing on scores instead of keying everything twice is in the comparison of double data entry vs confidence based review.
What should you ask before buying OCR with human review?
Before buying OCR with human review, ask questions that make the vendor show the product working on paperwork like yours. Ask what a reviewer sees, how the threshold is set, what the log records, which documents are covered and when a business associate agreement is signed. A live demo beats a slide.
Questions that tend to separate real review workflows from thin ones:
- "Show me a field below the threshold." You want to see the queue, the highlighted page and the approve and correct buttons.
- "What happens to the other fields on that document?" They should pass on their own, not wait for the one flagged field.
- "Show me the log entry after I correct this." It should name the reviewer, the time, and the old and new values.
- "Can I export the log?" A log you cannot get out is hard to use in an audit.
- "Which document types does this read today?" Get the list in writing, with the fields read from each.
- "How do I test it on my own documents?" A good answer involves de-identified samples you choose, scored field by field.
- "When do we sign a BAA?" It should come before any real patient data.
The BAA question has a regulatory basis. Under 45 CFR 164.502(e) on eCFR, a covered entity may let a business associate handle protected health information if it "obtains satisfactory assurance that the business associate will appropriately safeguard the information," and those assurances must be documented through a written contract or other written agreement. Ask your own compliance lead what your organization requires.
Vendor accuracy numbers deserve their own scrutiny, since the same tool can report very different figures depending on what is counted. The post on what a vendor accuracy claim usually measures explains how to read them.
Red flags in an OCR human review product
Red flags in an OCR human review product are signs that review is an add-on rather than the core of the design. Watch for demos that only use clean sample documents, accuracy claims without a definition, a threshold you cannot change, and corrections that leave no record. Each one means more manual checking after you sign.
Demo red flags:
- Only perfect scans. If the vendor will not run a faxed, skewed or handwritten page, you have not seen the queue under real load.
- No visible scores. A product that hides confidence from reviewers leaves them guessing which fields to doubt.
- Review of whole documents only. If a reviewer must re-read every field to fix one, you have bought a slower form of data entry.
- One accuracy number. A single percentage with no field-level breakdown tells you little about the fields you care about.
Contract and setup red flags:
- Real patient data before a BAA. Any request to send live records first is a reason to stop.
- No log export. Corrections you cannot extract are hard to audit or learn from.
- Vague document coverage. "We read any medical document" without a field list means you will find the gaps yourself.
- No way to test on your own files. A trial limited to the vendor's samples proves little about your EOBs or intake forms.
If you are weighing whether a person needs to check anything at all, the cost side of that choice is worked through in human review vs full automation. Buyers who also need clinical abstraction from charts may want the separate guide to medical record abstraction software.
Where Schema Care fits for OCR with human review
Schema Care fits buyers who want OCR with human review built in from the first field. Each extracted value carries a confidence score and a pointer to its spot on the page. Anything under the threshold you choose waits in a queue, where a reviewer approves or fixes it against the highlighted scan, and the system records who acted and when.
Against the checklist above, here is what the current plans cover, as listed under Schema Care plans and pricing. A Free plan reads de-identified sample documents, up to 500 pages a month, with the review queue, so you can test on your own paperwork before anything else. The Clinic plan adds a BAA, three reviewers and the audit log with exports. The Group plan adds unlimited reviewers and review thresholds per document type. A Health system plan covers volume pricing, a security review, EHR and billing-system integrations and single sign-on.
Schema Care reads EOBs, CMS-1500 and UB-04 claims, lab reports, prescriptions, discharge summaries, billing statements, intake forms and medical records. It does not offer an API, an SDK, FHIR output or 835 files, and it does not publish accuracy figures, so test it on your documents rather than taking a number on trust. You can try the threshold on a fictional EOB in the interactive review demo, or select Get started to sign in to Schema Care.