Edit: Above was an attempt at digitization while this thread is about form automation. Understood. My point is that there was a lot of automation that could have been employed but wasn't. With that and good UI principles, the org could have made us more efficient. They chose not to because what they really wanted was a searchable database of patients treated so they could get more funding. EMT productivity was never a consideration.

I've seen a similar thing at a medical insurance company, not sure if this one was access (that they made IT take over) or winforms, but to make things even worse the list was un-ordered and semi-random. I only found out about it because the main user was bitching to me on a smoke break, but it had been this way for years and cost her at least a couple of hours a day. After the 5 minutes of work to slap an order by clause in there and the weeks worth work getting it though the bureaucracy (yay for that stupid process of billing internal clients) she was in tears.

Efficient and automated claims processing was the whole reason this company existed too.

I'm not saying the solution they used was a good one mind, but I bet that was part of the motivation to implement it that way

I once worked for an insurance brokerage whose in-house CRM had started years before as an effort to automate paper-based forms. The company's business model was based on having their sales advisers fill out insurance policy application forms on their customers' behalf and originally this had been done using pen-and paper, which was obviously time-consuming and laborious.

At some point, someone in the IT department had had the idea of scanning the application forms to image files and writing a simple PHP application to insert those images onto web pages with HTML <input> tags superimposed over the form fields, thus allowing advisers to fill in the forms using keyboard entry.

They quickly realised that once forms are filled in digitally, (a) you can store the form data into the database and retrieve it later for further editing, (b) some of the data can be filled in automatically from the customer's records and (c) when generating quotes across multiple insurance providers, the common parts of each insurer's form can be filled in from data previously entered elsewhere.

While the idea of superimposing HTML input fields over a scanned paper form isn't one I've encountered before or since, that company was turning over $3M per month by the time I joined, so there is clearly mileage in the idea.

Incidentally, it turns out that basing your entry forms around scanned paper forms completely kills dead any of the interminable bikeshedding that takes place around UX design with complicated, multi-section forms.

We built an internal tool that effectively converts any business form into a PNG @ 300DPI, and then defines a fixed element layout on top. This allows for pixel-perfect positioning of elements you'd like to fill on top of literally anything you can get into a PNG. Each definition is effectively just a JSON model specifying where everything lives, and then it is fed into some C# System.Drawing routines to fill the template image with expected data. The output is then converted back into whatever format is most ideal for downstream delivery (i.e. merge PNGs back into pages in a combined PDF).

The downside of this approach is that rasterization of PDFs or other upstream forms items effectively strips them of any textual data that you could mine out of the document. So, there are certain use cases where this would be a bad approach. For most businesses, I don't think this is usually a concern, especially if you already have the data you used to fill the document in a good structure somewhere for alternate delivery approaches.

You can also do this with PDF files, if you have Acrobat (or at least, it was possible - last time I played with it was several years ago - 2009-ish).

You've probably seen "editable" PDF files - where there are fields you can type stuff into - much like a paper document that you'd put in a typewriter to "fill out".

Well, it's actually possible (in Acrobat) to set up a "form submit" (virtually identical - IIRC, it was an actual HTTPS POST message) that you could point to a web endpoint. Add a button to the bottom of the page to submit the form, and it could also capture and handle errors (like if the service to receive the POST is offline, or has an error, etc).

I forget was Adobe called it - but it worked rather well. I worked for a web app company who was contracted by a doctor's group to redo their website, and part of that was automating the forms. They wanted some way that a patient could download and use their standard PDF forms, to both enter and upload the information, or print it and fill it out manually and return it, if they were more comfortable with that.

They didn't want an standard web form, or anything like you mentioned - because they might change the PDF for manual copies. Instead, we supplied them a template and taught them how to use it (and not to change particular parts - the parts handling submitting/errors and such) - so they could continue to use it. The backend was a PHP/MySQL system, everything was HTTPS, and IIRC we encrypted the data on the backend. I'm not certain that it was completely HIPAA compliant, but it was certainly as compliant as "form filled out with pen and filed in folder).

So yeah - there's clearly a market for this kind of thing...

Livecycle Designer?

That's funny. I work at a very large fab, and of all the places I've worked, this is the one that's most in need of the sort of in-office hot path optimizations you mention, and doubly worse is that it's the least susceptible to allowing someone to do anything about it.

(In fact, it's regressing. This month saw a fab-wide rollout of a document management system that has caused a ~10x increase in wall clock time for attaching files to emails or through forms on the intranet. Now consider what that means when the company exhibits a pathological form of the passing-MS-Office-documents-around-to-each-other mindset...)