OCR vs. OCV for Lot and Expiry Codes: The Part 11 Boundary Packaging Engineers Miss

Every regulated packaging line prints variable data — lot codes, date codes, expiration dates — and every one of them eventually has the same two conversations. The first is an engineering conversation: how do we automatically check that the right code printed, in the right place, legibly? The second is a compliance conversation: when a camera makes that check, what have we just created a regulated electronic record of?

Most teams handle the first conversation well and stumble into the second. Here's both, in order.

OCR reads. OCV verifies. They are not the same check.

Optical character recognition (OCR) reads whatever characters are present and returns them as text. Useful when you don't know in advance what the code should say.

Optical character verification (OCV) answers a narrower, sharper question: do the expected characters occupy the expected positions? It's the standard approach for lot codes, date codes, expiration dates, and other printed packaging information — the system holds a configured character set, receives the expected string at run time, and passes or fails the print against character and string thresholds.

On a packaging line, verification is usually what you actually want. You already know what the code should say — the question is whether the printer put it there. And keep the categories straight beyond these two: barcode decoding, barcode print-quality inspection, and comparing human-readable text against an encoded symbol are each separate capabilities. A system that does one does not automatically do the others.

It's an imaging application before it's a text application

The algorithm only judges what the camera hands it. Lighting, contrast, image noise, stroke width, character position, rotation, scale, and — the eternal offender — dot-matrix print variation all move matching scores. That makes threshold-setting an engineering decision with real consequences in both directions: set the match threshold too high and you reject valid print all shift; loosen it without application evidence and you've quietly reduced the system's ability to catch actual defects.

One architecture point matters more than any camera spec, and Laetus's product-identification guidance makes it plainly: the printed code gets compared against an approved reference from a controlled source. If the "expected value" is whatever an operator typed in at the start of the run, the system will happily verify a wrong code against itself — perfectly, every time. The reference has to come from the batch record or MES lookup, not from ungoverned re-entry.

Where Part 11 actually starts

Now the part that gets miscounted in both directions.

21 CFR Part 11 does not attach automatically to every image or camera on the line. FDA's own scope guidance says Part 11 applies when records required by predicate rules — the underlying CGMP regulations — are maintained electronically in place of paper, or when an electronic record maintained in addition to paper is actually relied upon to perform regulated activities. An electronic file that no predicate rule requires isn't a Part 11 record just because it's electronic.

But don't relax too early. FDA's data-integrity guidance for drug CGMP states that data generated to satisfy a CGMP requirement becomes a CGMP record — and it specifically lists automated visual-inspection records among the records whose access should be restricted. Once your OCV result is the thing that decides whether a carton ships, that result is a record: expected to be complete, consistent, and accurate; actions attributable to people; changes authorized and logged; retention secure.

So the working question for your line isn't "is this camera Part 11?" It's: which predicate-rule record does this inspection produce, is the electronic version the one we rely on, and is the workflow around it controlled?

Nothing is "Part 11 certified" — and anyone who says so is selling

Say it plainly, because vendor decks blur it: no camera, reader, or software is "Part 11 certified" or "Part 211 certified." FDA doesn't certify equipment. What a configured system and its controlled workflow can do is support your compliance — and that support gets demonstrated through validation, which FDA frames as validation of each CGMP workflow for intended use, with effort commensurate with risk. A camera vendor can hand you excellent tools: audit-trail functions that reconstruct who created, changed, or deleted what; secure user roles; backup that preserves exact records with their metadata. What they cannot hand you is your validation — that lives in your application: the approved reference source, user roles, change control, reject logic, a challenge set that proves the system catches bad print, audit-trail review, backup and restore, and record retention.

One more precision point: FDA guidance documents contain nonbinding recommendations — the "shoulds." The predicate-rule requirements underneath them are the enforceable "musts." An article, an auditor, or a vendor who swaps one for the other is being sloppy with exactly the distinction this whole topic turns on.

The takeaway

Pick verification over recognition when you know what the code should say. Treat the inspection as an imaging problem with a controlled reference, not a software setting. Then draw the compliance boundary deliberately: find the predicate-rule record, decide whether the electronic result is what you rely on, and validate the workflow — not the brochure. Teams that do it in that order pass audits with a binder that makes sense. Teams that start from "the camera is compliant" find out mid-audit that cameras never were.

Inspection hardware for this class of application lives in our Balluff vision and identification line — as inspection equipment, configured and validated in your workflow; no equipment carries a compliance certification.