Six months ago, evidence requests were my least favourite part of an audit. We had e-mails, shared drives, sticky notes on whiteboards and one person who "knew where the file was". Notified-body follow-ups, clinical-evidence asks and supplier-data pulls arrived in bursts, and every one felt like starting from zero. To be fair, the MDR's expectations (Annex II for Technical Documentation and manufacturers' obligations under Article 10) make those requests legitimate. Granted, that doesn't make them any less painful when you have three people covering RA/QA and a product line to keep shipping.
We introduced Foundation to track and store evidence requests. Six months later the difference is obvious: the churn is lower, our responses are faster, and audits feel less like forensic investigations. This is what changed — practically — and what I'd advise other small teams to look for.
What was actually broken
Listing the symptoms helps. Before Foundation:
- Requests landed in e-mail or chat with no canonical owner.
- Attachments were copied to local folders; versioning was inconsistent.
- Evidence lived apart from the Technical File — finding the "source of truth" required manual tracing.
- We lost time reassembling chain-of-custody: who prepared the data, when was it approved, has anything changed since the request.
- CAPA and change-control impacts were not automatically considered when a request uncovered a problem.
All of that is a problem not just for convenience but for compliance: Annex II requires traceable technical documentation, and the notified body wants to see how an item was justified, revised and approved.
What we changed (process, not just tooling)
Introducing a tool without changing how we operate would have gained us nothing. We paired Foundation with three process changes:
-
Standardised intake
- Every evidence request — whether from a notified body, vigilance team, or internal audit — enters Foundation as a request ticket.
- The ticket must include the requested artefact, applicable MDR/Standard reference (if given), and a deadline.
-
Owner assignment and SLA
- Each ticket gets a named owner (not a team) and an SLA: Acknowledge within 48 hours; substantive response within N calendar days depending on risk class.
- We linked tickets to existing documents in the Technical File, so the owner sees related artefacts immediately.
-
Controlled follow-up and evidence linkages
- Responses attach to the ticket and are versioned. If an action triggers a CAPA or a design change, that is created from the ticket and linked back.
- Every ticket records who prepared it, who reviewed it, and timestamps — audit trail done.
Those three changes cut the "where is the file?" time dramatically. But the tooling matters too.
How Foundation helps day-to-day (what actually works)
In practice, Foundation made these concrete differences:
- Single source for requests: no more hunting through inboxes. The ticket is the request and the evidence sits in the same place.
- Instant traceability: each response is linked to Technical File sections or specific risk assessments so a notified body reviewer can see provenance without a manual map.
- Time-stamped audit trail: every upload, comment and approval is recorded. During audits we answer "who did what and when" without a forensic dig.
- Connected workflow: when a ticket surfaces a non-conformance, generating a CAPA is one click, with the CAPA linked back to the ticket. That CAPA carries a traceable justification — helpful for PSURs and PMCF planning.
- Searchable evidence: an AI-assisted search (where available) surfaces prior responses and similar tickets so we avoid reinventing the wheel.
To be clear, none of this is magic. It's disciplined intake plus a system that preserves links and timestamps. That said, being able to find the "original 2019 supplier test report" in under two minutes is worth the subscription fee alone.
Practical tips for other small RA/QA teams
If you are considering the same route, focus on these points when evaluating tools and rolling out process:
- Insist on evidence-to-Technical File linking. Storing documents is not enough; they must be linkable to the specific Annex II sections they support.
- Keep ownership granular. One owner per request prevents the "nobody" problem.
- Integrate CAPA generation into the request workflow. Automated CAPAs or at least CAPA-driven risk assessment templates reduce missed follow-ups.
- Preserve reviewability. The review trail must show who approved a response and on what basis.
- Don’t skip training. A short, focused playbook (how to open a ticket, attach evidence, link to a file) is more effective than a 100-page SOP rewrite.
What I still worry about
To be honest, I still worry about interpretation variance across notified bodies. The tool helps you assemble, trace and present evidence, but it doesn't make the rules clearer. A request that asks for "equivalence documentation" can still precipitate a multi-week back-and-forth if the notified body and we disagree on what constitutes equivalent clinical data.
Also, tooling can create complacency. If the system makes it easy to produce an answer quickly, teams sometimes rush a reply instead of taking the time to check the underlying risk assessment. That's where process controls and reviewability are crucial.
The net result
Our cycle time for responding to evidence requests has shortened, our Technical File is more coherent, and audit prep requires far less frantic searching. The connected workflow — requests linking to documents and CAPAs — means fewer items falling through the cracks. For small teams with constrained bandwidth, that's the kind of operational relief that actually protects patients and reduces stress.
What I still want to learn from other teams is how they handle subjective requests (equivalence, sufficiency of clinical evidence) inside their tooling: do you keep draft rebuttals in the same ticket, or in a separate controlled document? How do you record the decision rationale so it's audit-ready?
