AVAILABLE NOW

Fit-for-Purpose Validation Package Review

You have a validation package. We tell you whether it would survive contact with an inspector, and what is missing.

Fee quoted on scope
scoped per engagement
3–4 weeks
typical turnaround
1
perimeter, assessed in depth

Fit for purpose is a question about your protocol

A device validated for one population, setting and measurement is not thereby validated for yours. The vendor's evidence answers the vendor's question.

This review tests the package against what your protocol actually asks the device to prove, and tells you plainly where the argument holds and where it does not.

vendor datasheet answers thisthe regulator asks about thisDeviceperforms to specMeasurementin this populationIn this settinghome, unsupervisedEndpointsupports the claim

Who this is for

Sponsors and CROs holding a validation package for a device that an endpoint depends on, and vendors who need to know whether their evidence will hold in someone else's protocol. It suits you if the package came from the vendor, looks thorough, and nobody has yet tested it against the specific measurement, population and setting your protocol requires.

What you receive

  • Gap analysis against ISO 14971, IEC 62366-1, the FDA QMSR (21 CFR Part 820), EU MDR Annex I and ICH E6(R3)
  • Endpoint-specific fitness opinion: does the evidence support this measurement, for this population, in this setting
  • Prioritised remediation list with effort estimates
  • Evidence index of what you already hold and where it sits

What you provide

  • The existing validation package
  • The protocol and endpoint definitions
  • Device technical documentation and vendor evidence
  • Any prior regulatory correspondence on the device

More details

What you provide

The existing validation package in whatever form it arrived — analytical validation, clinical validation, human factors, technical file extracts. The protocol and the endpoint definitions, which are what the package is tested against. Device technical documentation and any further vendor evidence you hold. Any prior regulatory correspondence on the device, including questions already raised by a notified body, an ethics committee or an agency. If the package is thin, send it anyway — establishing what is absent is half the output.

What is excluded
This review assesses a package that already exists, against one protocol. It does not include: generating the missing evidence; designing, running or analysing analytical or clinical validation studies; usability or human factors testing; determining the device's regulatory classification, which is the Snapshot RIA; notified body or agency engagement on your behalf; and it is not legal advice. It is a specialist opinion on the fitness of evidence for a stated purpose — it is not a certification, and it does not bind a regulator, notified body or inspector to the same conclusion.
What happens next
Every endpoint that depends on the device gets one of three verdicts: supported, supported subject to stated conditions, or not supported on the current evidence. Where the answer is "supported", you have the argument written down and referenced, which is the thing you actually needed. Where it is not, the remediation list is prioritised by what it blocks and estimated for effort, so you can decide between closing the gap, changing the endpoint, or changing the device — and you can make that decision before the protocol is locked rather than after.
What the output looks like

You receive a single controlled package:

1. Endpoint-specific fitness opinion: for each endpoint that depends on the device, whether the evidence supports this measurement, for this population, in this setting, with the reasoning recorded.

2. Gap analysis: the package assessed against ISO 14971, IEC 62366-1, the FDA QMSR (21 CFR Part 820), EU MDR Annex I and ICH E6(R3), cited to clause level, with each gap traced to the requirement it fails.

3. Prioritised remediation list: what has to be closed, in what order, with effort estimates, separated from what is merely desirable.

4. Evidence index: every document you already hold, indexed with where it sits and what it proves, so the next reviewer does not start from zero.

Where this sits among the eight

Every assessment leaves the same controlled artefacts — a recorded decision, the reasoning behind it, and the evidence index that makes it defensible. They differ in scope. This one is one perimeter, assessed in depth.

See all eight side by side →

Request this assessment

Tell us about the device and the protocol. We come back with a written scope, price and date — no obligation.

Name, manufacturer and model if you have it. List every item if there is more than one.
The single most important field. Screening, primary endpoint, secondary endpoint, safety monitoring, engagement only?
Which specific endpoints, and whether any safety decision is informed by its output.
e.g. EU, US, UK, Japan, Canada, China.
Who supplies it, whether you relabel, reconfigure or assemble kits, and whether you import into the EU.
Firmware or app updates expected, protocol amendments planned, algorithm retraining, supplier changes.
Vendor declarations, CE certificates, validation reports, prior assessments, DPIAs.
A date or a milestone.

We treat everything you send as confidential and handle it in line with our Privacy Policy. Do not include patient-identifiable data — we never need it.

Before you buy: the service overview

Free, no account needed. Every service line and the framework each is written against.

Two papers behind this assessment

Free to read with a qointa account. No sales call attached.

The Smartphone in Digital Endpoints Position papersFree

The Smartphone in Digital Endpoints

Indispensable conduit, immature instrument — the phone’s role in capturing, processing and submitting digital endpoint data

Read the summary →
Designed for the Hand That Holds It: Human Factors and Use-Safety in Trial DHTs Position papers

Designed for the Hand That Holds It: Human Factors and Use-Safety in Trial DHTs

Why usability and use-error are regulated concerns for participant-facing devices — and why the population, and the risk, set the bar.

Read the summary →

All papers in the library →