Going digital with your QMS just means paper that won't print

Six years ago, my company moved from a shared drive full of Word docs and an Excel CAPA log to an eQMS. We called it going digital. The auditors came, saw electronic signatures, controlled document folders, and a CAPA record per nonconformance. Everyone agreed we'd arrived.

It took us about a year to realize what we'd actually bought was paper that wouldn't print.

What "going digital" usually means

Look at most QMS rollouts and you'll see the same pattern:

• Templates become online forms.
• Files become PDFs in a folder hierarchy.
• Approvals become email notifications with a link to click "Approve."
• The CAPA log becomes a table with status columns.
• Training records become a checkbox next to a PDF.

The data lives in a database. The screens render in a browser. So it counts as digital, right?

Sort of. The records are stored electronically and 21 CFR Part 11 is technically satisfied if your vendor did the validation work. But here's the part nobody on the steering committee wanted to talk about: none of those forms are connected to each other. A CAPA is a record. A change is a record. A complaint is a record. They sit in the same database and have nothing to say to each other unless a human opens one, reads it, decides another record needs to be created, and creates it.

That's not a workflow. That's a form with a save button.

What a workflow engine actually does

A workflow engine treats your processes as processes. When event X happens, it triggers event Y, which has its own gates and reviewers. The state moves forward; it doesn't sit waiting for someone to remember the next step.

In a QMS, that looks like:

• A complaint auto-feeds a CAPA candidate when it crosses a threshold.
• A CAPA can't be closed until an effectiveness check is recorded — not just "marked done."
• A change control can't be approved until impacted documents, designs, and risks are linked.
• A risk file updates when the source hazard, severity, or probability changes — and the linked design inputs and verification protocols flag for review.
• A supplier nonconformance triggers a supplier evaluation record automatically.

ISO 13485:2016 §8.1 and §8.5 are explicit about this. The standard is built on the process approach. A process has inputs, outputs, sequence, and interaction. A form captures an output. The system around the form is what proves you ran the process.

Where we felt it

Two specific failures from our first year on the new tool:

1. We had a CAPA where the root cause analysis was approved and the corrective action was implemented, but the effectiveness check was never recorded. The record was closed because nobody stopped it from being closed. At audit, the inspector asked to see the effectiveness criteria before we looked at the closure date. We didn't have a satisfying answer.

2. We issued an engineering change to a device component without the change record linking to the design verification that had already been done on the previous revision. The DHF was complete. The change record was complete. They were just two complete records in different folders.

Both of these were process problems, not tool problems — except that the tool did nothing to make the right thing the easy thing. The state was free to move forward without the next gate.

What I'd do differently now

When I evaluate a QMS now, I don't look at the form library. I look at the state diagram.

• What happens when I save a CAPA in this system?
• Can it be closed without an effectiveness check?
• Does changing a design input flag the linked risk file?
• If I update a supplier's status, does that update flow into the supplier audit schedule, or is that a separate form a different person fills in?
• Does a complaint trend above threshold open a CAPA, or does someone have to remember?

If the answer to most of these is "you have to remember to do it manually," the tool is a database with forms. It is not a workflow system.

I'd also push vendors on what ISO 13485 §4.1.6 looks like in their product — validation of processes. A workflow engine is part of how you validate and control your own processes. If the tool doesn't help you validate your QMS processes, you're still doing that validation manually with SOPs nobody can find.

And for anyone in the EU/UK reading this, the same logic carries straight into MDR Annex I and the General Safety and Performance Requirements. A post-market feedback loop that exists as four disconnected forms isn't a post-market system. It's four forms that share a database.

The trap

The trap is that "going digital" is a checkbox for leadership. Once you've signed the contract, you've delivered the initiative. The fact that the CAPA queue still piles up, the change requests still need chasing, and the complaints still don't trigger risk updates — that's an "adoption problem," not a tool problem.

It's worth being honest about this. A workflow engine is harder to buy than a form library. It constrains how people work, which is uncomfortable. It exposes gaps in your processes, which is uncomfortable. It costs more than a database with pretty screens.

But paper that can't print is the worst of both worlds: you paid the digital tax without getting the digital benefit.

What's the one question you ask a QMS vendor that immediately separates "form library" from "workflow engine"? I'm collecting examples for the next time I'm in a procurement meeting.