Your protocol can change who carries device obligations — whatever the vendor calls the device.
End-to-end governance of every digital health technology in the trial: qualification and classification, fit-for-purpose validation, logistics, data interoperability, training and inspection-ready evidence.
delivery modules — bought one at a time, or all eight
7
regulatory perimeters — every device, every time
5
steps in the loop: inventory, assess, register, monitor, re-assess
2–3 weeks
to a Snapshot RIA on your hardest device
The expensive mistake is deciding scope before assessing it
Digital health technologies — wearables, biosensors, point-of-care analysers, software as a medical
device, algorithms and participant-owned phones running study applications — are now load-bearing in
decentralised and hybrid trials. Whether one is a medical device depends on the intended purpose its manufacturer gives it. The protocol still matters: it can change who carries device obligations — a sponsor that modifies a device or uses it for a new medical purpose can become its manufacturer (EU MDR Art. 16) — or turn the study into a clinical investigation of the device. That can happen even when it is not the investigational product, and even when the sponsor bought it retail.
A consumer smartwatch used for engagement is one thing. The same watch generating a secondary endpoint
is another. The device did not change; the protocol did.
Why the regulation attaches
Data used in a regulatory submission carries the qualification and validation duties of the system
that produced it.
Devices must be qualified, classified, validated and documented per the frameworks of every market the
trial runs in — which rarely agree at the edges.
Handling a device can make someone a manufacturer, importer, distributor, or system or procedure-pack producer, each with distinct legal obligations by jurisdiction — and a non-EU manufacturer needs an authorised representative, appointed by written mandate.
The failure modes are expensive and late: audit findings, trial holds, data invalidation, rejected
submissions.
Frameworks in scope typically include EU MDR 2017/745, IVDR 2017/746, the FDA framework for digital
health technologies used in clinical investigations, ICH E6(R3), ISO 14971, IEC 62304, ISO 13485,
21 CFR Part 11, EU GMP Annex 11 and the EMA guideline on computerised systems and electronic data in clinical trials — plus the national requirements of each participating country. Which of
these actually apply to a given device is the output of the assessment, not an assumption going in.
The cost of not assessing is not zero. It is deferred — to an audit, a hold, a data set or a submission.
Eight modules, one loop
Modules are bought one at a time; the loop is the same whichever you buy. AuditPrep is the exception — the evidence index is a by-product of every step, not a stage of its own.
Compliance assessment. Every device in the trial run through the seven perimeters,
with the reasoning recorded and the triggers that would reopen it registered.
Regulatory classification and filing. Multi-jurisdictional qualification and
classification, with the justification written to survive challenge, and submissions prepared where they
are required.
Fit-for-purpose validation. Verification and validation against the endpoint the
protocol asks for, in the measurement context it will actually be used in — the argument a vendor
datasheet does not make for you.
Training and certification management. Multilingual, role-specific, with completion records prepared for TMF filing and re-training triggered by device change.
Logistics and lifecycle management. Labelling, UDI, importer-of-record, customs, chain
of custody, calibration, reuse, decommissioning and recall — designed so the paperwork exists as the
device moves rather than afterwards.
Data interoperability. Traceable, time-synchronised, audit-ready data across eCOA,
EDC, eSource, CTMS and vendor clouds, with the transformation steps documented.
Risk intelligence. Activation, usage, adherence and compliance risk monitored across
the device portfolio, so a failing device class is visible before it is a data problem.
Inspection readiness and evidence management. Evidence index, binders, mock audits,
CAPA and traceability maintained continuously.
Alongside the eight modules: enabling services. Quality and regulatory assurance and computer systems validation,
applied where the device assessment shows they are needed.
The hardest case, handled
A participant's own phone is hardware you did not supply, cannot control, cannot configure and cannot
recall — running an operating system that updates itself, alongside applications you did not approve, on a
device that may still be a regulated part of your trial. We treat it as the reference case because a
framework that handles it handles everything simpler. The method page traces one
device class end to end.
What a DHT governance engagement delivers
A governance engagement is not a slide deck of risks. It produces controlled artefacts you
can file, defend and hand to a CRO or vendor with clear owners:
Device inventory — trial-issued and participant-owned, medical and
consumer, hardware and software, including the systems nobody listed in the protocol appendix.
Snapshot Regulatory Impact Assessment — one device, one protocol, seven
perimeters, with the reasoning recorded.
Trigger register — events that reopen the assessment, named per perimeter.
Validation and change scope — what must be validated, bridged or re-run when
a trigger fires.
Inspection index — where an auditor finds the decision, the evidence and
the person accountable.
Firmware, OS, retrain, supplier, amendment, new country: the events pass; the device notices.
AI in a trial device is a stacking problem
When a device in your trial contains a model — an algorithm scoring an image, deriving an endpoint,
flagging a safety signal — obligations stack rather than substitute. The device question is answered under
EU MDR or FDA rules. The AI question is answered under the EU AI Act on top, where Article 6(1) makes an
AI system high-risk if it is a safety component of, or is itself, a product under Annex I harmonisation
legislation (which lists EU MDR and IVDR) and that product requires third-party conformity
assessment. The AI Act has applied generally since 2 August 2026. For Annex I products — which include devices under EU MDR 2017/745 and IVDR 2017/746 — the high-risk obligations under Article 6(1) apply from 2 August 2028, the fixed date set by the AI Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026. Stand-alone Annex III systems come earlier, on 2 December 2027.
In the United States there is no separate AI statute: the device question and the AI question are answered inside one FDA framework. The final guidance on Predetermined Change Control Plans for AI-enabled device software functions (December 2024) is how a model is allowed to change without a new marketing submission. Two January 2025 draft guidances — on AI-enabled device software functions, and on the use of AI to support regulatory decision-making for drug and biological products — set the direction for lifecycle evidence and model credibility. Drafts are not for implementation; we track them as the direction of travel.
Then the trial question stacks on both: whether a model that changes mid-study invalidates data
collected before it changed. That is a protocol and endpoint question no regulation answers for you, and
it is the one that decides whether your dataset survives.
Device rules first, the AI Act on top, the protocol question last. A model that keeps learning is a device that keeps changing — and only the third layer decides whether your dataset survives.
When to start — and who should be in the room
The expensive version is retrofitting governance after sites are live. The cheaper version is
running the Snapshot before vendor selection locks you into an architecture you cannot validate.
Bring the clinical scientist who owns the endpoint, the data manager who owns the flow, and
the vendor manager who owns the contract — not because qointa replaces them, but because the
decision has to survive all three functions. One device and one protocol section is enough for
the first conversation.
Before that conversation: score it yourself
If you want a defensible view of where you stand before you book anything, run the free DHT readiness scorecard. Ten minutes, no sign-up, and it scores your programme across the same seven perimeters this service governs — medical device, GxP and computerised systems, data protection, human factors and use-safety, configuration and change, economic-operator role, and protocol design and endpoint. In our assessments, the gap is often in two of the seven, not all of them; knowing which two is what makes the first conversation short.
Three papers, one of them open
The position-paper series is free and needs no account. The two papers below open with a free account — no approval step, no sales call.
