Refried PDF: a tale of woe in forms design

By Duff Johnson

My hospital sent me a medical records release form as a PDF file. They told me that I was to print it, fill it, sign it, scan it and return it to the medical records department, in that order. In 2018, to be receiving the form via email (i.e., electronically), yet being asked to print it? Frustrating.

So I thought I’d be clever. I’d fill it first, THEN print it. Or better yet, never print it, but sign it anyhow, and return it along with a note making the case for improving their workflow.

I opened the form. Immediately, I noticed there were no fillable fields, which was disappointing, as my handwriting is abysmal. So, ok… that not uncommon, especially on forms intended for printing.

I tried my software’s automatic forms-recognition feature with the idea of making some form fields that I could fill. No joy, it seems, because the form had been created using <cough> incompatible </cough> software.

Rather than having the decency to simply refry the PDF for me and proceed accordingly, my best-in-breed software simply complained that the source-file had been made with this other tool, and then stopped.

I was looking at a form created in a proper form-designer tool. However, the author, in his or her ignorance, had not actually bothered to allow the PDF form to be fillable. Since they assumed that it would be printed, they didn’t even care.

What’s more, the author’s (otherwise reasonable) choice of authoring tool was blocking me from using conventional forms-recognition software to add my own fields to a dead page. Because the PDF really wasn’t a PDF at all; it was an XFA-PDF.

I did not want to print this form and fill it by hand.

To avoid spilling ink, here’s what I had to do to fill my “form” – a PDF without usable form fields:

  1. Export the PDF to PostScript and distill back to PDF (a process known by the cognoscenti as “refrying”)
  2. Run the form-recognition software
  3. Adjust the resulting fields so the text would be legible when printed
  4. Fill the form (with the keyboard!)
  5. Fill address blocks manually, as the relevant fields were not connected to a database
    1. Of course, fill the address block twice on each page, as the form went to two different departments
  6. Print the form.
  7. Initial appropriately, then sign the form with a pen
  8. Get a 3rd party to witness the document, also with a pen
  9. Take a photo of the form with (clever) phone software that turns images of pages into image-only PDF.
  10. Save the resulting file to my desktop.
  11. Append the supporting documentation (that I’d already scanned into PDF) into the file.
  12. Encrypt (my idea, but I figured, desirable for US privacy law (HIPAA purposes), save and… send!

Starting from the moment that I realized, staring at the Document Properties dialog, that I was looking at an unfillable PDF form to the moment when I actually emailed the completed form: at least 15 minutes.

Maybe I’m just slow… but I’m pretty sure that only 0.1% of users would do it faster than me via some sort of clever shortcut that I didn’t think of.

Another 0.9% of users would do the same thing I did, but it would take them most of an hour.

The other 99% of users won’t solve the problem at all; they’ll just…. print and fill the form, then snail-mail it, fax it (what’s a “fax”?) or drive it over.

What is all that worth?

The use case

As I said at the outset… this form that I now hate… it’s distributed via email. The workflow guarantees a means of returning the filled form, it’s just that no-one even thought to use it, or sell this hospital a solution they could use for it. Instead, the cumulative time and money spent by an average patient to move a medical records request along is a non-trivial fraction of a day’s work. And for the hospital, it requires more infrastructure, staff and storage to cope with the… mere fact of a non-fillable form.

Some roll their eyes; “use a web form!”

Sure about that?

This use case requires:

  • a really easy process, available to the widest possible set of users.
  • a form that can operate in a session-independent manner, as users may need to fill it out in stages, after accessing different resources, or possibly, in an entirely offline (gasp!) condition.
    For example, I needed a 3rd party to witness the form. Should they have to create some account on some server just to sign their name?
  • the ability to capture submissions from people who may need to (for, say, regulatory reasons out of the owner’s control) use a pen, or in some way have their personal mark added as an image to the file.
  • PDF, because it requires a stable, archival-grade format with (in principle) no dependencies on specific applications, and no vendor lock-in.

The first PDF was an IRS 1040 tax form. It would be nice to think that in 2018 well-behaved PDF forms would just be… standard.

25 years of PDF… but in some ways, we are just getting started.

Postscript

Damn, I wish I’d known about Joel’s XFA-to-Acroforms software before I started down that road!

Duff Johnson is an independent consultant, Executive Director of the PDF Association and ISO Project co-Leader (and US TAG chair) for ISO 32000 and ISO 14289. Originally published at the blog of the PDF Association.