The download-and-upload cycle is where your Technical File loses its audit trail

I lost two days last quarter reconciling three versions of a CER because someone had downloaded the template, edited it offline, and uploaded it back without checking what had changed in the meantime. That afternoon is why I now push back hard on any workflow that takes a regulated document out of the QMS, even briefly.

The download-and-upload habit

Most of us learned regulatory writing in Word. You download the template from the eQMS, edit on your laptop, save locally, upload the finished file, and tick the box. It feels normal. It is also, to be fair, what nearly every Technical File I have ever reviewed started life as.

The problem is what happens between download and upload:

• Edits are not part of the QMS audit trail
• Concurrent edits overwrite each other silently
• The "current" version in the system is whatever was last uploaded, not what was actually sent to the notified body
• Linked records (the CER linked to the device, the literature search, the PMCF plan) go stale the moment you break the link by editing offline

For MDR work specifically, Annex II section 6 expects your technical documentation to be traceable, up to date, and readily available. Annex IX talks about the QMS being able to demonstrate control of documents and records. Per Article 10(9), the manufacturer is responsible for keeping documentation current. None of those phrases survive a workflow where the most recent edits live on someone's laptop between Friday afternoon and Monday morning.

What "direct in-app edit" actually changes

When the workflow moves from file-exchange to in-app editing — you open the record, change the text, the system saves it automatically — three things happen that the download pattern cannot:

1. Every save is in the audit trail, with attribution
2. The document stays linked to its related records throughout the edit
3. Status changes (draft, in review, approved) trigger the system, not the human remembering to upload

That third point is the one that quietly does the most work. In practice this means automatic escalation when a draft sits too long in review, automatic traceability across the linked records, and automatic change impact analysis when the edit actually changes something downstream. None of that fires if the edit happened in a local file that nobody remembered to re-attach.

A concrete example from last year

We had a change request to update the intended purpose statement on a Class IIb device. Simple text edit. In the old workflow, the request was raised in the QMS, the CER owner was emailed the Word file, edited it locally, and uploaded the new version. Meanwhile the labelling team's file was a separate download. The risk management report had its own copy. The PMCF plan referenced the intended purpose in three places.

By the time we noticed, two of those documents were out of sync with the CER. The notified body finding was not about the intended purpose itself — it was about evidence of control over the change. We spent the next audit cycle explaining why our QMS could not demonstrate that the change had been applied consistently across the technical documentation.

A connected workflow — one place where the change request, the CER, the labelling file, the RMR, and the PMCF plan actually link to each other — would have flagged the downstream documents before the change closed. It would have generated the impact map automatically. And the audit trail would have shown the edit happening inside the system, not on a laptop somewhere.

What I look for now

When I evaluate a QMS tool for RA work, I no longer ask whether it has document control. That is table stakes. I ask three things:

• Can I change a document without exporting it?
• When I change it, do the linked records update or at least flag?
• Is the audit trail real, or is it a folder of uploaded PDFs with timestamps?

If the answer to the first question is no, I keep looking. The download-and-upload cycle is not a minor convenience tax. Granted, it is what most teams know. But it is also where your audit trail frays first. So ist das halt.

---

So — what is the one document in your QMS that you trust least right now, the one where you are not sure the version in the system matches the version that actually went to the notified body?