From banker's box to searchable brief: what OCR actually does to a 900-page file.

A 900-page medico-legal brief is not 900 pages of text. It is 900 pictures of pages, most of them made by a fax machine, a photocopier or a phone camera somewhere upstream, and the words the report will eventually cite do not exist as words until something reads the pixels. That reading step is optical character recognition, and it is the least glamorous layer in the whole pipeline, which is exactly why it deserves precision: every page reference in a draft report, every "D4, p 2", is a claim that a particular string of text sits on a particular physical page, and both halves of that claim are manufactured by the ingestion layer.

Get the layer right and verifying the report becomes a lookup. Get it wrong and the report inherits errors that no amount of clinical care downstream can see.

The brief arrives as pictures of pages, not as a document

Open a typical brief and count the ways a page can have been made. The GP notes were printed from a practice system and scanned by a clerk. The hospital discharge summary went through a fax server before anyone put it in a PDF. The insurer's sub-brief is a merged bundle with its own cover sheet and its own page numbers. The physiotherapy notes are photographs of a paper file, taken at an angle under a ceiling light.

The few native PDFs, usually typed specialist letters, are the exception. Scanned documents have been a problem in electronic health records for decades and are expected to remain one for the foreseeable future, so a medico-legal pipeline that only handles clean text is a pipeline built for a file that does not arrive.¹

The trap inside that mix is the "searchable" PDF. Many scanned documents carry a hidden text layer that some scanner or fax server produced years ago with whatever engine it had at the time, and because the search box appears to work, the layer gets trusted. It is often worse than a fresh pass on the image, and it is never marked as such.

So the first decision in ingestion is not which OCR engine to use but which pages to believe: a native text page can be read directly, a clean scan needs recognition, and a degraded scan or a handwritten page needs recognition plus an honest confidence signal. A pipeline that treats all three the same way collects the worst properties of each.

Fax resolution and phone photographs set the error floor before any software runs

The numbers explain why faxed pages read so badly. The Group 3 fax standard sets its standard resolution at 3.85 lines per millimetre vertically, which is about 98 lines per inch, with 1,728 picture elements across a 215 mm scan line, roughly 204 per inch, and it permits an alternative standard of 200 by 100 pels per inch outright.²

Recognition engines are tuned for a different world: the Tesseract project's own quality guidance says the engine works best on images of at least 300 dots per inch, that skewed pages degrade line segmentation until the image is rotated straight, and that uneven page backgrounds defeat the step that separates ink from paper.³ A radiology report faxed at standard resolution therefore arrives with a third of the vertical detail the engine expects, its 8-point footer already a smear, and a phone photograph of a handwritten note adds perspective skew, shadow gradients and motion blur on top.

Where the damage lands matters more than how much of it there is. Prose survives a few wrong characters because a reader recovers the word from context. Dates, doses and identifiers do not, because there is no context to recover from: a "2" read as a "7" moves an event five days, a dropped decimal turns 2.5 mg into 25 mg, and an "l", a "1" and an "I" are interchangeable at 98 lines per inch. Those are precisely the tokens a chronology is built from, so character-level errors that would be invisible in a paragraph become date-level errors in the timeline.

The failure then compounds downstream, and the research on OCR-derived text is consistent about this. Testing named entity recognition, parsing, retrieval and topic modelling on OCR output found a consistent impact from OCR errors on every task, with some tasks harmed beyond repair.⁴ A study of a national digital library, where more than 100 million documents are indexed through their OCR text, modelled how often a user's search terms fail to match the documents they are looking for purely because the recognised text differs from what was printed.⁵

Translate that into a brief: the record of the first consultation is in the file, but the word the pipeline searched for never existed in the text layer, so the chronology reports a silence that is not there. That is the most expensive class of error, because a report that says "no record of treatment in this period" is making an assertion about the file, and the assertion is wrong.

A page reference lives or dies in the page map underneath it

A citation like "D4, p 2" carries two coordinates: D4 identifies a document in the documents-reviewed table, and p 2 is a page within it. Both are harder than they look, because a brief has at least three paginations running at once:

• the PDF page index, which is what software sees;
• the printed page number on the original, which restarts at one inside every sub-brief;
• the folio or Bates stamp on the bundle, when the instructing party has applied one.

A reference is only useful if the reader, holding their own copy of the file, can turn to the page it names, so the ingestion layer has to record all three and know which one the report should speak in.

The physical scans then attack the map from below. A double-sided scan with blank backs shifts every subsequent page count by one unless the blanks are detected and kept in place. A two-up scan puts two physical pages in one image, which halves the count and puts the wrong text on the wrong page unless the image is split. A page scanned at 90 degrees is often recognised as nothing at all, so its content silently vanishes from the searchable text while the page itself still occupies a slot. Orientation detection, blank detection and page splitting are plumbing fixes, but each one is the difference between a reference that resolves and one that points a reviewer at the wrong page.

Duplicates are the subtler version of the same problem. The same consultation note routinely appears three times: in the GP's own records, quoted in the insurer's summary, and attached to a specialist's letter. The instinct is to remove them, and it is wrong, because removing a copy breaks every reference to it while the reader's copy of the file still contains all three.

The right move is to link them, so that the chronology cites one canonical copy, the link records where the other copies sit, and a reviewer can find the cited passage in whichever bundle they happen to have open. The expert witness code of conduct requires a report to set out the facts and assumptions each opinion rests on and the examinations, tests and other investigations relied on, and a reference that resolves to the wrong page fails that obligation while looking as though it has met it.⁶

Handwriting is a different problem, and the honest output is a visible one

Recognition of printed text is a mature technology. Recognition of a registrar's ward-round note is not the same task, and the input itself is the reason. When independent observers scored legibility in a sample of hospital case notes, 15 per cent of 117 records were unclear as a whole, with surgical departments the worst, and the authors concluded that much of the information in medical records is simply inaccessible to anyone who did not write it.⁷ An OCR pipeline cannot read what a colleague cannot read, and a pipeline that claims otherwise is guessing.

One clinical result shows what honest handwriting recognition looks like. A pipeline built to extract handwritten form fields from an electronic health record, running two commercial engines in parallel, reached a positive predictive value of 94.6 per cent at a sensitivity of 13.5 per cent.⁸

Read those two numbers together: the system was right almost every time it answered, and it achieved that by declining to answer most of the time. That trade-off is the correct one for a medico-legal file. A draft that reads "handwritten entry, partly legible, see D7 p 14" with the page image beside it tells the doctor exactly where a human eye is needed. A confident transcription of a handwritten dose that happens to be wrong is the failure nobody catches, because the sentence looks finished.

Verification happens against the image, and the rules already assume it

The regulatory framework has settled the question of where software belongs in this work. The NSW Supreme Court's practice note expressly permits generative AI for the generation of chronologies and indexes and for the summarising or review of documents, while requiring leave before it drafts the content of an expert report, and it directs that verification of references must not be carried out solely by an AI tool.⁹

The Personal Injury Commission's PIC13 runs the same lines: chronologies, indexes and schedules and the review of documents are permitted, verification that references exist and are accurate must not be done with a generative AI tool, and an expert who uses one must disclose which parts of the report it touched and the program and version used.¹⁰

Those rules carry two design requirements for the ingestion layer. First, because the OCR text is the thing being verified, verification cannot be done against the OCR text. Click-to-source has to open the page image with the cited region highlighted, so that the doctor or the practice manager checks the sentence against the page as it was scanned rather than against a transcription of it.

Second, the pipeline has to know its own provenance: which engine and version produced each page's text, what orientation correction and splitting were applied, and what the confidence was, because that record is what a disclosure annexure is made of. A pipeline that cannot say how it read a page cannot support a report that has to disclose how it was prepared.

Where the pages are processed is part of the file's privacy footprint

OCR is a processing step, and in most modern stacks it is an outsourced one: pages go to a cloud recognition service and text comes back. Under APP 8, sending personal information to an overseas recipient is a disclosure that requires reasonable steps to ensure the recipient handles it in line with the Australian Privacy Principles, and the entity that sent it remains accountable under section 16C for the recipient's breaches.

The narrower "use" category, which avoids that machinery, applies only where a binding contract limits the provider to specified purposes and the entity retains effective control, including the right to access, change, retrieve and delete the information.¹¹ A medico-legal brief is health information with a legal context layered on top, so a practice that pushes it through an offshore recognition endpoint has made a cross-border disclosure whether or not anyone in the practice thought of it that way.

The practical answer is to keep the recognition step inside the same boundary as the rest of the file. Trenthos IME processes and stores files in AWS ap-southeast-2 in Sydney, recognition included, and they are not sent offshore; the Privacy Policy is the source of truth on how that is done. Residency is not a checkbox that applies to storage alone, because the pages are most exposed at the moment they are being read.

Hold the ingestion layer to the report's standard

Hold the ingestion layer to the standard the report will be held to:

• the original page image is the record, and the text is an index over it, never a replacement;
• every page carries its provenance, from source file and physical page to the engine that read it and how confident it was, surfaced rather than hidden;
• duplicates are linked, not deleted;
• handwriting is flagged, not guessed;
• the whole layer runs onshore, because the file's privacy obligations follow the pixels.

That is the design brief Trenthos IME is built against: it ingests the brief as it arrived, scans and photographs included, reads every page in Australia, and attaches a page reference to every chronology entry and every factual line of the draft so that checking a claim means opening the cited page rather than re-reading the file.

The doctor's review then goes where it belongs, to the handwritten entries flagged as uncertain, the examination and the opinion, which are the parts the software is designed never to touch.

A banker's box does not become a brief when its pages become text. It becomes one when every line of that text knows exactly which page it came from.