AVAILABLE NOW

Mid-Study Change & Trigger Assessment

A firmware release, OS update, algorithm retrain or supplier change has landed. Documentation only, bridging evidence, or full revalidation?

Request this assessment See the method

Fee quoted on scope

scoped per engagement

5–10 working days

typical turnaround

Affected

perimeters assessed; the others recorded as unaffected

The decision nobody wants to make under pressure

Change is the normal operating condition of a digital trial. Firmware ships. Operating systems update themselves. Models get retrained. Suppliers get acquired.

Each event needs a classification — documentation only, bridging evidence, or full revalidation — and that call is far more defensible when it follows a rule written in advance than when it is made by whoever is available on the day.

Who this is for

Quality, regulatory and clinical operations teams with a change already in the field, or one landing within weeks, and a study running. It suits you if the question on the table is "does this need revalidation?" and the honest answer inside the organisation is that nobody is sure — or that the answer differs depending on who you ask.

What you receive

Change classification — minor (documentation only), moderate (bridging evidence) or major (full revalidation) — with the rationale
Impact assessment across affected perimeters
Required actions with evidence expectations for each
Updated decision register entry preserving the prior version
Protocol amendment impact note where relevant

What you provide

What changed, and the vendor release note if there is one
When it reached participants or sites
The affected device and study
The prior assessment or register entry, if one exists

More details

What you provide

What changed, and the vendor's release note if one exists. When it reached participants or sites — the date matters, because it sets the boundary between data collected under the previous configuration and data collected under this one. The affected device and study, and the prior assessment or decision register entry if one exists. If no prior assessment exists, say so; we establish the baseline as part of the work rather than assuming one.

What is excluded

This covers one change event on one device. It does not include: the initial regulatory classification of a device never previously assessed — that is the Snapshot RIA; execution of the revalidation, bridging study or documentation the classification calls for; drafting the protocol amendment itself, though we tell you what it must address; deviation, CAPA or data-integrity remediation for data already collected; and it is not legal advice. It classifies a change and records the basis for that classification — it does not bind a regulator, notified body or inspector to the same conclusion.

What happens next

The classification determines the work. Documentation only, and the engagement ends with the register updated and the file closed — we say so plainly rather than manufacturing a follow-on. Bridging evidence, and you receive the specific evidence expectations against each affected perimeter, so the scope of the bridge is bounded before anyone starts. Full revalidation, and you receive the impact across every affected perimeter and the sequence in which the work has to happen. Where changes of this kind are arriving more than once or twice a year, a governance arrangement is cheaper than assessing each one cold.

What the output looks like

You receive a single controlled package:

1. Change classification record: minor (documentation only), moderate (bridging evidence) or major (full revalidation), with the rationale, the criteria applied and the regulatory basis cited to article or clause level.

2. Impact assessment: perimeter by perimeter, which are affected, which are not, and why the unaffected ones are unaffected. The negatives are recorded, because an inspector will ask.

3. Required actions with evidence expectations: what has to be produced, to what standard, before the change is defensible.

4. Updated decision register entry: the new position, with the prior version preserved intact so the change in reasoning is visible rather than overwritten.

5. Protocol amendment impact note: where the change touches the protocol, what the amendment has to say and which sections it lands in.

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 change, classified.

Usually preceded by: Snapshot Regulatory Impact Assessment — one device, one protocol, all seven perimeters.
Or, across the estate: Full Multi-Perimeter Assessment — several devices or several jurisdictions, where the answers diverge.
If the change touches the endpoint: Fit-for-Purpose Validation Package Review — one perimeter in depth: does the evidence support this endpoint.
Triggered under: Portfolio Governance — the register kept current across the estate, quarter after quarter, by a named specialist.

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.

Your name *

Work email *

Organisation *

You are a…

Device or technology *

Name, manufacturer and model if you have it. List every item if there is more than one.

Technology class *

What does the protocol ask it to do? *

The single most important field. Screening, primary endpoint, secondary endpoint, safety monitoring, engagement only?

Endpoints or safety decisions that depend on it

Which specific endpoints, and whether any safety decision is informed by its output.

Jurisdictions *

e.g. EU, US, UK, Japan, Canada, China.

Supplier and economic-operator situation

Who supplies it, whether you relabel, reconfigure or assemble kits, and whether you import into the EU.

Known change triggers

Firmware or app updates expected, protocol amendments planned, algorithm retraining, supplier changes.

Documentation you already hold

Vendor declarations, CE certificates, validation reports, prior assessments, DPIAs.

When do you need this?

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.

Brochure

qointa service overview

Download brochure →

Two papers behind this assessment

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

Position papersFree

The Update You Ship Is a Trial Event

A companion reading from the OS / firmware vendor seat — why your release is the sponsor’s change event, and what only you can tell them about it

Read the summary →

Position papers

When the Device Thinks: AI/ML in Trial DHTs and the Stacking of Obligations

How an on-device model adds an AI overlay on top of the device rules — and why the 2028 application date is a trap, not a reprieve.

Read the summary →

All papers in the library →