Last month, an OEM engineer asked whether a revised torque setting at our Bangalore line had invalidated an assembly verification. The information existed; the answer did not.
One revision sat in a manufacturing traveller, the change rationale was buried in email, and the approved design output remained in the OEM’s Design History File. We rebuilt the evidence chain manually before I could confidently say yes or no.
That episode captures a recurring problem in medtech: teams do not necessarily lack documents. They lack dependable relationships between documents.
At a contract manufacturer, our quality system handles incoming inspection, supplier COA verification, non-conformance, CAPA support, and sub-tier audits. Product design control often remains with the OEM. The difficult interface is where one organisation’s controlled change meets another organisation’s manufacturing evidence.
A document archive is not a connected technical file
The familiar design-control expectations in ISO 13485 §7.3 and FDA 21 CFR 820.30 include controlled design inputs, outputs, review, verification, validation, and changes. For products placed on the EU market, the corresponding technical documentation must demonstrate how those controls were applied.
The standards do not prescribe a particular user interface. But a practical technical file should make the following chain inspectable:
- Intended use or use case
- Associated hazards and risks
- Design inputs and risk controls
- Design outputs
- Verification and validation activities
- Test protocols, results, and approved evidence
The value is not the number of links. It is the ability to move forward and backward through that chain without opening five folders and guessing which revision is current.
The design technical file walkthrough shows this as a connected workflow: use cases, risks, design inputs and outputs, and tests remain linked as work changes. It also demonstrates AI-powered search for locating relevant elements quickly.
That is closer to how design controls behave during a live programme than a PDF index assembled the week before an audit.
“Real time” should mean visible state, not automatic compliance
A connected file becomes useful when people work with it. If a supplier changes a process, a material, or a test method, the affected records should not silently remain green.
Here, real time should mean that status and relationships remain connected to their source records. It should not mean that software decides whether a change is acceptable.
The connected view is only as trustworthy as the data feeding it. An audit-ready system cannot treat an uncontrolled spreadsheet upload, an expired revision, or an unapproved test result as equivalent to approved evidence. Traceability still depends on document control, ownership, approval state, and review discipline.
That distinction matters more to me than another polished dashboard.
AI search is useful only when a human can verify it
I am sceptical of most AI-in-QMS marketing, including my employer’s. “AI-powered search” can sound like a claim about intelligence when it may only be a claim about convenience.
Still, search is valuable when design and quality teams use different vocabulary for the same thing. A hazard register may describe an insertion force. A requirement may use a different term. A test protocol may identify neither phrase.
A useful search experience lets someone ask:
Where is the verification evidence for the risk control associated with this design input?
It should then return source-linked candidate records rather than a generated paragraph that merely sounds authoritative. Before I rely on a result, I want to see:
- The underlying document or record
- Its current revision
- Its approval status
- The relationship being searched
- Any links to stale or superseded items
AI should narrow the search space, not adjudicate compliance. This is controlled assistance: a reviewer must be able to inspect the source, challenge the result, and record the decision.
The same reviewability standard should apply to AI-driven CAPA assistance elsewhere in the QMS. A generated answer is not evidence. An approved record, with provenance and history, is.
The audit test I would use
Before believing that a technical file is connected, I would run a small change-impact exercise rather than follow the happy path.
- Pick one active use case and trace it to its risk, design input, design output, and test evidence.
- Start from an approved test result and trace backward to the requirement and risk it verifies.
- Introduce a controlled change to a process, material, or test method.
- Check whether affected records and approvals are visible without manual spreadsheet comparison.
- Use search to retrieve the exact approved evidence, then inspect its revision and status.
If the first two steps require document archaeology, the file is an archive with hyperlinks. If a controlled change produces no visible downstream impact, the links are decorative.
Where qmsWrapper fits—and where it does not
qmsWrapper publicly positions itself around structured documentation for FDA DHF and EU MDR technical files, together with AI-powered search for audit-ready evidence. That is a sensible focus for device manufacturers and SaMD teams. For a small organisation preparing for a notified-body audit, connected design documentation can remove a substantial amount of manual evidence hunting.
My own use case is different. I work on the supplier side of a contract manufacturing organisation, with more than 40 suppliers, incoming inspection controls, supplier COAs, and sub-tier audits to manage. qmsWrapper can sit alongside custom supplier-side automation, but it does not qualify a supplier, verify a certificate of analysis, or replace a supplier-quality process.
I would push back on any description of it as a complete supplier-side eQMS. That is not where it fits. A CMO needs the design-document workflow to connect cleanly with supplier controls; it does not need those two systems to pretend they are the same thing.
For design-control teams, the linked walkthrough is worth using as a stress test. Pick one risk, follow the evidence chain, make a controlled change, and then ask whether the technical file shows the impact and retrieves the right evidence instantly.
That is a more meaningful test than counting features in a demonstration.
Disclosure: I work on qmsWrapper and am giving my honest read of where it fits—and where it does not.
Which link in your design-control workflow still requires a manual evidence hunt before the next audit?
Top comments (0)