The filled PDF is sitting in your inbox. Now what?

It starts after the form.

A patient fills in their admission form — digitally, on their own device, before they even arrive. They type their name, their date of birth, their medications, their emergency contact. They tick the checkboxes. They sign. They save and send it back.

Progress. No clipboard, no illegible handwriting, no scanning.

But then the file lands in someone’s inbox, and the same old problem reappears in a different shape.

Someone still has to open it. Read it. Type the information into the system. Field by field, section by section, one patient at a time.

The form got better. The workflow didn’t.

The step nobody automates

Most organisations that move to digital forms focus entirely on the collection side — how the form looks, how patients fill it in, how it gets returned. That part gets attention because it’s visible. Patients interact with it. It reflects on the organisation.

What happens after the form comes back is invisible. It’s a back-office problem. Someone handles it, and life goes on.

But that invisible step — reading a filled PDF and getting the data somewhere useful — is exactly where the time goes. And exactly where the errors happen.

A misread digit in a date of birth. A medication name copied with a typo. A checkbox status missed because the staff member was handling three other things at once.

None of these are disasters. They’re just the quiet cost of a process that was never finished.

What a filled AcroForm actually contains

A properly built fillable PDF — one that uses the AcroForm standard, not a Word document exported and printed — stores the data the patient entered as structured information inside the file itself.

It’s not an image of typed text. It’s not a scan. It’s actual field data: a name field that contains “John”, a date of birth field that contains “01/06/1971”, a checkbox that is either ticked or not.

That data can be read programmatically. Not approximated, not guessed by an AI looking at pixels — read directly from the file structure, with certainty.

This is the part most people don’t know about. The form already has the answer. You just need to ask it.

How the extraction works

The project I built to demonstrate this reads a filled patient admission form and extracts every field — 35 in total, across five sections — without any prior knowledge of how the form was built.

That last part matters, so I’ll explain it.

Because I also built the form in a previous project, I already knew every field name internally. I could have used those names directly. It would have been straightforward.

But that’s not the real problem. In practice, the form arrives from a clinic, a partner, a government system. You don’t have the source file. You don’t know what the developer called the fields. You only know what you can see: the layout, and roughly where each section lives on the page.

So the extraction was built to work that way — by position, not by name.

Each AcroForm field has a location on the page. A bounding rectangle that says exactly where it sits. The script defines a region for each section — Personal Information, Insurance, Medical History, Emergency Contact, Consent — and collects every field whose position falls inside that region.

Before any extraction runs, there’s a debug step: the script draws coloured rectangles over the form and saves a separate PDF so you can see exactly which areas will be used. You adjust until the boxes look right. Then you run the extraction.

The result: a formatted Excel file with all 35 fields, grouped by section, ready to be imported into any system.

Why not just use AI for this?

It’s a fair question. You could send the filled PDF to a vision model and ask it to extract the fields. It works, to a degree.

The trade-offs are real though. Every extraction costs tokens — at volume, that adds up. Rate limits become a problem under load. The same form can return slightly different field names or structures across different calls, which makes downstream processing fragile. And if the API is down or the model changes, your pipeline breaks.

AcroForm extraction is deterministic. Free to run. Works offline. The form already contains structured data — the only question is whether you read it directly or route it through an AI model that will interpret it for you, with all the uncertainty that implies.

(Scanned forms, handwritten forms, forms that were never built as proper AcroForms — those are a different problem. AI is often the right tool there. But that’s a different project.)

What this means in practice

The technical details aside, what this project demonstrates is a complete cycle.

A form is generated from code — consistent, branded, interactive. A patient fills it in on their own device. The filled file comes back. The data is extracted automatically, grouped by section, and written to a spreadsheet.

No printing. No scanning. No transcription. No manual data entry.

The information that was in the patient’s head is now in a spreadsheet, correctly, in about the time it takes to run a script.

That’s the outcome. The rest is implementation.

Who builds this

I’m a Python developer specialising in PDF automation — form generation, data extraction, document pipelines. I teach these techniques to developers on Udemy, and I build them professionally for organisations that need them.

If you have a form that people fill in and someone else re-enters by hand — or if you’re not sure whether your current process could be better — feel free to reach out.

📩 hugoferro.business(at)gmail.com

🌐 hasff.github.io/site