Lab report OCR (optical character recognition) turns a scanned, faxed or photographed lab report into machine-readable text, with the position of each word on the page. It does not know which number is a result or which is a range. Trust it as a reader of characters, then check every value it reads before that value becomes data.
What lab report OCR produces before any field extraction
Lab report OCR alone produces text and positions, not fields. Its output is a list of words or lines, each with a page number, a bounding box and usually a confidence score. Deciding that "5.4" is a potassium result rather than part of a reference range is a later step done by a parser.
The open source Tesseract engine is a useful reference because its outputs are documented. The Tesseract command-line documentation lists plain text as the default output, plus hOCR and TSV formats in which each word carries a bounding box and a confidence value, and a PDF output that "creates a pdf with the image and a separate searchable text layer with the recognized text."
For one fictional result row, the difference between OCR output and extracted fields looks like this:
| Stage | What you get (example) |
|---|---|
| OCR, plain text | Hemoglobin 13.1 g/dL 12.0-15.5 |
| OCR, words with positions | Hemoglobin at x 72, 13.1 at x 240, g/dL at x 300, 12.0-15.5 at x 380, all on line 14 of page 1 |
| After parsing | test = Hemoglobin, value = 13.1, unit = g/dL, range = 12.0-15.5, flag = none |
The positions matter more than the plain text. Lab results print in columns, and plain text can join columns in the wrong order or merge two rows into one line. A parser that has each word's x and y position can rebuild the table. One that only has the text string has to guess.
OCR is only needed when a page is an image. Many lab reports arrive as digital PDFs that already contain a text layer, and reading that layer directly avoids recognition errors altogether. Old paper reports are the opposite case: they must be scanned first, and the post on how to digitize old lab reports kept on paper covers that project.
How accurate is lab report OCR on faxed and photographed pages?
Lab report OCR accuracy depends far more on the page image than on the software. Clean scans at a good resolution read well. Faxes, phone photos, skewed pages and tiny print lower accuracy most, and the errors cluster in exactly the places that matter on a lab report: small numbers, decimal points and symbols.
The conditions that hurt most, with what the engine documentation says about them:
- Low resolution. The Tesseract guide to improving quality says the engine "works best on images which have a DPI of at least 300 dpi." Many faxes arrive at lower resolution, and the small type of a reference range column suffers first.
- Skew. The same guide says line segmentation "reduces significantly if a page is too skewed." A fax fed in at an angle can shift a value onto the neighboring row.
- Uneven background and noise. Fax speckle and shadows from phone photos interfere with turning the page into black and white. The guide warns that some noise "cannot be removed" in that step.
- Scanner edges. Dark borders from a scanner can be read as extra characters, such as stray marks next to the first column.
- Tables. The guide notes that Tesseract has trouble recognizing data from tables without extra layout analysis. Lab reports are mostly tables.
- Phone photos. Curved pages, perspective and glare combine all of the above in one image.
There is no single accuracy number for lab report OCR, and a vendor figure measured on different documents tells you little about yours. Measure on your own pages, and measure at the field level: count how many result values, units and ranges came out exactly right, not how many characters. A page can score well on characters and still have one wrong digit in a result. The human review category covers how to measure extraction accuracy in general.
Can lab report OCR read handwritten results?
Lab report OCR can sometimes read handwritten results, but handwriting is the least reliable input on a lab report, and a handwritten value should always go to a person. On printed reports, handwriting usually appears as corrections, initials, added values or notes in the margin, each with its own risks.
The cases you will meet:
- Handwritten values on a form. Point-of-care logs and some requisitions carry results written by hand. Printed-text engines are tuned for type, so test any tool on your own handwritten samples before relying on it.
- Hand corrections on a printed report. A line struck through and a new value written beside it. OCR may read the printed value, the handwritten value, both, or neither. Extraction should treat any strike-through or nearby handwriting as a reason for review.
- Initials and dates. Initials next to a value often mean a person reviewed or changed it. Capture that something is handwritten there even if the characters cannot be read.
- Margin notes. Notes such as "repeat sent" or an arrow pointing to a row can change which value is current. They rarely fit a field, so flag them for a person to read.
The safe rule is simple: handwriting near a value turns that value into a review item. An official correction from the lab arrives as a corrected report, so a hand-written change on a printed copy is something to confirm, not something to file.
Lab report OCR errors that change a value: decimals, units and less-than signs
Some lab report OCR errors are cosmetic, such as a misspelled test name that still matches the right test. Others change a value, and those are the dangerous ones: a lost decimal point, a dropped less-than sign or a misread unit prefix produce a clean, plausible-looking number that the lab never reported.
Unit prefixes are a special case. The UCUM specification uses u as the plain-text symbol for micro, because the Greek letter μ is not ASCII, and m for milli. So "ug" is a legitimate way to write micrograms, while "mg" is a different unit a thousand times larger. An OCR engine that reads μ as "m" has changed the unit while producing a valid-looking result.
Every row below is a fictional example:
| Printed on the page | OCR read | What changed | Typical cause | Check that catches it |
|---|---|---|---|---|
| 1.8 | 18 | Decimal point lost | Faint dot on a fax, low resolution | Value outside the plausibility limits set for that test; compare with digits in the printed range |
| 0.48 | 048 or 0 48 | Point read as space or dropped | Speckle, tight spacing | Value text fails the number pattern |
| <0.5 | 0.5 | Less-than sign lost | Small symbol, light print | Flag the row when the source image shows a character before the digits; compare value with range wording |
| >1000 | 1000 | Greater-than sign lost | Same as above | Same as above |
| 5.0 μg/dL | 5.0 mg/dL | Micro read as milli | μ shape close to m in poor scans | Unit is not one this test is reported in by this lab |
| 5.0 μg/dL | 5.0 ug/dL | Micro written as u | Engine has no μ, or normalizes it | Accept as the UCUM form; map, do not reject |
| 7.1 | 7.7 | 1 read as 7 | Font, blur | Field confidence below threshold; row reviewed |
| 140 H | 140 | Flag lost to next column | Column misalignment | Printed range and value disagree with an empty flag field |
| 4.5-11.0 | 4.511.0 | Hyphen dropped | Thin dash | Range text fails the range pattern |
Each check compares the extracted data with the report itself or with what a test is normally reported in. None of them says anything about the patient. The rule set for these checks, unit and test pairs, plausibility limits and flag agreement, belongs to the post on checking extracted lab values against units and ranges, and the lab report parser guide shows where such patterns sit in code.
Test names suffer misreads too, though the effect is different. "Sodium" read as "Sodlum" is harmless if the parser matches names loosely, but a loose match can also pair a misread name with the wrong test when two names differ by one or two letters. Match test names against the list a given lab actually prints, and send anything that matches nothing, or matches two names equally well, to review.
Keep the confidence score for every field, not just every page. A page with one doubtful character in a result value should send that one field to review, while the rest of the page flows through.
Choosing a lab report OCR tool: a buyer's checklist
Choosing a lab report OCR tool starts with a test on your own reports, not a demo on the vendor's. Gather twenty to fifty de-identified or fictional pages that reflect what you really receive, including your worst faxes, and score each tool at the field level on those pages.
Questions to answer before you buy:
- Does it return positions and confidence per word or per field? Without positions you cannot link a value to its page, and without confidence you cannot decide what to review.
- Does it read the text layer of digital PDFs directly? Running OCR on a page that already has exact text adds errors for no gain.
- How does it handle tables? Check that rows stay together when a lab prints without ruling lines and when a test name wraps onto two lines.
- Does it keep symbols? Test pages with <, >, μ, ± and superscripts. Count how many survive.
- What happens with handwriting? Ask whether handwritten regions are flagged, not just whether they are read.
- Does it go beyond text? OCR alone stops at text. If you need fields, ask what produces them, and look at the output for a full report. The guide to turning a PDF lab report into structured data shows what that output should look like.
- Where do uncertain values go? A tool that writes every value straight into your system, sure or not, moves the checking work downstream where it is harder.
- What are the data terms? Lab reports name patients and their results. Ask where files are stored, who can see them, how long they are kept, and what agreement the vendor signs before any real report leaves your building.
Schema Care is built around the last two points: it scores every field it reads from a lab report, and the ones under the threshold your team sets wait for a reviewer instead of entering your records. Its compliance status on the homepage lists how far along each safeguard is. For background on how OCR works across all medical documents, see the medical OCR basics category.