CASE STUDY · CLIENT PROJECT · DOCUMENT AI
Docutize.ai
Turns scanned laboratory reports — medical, water and other testing — into one clean, exportable table. I built the entire backend: from character detection to the final merged table — 98%+ character accuracy and 99% column matching, in about 3 seconds a page.
SCANNED PDF · PAGE 1 OF 3
YOLO + OCR
detection check: “3B.5” → “38.5” · B is invalid in a numeric column
MERGED TABLE · 3 PAGES
~3 s / page
columns matched across pages: Result ≈ Value ≈ Measured
Illustrative sample values — not client data.
- CLIENT
- Docutize.ai
- USERS
- Testing laboratories in Europe
- MY ROLE
- Built the entire backend & AI pipeline
- SPEED
- ~3 s per page · 98%+ character accuracy
CAPACITY & COST
How much it can process — and what it saves.
01 · CAPACITY
Pages it can processPER HOUR
~1,200
pages
PER DAY
~28,800
pages, running 24/7
PER MONTH
~864,000
pages, running 24/7
Docutize.ai
~1,200 pages / hour
One person, entering + checking
~30 pages / hour
About 40× faster than one person — and it doesn't stop at the end of a shift.
02 · COST
Same 5,000 pages a month: manual vs softwareMANUAL
~167 hours
~€4,170 / month in staff time
DOCUTIZE.AI
~4 hours
of automatic processing
SAVED IN STAFF TIME
~€4,060 / month
~€48,700 a year — about one full-time data-entry role
Assumptions: manual entry + checking at 2 min a page · staff cost €25 / hour · Docutize.ai at ~3 s a page · savings shown before software cost.
And beyond time: 98%+ character accuracy instead of manual typing errors in medical and water results, and no page limit — volume grows without hiring.
THE PROBLEM
Lab results live in scanned PDFs. One wrong digit is a wrong result.
Laboratories across Europe — medical, water and other testing — exchange results as scanned PDF reports. Every lab formats its tables differently, tables run across pages, and column names change from page to page.
Re-typing them is slow and error-prone. Generic OCR isn't good enough either: a misread “8” or a shifted column silently corrupts the data. The system had to be accurate at character level, understand table structure, and stitch pages back together.
Scanned page in. One clean table out.
Computer vision finds every character. Language models understand the structure. Custom algorithms check both.
01 · INGEST
Scanned PDF to pagesMulti-page reports uploaded through the API and split into page images.
02 · OPENCV
Image enhancementOpenCV clean-up so faint, skewed or noisy scans become readable.
03 · YOLO
Character detectionObject detection pipelines that locate characters on the page.
04 · CORRECTION
Detection correctionCustom algorithms that find and fix wrong YOLO detections, improving accuracy.
05 · TESSERACT
Tesseract OCRTesseract reads text from the detected, cleaned-up regions.
06 · OPENAI
Structure & meaningOpenAI models understand the report and organise the data.
07 · MATCHING
Cross-page column matchingData from every page compared; similar columns identified automatically.
08 · EXPORT
One table outEvery page merged into a single table, ready to export.
PERFORMANCE ENGINEERING
OpenCV and OCR are heavy. I made them fast.
Image processing and OCR on every character of every page is CPU-hungry. I optimised the pipeline at four levels to get extraction to around three seconds a page.
~3s
per page, full extraction
CODE
CythonHot paths compiled for C-level speed.
MEMORY
Memory optimisationLower footprint for large multi-page scans.
I/O
Multi-threadingConcurrent work where tasks wait on I/O.
CPU
Multi-processingOpenCV and OCR spread across cores.
A DESIGN DECISION
Why not just send pages to a vision LLM?
It's the obvious first idea. For lab results, it's the wrong default. I use language models where they're strongest — understanding structure — and keep character reading in a pipeline I can measure and correct.
01 · ACCURACY
Every digit is checkableCharacter-level detection with correction rules catches a “B” in a numeric column. A model that rewrites a whole page can silently change a result.
02 · COST
Predictable at volumeThousands of pages a month on optimised local vision costs far less than a large vision model call on every page.
03 · PRIVACY
Less sensitive data leavesMedical and testing reports are sensitive. Reading characters in-house means full page images don't need to go to a third-party model.
The hard parts.
01
Every lab is different
Medical, water and other test reports from many labs, each with its own table layout.
02
Wrong detections
Look-alike characters fool the detector. Custom correction algorithms catch and fix them.
03
Tables across pages
Columns renamed or reordered between pages still need to land in one table.
04
Heavy compute
Character-level vision and OCR is slow by default — until it's optimised.
Results
~3s
Extraction time per page
1 table
From multi-page reports, merged automatically
3+
Testing domains: medical, water and more
98%+
Character detection accuracy, after correction
99%
Cross-page column matching accuracy
What I built
- The whole backend and API
- Object detection pipelines for characters
- OpenCV image enhancement
- OCR and LLM model integration
- Algorithms that detect and correct wrong YOLO detections
- Cross-page column matching and single-table export
- Cython, memory, multi-threading and multi-processing optimisation
Technology
Client project — Docutize.ai is owned by its founder. Shared with permission; sample values on this page are illustrative, not client data.
“[A short quote from the Docutize.ai founder about working with you.]”
[Name], Founder — Docutize.ai