Seven perimeters, assessed in one controlled loop.
Inventory → Assess → Register → Monitor → Re-assess. The same loop for every technology in the trial — wearable, biosensor, point-of-care device, algorithm or participant-owned phone — so the decision is reproducible and the evidence is already assembled when someone asks.
regulatory perimeters — the question a use of a device opens
16
assessment domains — the instrument that answers it
8
Device360 modules — how the work is packaged and bought
5
steps in one controlled loop, for the life of the study
What the protocol asks of a device can change its status
The most expensive mistake in digital health deployment is deciding a device is out of scope before
assessing it. A consumer smartwatch used for engagement is one thing. The same watch generating a
secondary endpoint is another. A weighing scale, a spirometer, a continuous glucose monitor, an
algorithm scoring an image, a participant's own phone running the eCOA app — each can sit on either
side of the line depending on what the protocol asks of it.
So we do not start from the device category. We start from what the protocol asks the device to do,
and work outwards through every perimeter that use opens.
The device never changes. The protocol does — and the perimeters follow.
The loop
Inventory. Every device, sensor, app and platform that touches the trial —
trial-issued and participant-owned, medical and consumer, hardware and software. Including the ones
nobody thinks of as devices.
Assess. Each one against all seven perimeters, with the reasoning recorded, not just
the conclusion. This is the Regulatory Impact Assessment.
Register. The result becomes a controlled artefact: what was decided, on what basis,
by whom, and what would change the answer.
Monitor. Firmware ships. Apps and operating systems update. Algorithms drift.
Suppliers change. Protocols get amended. Each is a trigger that may move a device across a boundary.
Re-assess. When a trigger fires, the loop runs again on that device — and only that
device. The register carries the history.
Inventory, assess, register, monitor, re-assess — and round again. The marker never stops, because the study does not.
Where to start if you have one device
You do not need to read this page top to bottom before you act. Most teams arrive with one
technology and one protocol amendment — a wearable, a home spirometer, a participant app, an
algorithm scoring an image — and need to know which perimeters that use opens.
Start with a Snapshot Regulatory Impact Assessment: one device, one protocol,
all seven perimeters at once, with the reasoning recorded rather than the conclusion asserted.
That artefact is what the rest of the method hangs from — the trigger register, the validation
scope, the economic-operator check, the training plan.
Return here when you need the full instrument: how the sixteen assessment domains map onto
the seven perimeters, how AI moves through the same loop, and what the controlled documents
look like when an inspector asks three years later.
Ten minutes before you commit anything
If you are not yet sure the Snapshot is the right first step, the free DHT readiness scorecard answers the prior question. Ten minutes, no sign-up, and it returns the same seven perimeters scored against your own programme — so you arrive at the conversation knowing which two or three are actually exposed rather than commissioning a review to find out.
We design against the hardest case, not the easiest
A participant's own phone is the reference case for this framework because nothing about it is
convenient. It is hardware you did not supply, cannot configure, cannot control and cannot recall,
running an operating system that updates itself and applications you never approved — and it may still
be a regulated part of your trial.
A method that survives that case survives a trial-issued wearable, a point-of-care analyser or a
cloud algorithm without modification. Only the specific triggers differ.
How we handle it in practice →
Why a single framework, and not seven checklists
Read separately, EU MDR, IVDR, the EU AI Act, FDA requirements and ICH GCP give five partial answers
that contradict each other at the edges. Read together, they resolve: obligations that look duplicative
collapse into one control, and obligations that look absent turn out to stack.
That reading is what qointa maintains, and it is why the assessment is reproducible rather than a
matter of whichever consultant you asked — and why it holds for a device class we have not met before.
Three numbers, three different things
Read quickly, our seven, our eight and our sixteen look like the same list counted three
ways. They are not, and the difference is the whole method.
7 perimeters — the question
The bodies of law a given use of a device can pull into scope. This is a
status question with a yes or no answer per perimeter, and it is what a regulator or
notified body will ask you to justify.
16 assessment domains — the instrument
The structured screen we run to answer it, trigger by trigger, each with a
regulatory anchor and a required control. Domains A–G map one-to-one onto the
perimeters; H–P cover what stacks on top once status exists.
8 Device360 modules — the delivery. How the work is packaged and bought: assessment, classification and filing, fit-for-purpose validation, logistics, interoperability, risk intelligence, training, and inspection readiness. Commercial units, not regulatory concepts. In our collateral the eight carry the Device360 names: DeviceAssess, DeviceReg, DeviceFit, DeviceOps, DeviceConnect, DeviceIQ, TrainReady and AuditPrep.
Put plainly: the perimeters are what you are exposed to, the domains are how we find out, and the modules are what you engage us to do about it. A single device can open three perimeters, be screened against all sixteen domains, and need two modules.
Seven perimeters — what a use of a device can open
Medical device. Does the intended use, as written in the protocol, meet the
definition of a medical device or IVD in each market of the trial?
GxP and computerised systems. Does the device or its software form part of a
regulated record — and therefore need validation and audit-trail controls, plus electronic signature controls where e-signatures are used?
Data protection. What personal and health data is processed, by whom, on what legal
basis, and across which borders?
Human factors and use-safety. Can a participant, carer or site user make an error
with this device that changes a result or creates a hazard?
Configuration and change. What can change after the device is deployed — firmware,
app version, operating system, algorithm, settings — and who controls it?
Economic-operator role. What does the sponsor, CRO or vendor legally become by
handling this device — manufacturer, importer, distributor, system or procedure-pack producer, or none of them — and who acts as authorised representative for a non-EU manufacturer?
Protocol design and endpoint. What does the data from this device actually
support — safety, a secondary endpoint, a primary endpoint, or nothing regulatory at all?
Perimeter seven is where most of the others are decided. Change what the protocol asks the device to
do, and the answer to the first six can change with it.
A use of a technology — not the technology itself — is what opens a perimeter. Change what the
protocol asks of it and the answer to any of the seven can change with it.
Sixteen assessment domains — the screen we run
Domains A to G map one-to-one onto the seven perimeters. Domains H to P cover what stacks on top of
them: obligations that do not create the regulatory status but attach to it once it exists.
A–G · the perimeters, made assessable
A · Medical device qualification and classification
B · GxP, 21 CFR Part 11, EU GMP Annex 11 and the EMA 2023 guideline for trials
C · Data protection and privacy
D · Human factors and usability
E · Device and system configuration
F · Operational and commercial role
G · Protocol and study design
H–P · what stacks on top
H · Cybersecurity
I · Combination products and specialist classes
J · Pharmacovigilance and post-market safety
K · Telecommunications and hardware
L · Cross-border personal-data transfer
M · Reimbursement, HTA and real-world evidence
N · Vulnerable populations and trial typology
O · Software supply chain and cloud
P · Artificial intelligence and machine learning
Each domain carries its own trigger set in the current RIA catalogue, and each trigger carries its
principal regulatory anchor and the control it requires. The catalogue is maintained as the frameworks
move; documents reference the catalogue rather than a fixed number, so a regulatory update never leaves
a stale count sitting in a client deliverable.
Where AI sits, and when it lands
An algorithm is not an eighth perimeter. It moves through the same seven — most sharply through
configuration and change, because a model that continues to learn is a device that continues to change, and
through protocol design, because an algorithm scoring an image is producing a result whether or not anyone
calls it a device.
The EU AI Act stacks on top of EU MDR; it does not replace it. Under Article 6(1), an AI
system is high-risk when two conditions are met together: it is a safety component of, or is itself, a
product covered by the harmonisation legislation in Annex I — which lists Regulation (EU) 2017/745 and
Regulation (EU) 2017/746 in Section A — and that product must undergo third-party conformity
assessment.
Both conditions matter, and the second is the one teams miss. A Class I device that
self-certifies does not meet the third-party conformity assessment condition, so it does not become
high-risk by that route. A device that needs a notified body does. In qointa's reading this is where most
vendor claims about AI Act status go wrong in both directions — some assume every AI feature is high-risk,
others assume none is.
The dates. 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 date set by the AI Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026. Nothing about that date is generous: an AI-enabled device in development now has to carry its AI Act technical documentation, risk management, data governance and post-market monitoring in the file it is already writing.
What the AI Omnibus changed
Regulation (EU) 2026/1744 — the Digital Omnibus on AI, in force since 27 July 2026 — replaced a moving start date with fixed ones: 2 December 2027 for stand-alone Annex III systems, and 2 August 2028 for high-risk AI in Annex I products, which include devices under EU MDR and IVDR. It also rewrote Article 4: providers and deployers must take measures to support the AI literacy of the people who operate AI systems on their behalf, without having to guarantee a level for any individual — in a trial, that lands as site and vendor training. And a new Article 4a lets providers of high-risk systems process special categories of personal data where strictly necessary to detect and correct bias, under stated conditions — a question the data-protection perimeter now has to answer for the model, not only for the device.
The FDA side
The United States has no separate AI statute to stack. The device question and the AI question are answered inside one FDA framework, and three documents set the expectation. The final guidance on Predetermined Change Control Plans for AI-enabled device software functions (December 2024) lets a manufacturer specify in the marketing submission which model modifications it will make and how it will verify them — the US counterpart of the change envelope described below. The draft guidance on AI-enabled device software functions: lifecycle management and marketing submission recommendations (January 2025) sets out what a submission should carry across the total product lifecycle. And for sponsors, the draft guidance on the use of AI to support regulatory decision-making for drug and biological products (January 2025) applies a risk-based credibility assessment to any AI model whose output supports a decision on safety, effectiveness or quality — including models used to produce or analyse trial data, whether or not they are devices. Drafts are not for implementation; we assess against them as the direction of travel and say so in the record.
Assessment domains P, E, G and O are where that reading is done: what can change in the model, what the
protocol asks the model to decide, and what the software supply chain underneath it can be shown to be.
Self-certified (MDR Class I; IVDR Class A non-sterile)
Notified body for limited aspects (MDR Class Is / Im / Ir; IVDR Class A sterile)
Notified body required (MDR Class IIa, IIb, III; IVDR Class B, C, D)
No AI function
Not in scope of Article 6(1)
Not in scope of Article 6(1)
Not in scope of Article 6(1)
AI function
Annex I product, but no third-party conformity assessment — not high-risk by this route
Arguable — depends on how Article 6(1) is read when the notified body reviews only sterility, metrology or reuse
High-risk. Obligations apply from 2 August 2028.
Article 6(1) requires an Annex I product and a third-party conformity assessment, together. Most vendor claims about AI Act status get one of the two wrong. Date per the AI Omnibus, Regulation (EU) 2026/1744.
What the controlled loop produces
Every run of the loop leaves controlled documents — versioned, attributable and indexed, so an inspector, a notified body or your own quality team can find the reasoning without asking us for it. They are yours whether qointa runs the loop, runs it alongside your team, or hands you the framework.
Snapshot Regulatory Impact Assessment
One device, one protocol, assessed against all seven perimeters. Records the decision, the reasoning behind it, the residual uncertainty, and what would change the answer. The artefact the rest of the pack hangs from.
Trigger Register
The live list of events that would reopen the assessment — firmware release, app or OS update, algorithm change, supplier change, protocol amendment, new country. Each trigger names the perimeter it touches and the person accountable for noticing it.
Fit-for-Purpose evidence pack
Verification and validation evidence tied to the specific endpoint the protocol asks the device to support — not generic device performance. Includes the measurement-context argument a regulator will ask for and a vendor datasheet does not answer.
Mid-Study Change Classification
When a trigger fires, a recorded determination: minor (documentation only), moderate (bridging evidence) or major (full revalidation, plus any amendment or submission it triggers). Classified, dated and signed — so the answer exists before the question is asked.
Change control plan handling
For devices and algorithms designed to change: the pre-specified change envelope, its verification protocol and its impact assessment, so anticipated modifications proceed under a plan rather than stopping the study.
Inspection Readiness Evidence Index
A single index mapping every obligation to the artefact that satisfies it and the place that artefact lives. Built continuously as a by-product of the loop, not assembled in the four weeks before an inspection.
How a trigger actually fires
The part clients ask about most is the mechanism: what makes the framework act rather than sit in a
binder. A trigger is not a reminder. It is a defined event, bound to a perimeter, with a named owner and a
required response.
Each trigger carries four things. The event that constitutes it — a firmware release, a
major OS version, a retrained model, a changed supplier, a protocol amendment, a new participating country.
The perimeter it touches, so the scope of re-assessment is bounded rather than total. The regulatory anchor
that makes it matter. And the control it forces — the specific action that has to happen before the trial
continues using that device.
Firing is a state change, not a notification. When an event matches a registered
trigger, the affected device's entry moves out of "current" and the assessment reopens for that device
alone. Nothing else in the estate is disturbed. The output is a Mid-Study Change Classification: minor (documentation only), moderate (bridging evidence) or major (full revalidation, plus any amendment or submission it triggers).
Either way the determination is written, dated and attributable — which is the difference between having an
answer and having to construct one.
The catalogue is the instrument. Triggers are maintained centrally across the sixteen
assessment domains and versioned as the frameworks move, so a change in guidance updates every study that
inherits from the catalogue rather than one study at a time. Deliverables reference the current catalogue
rather than a fixed trigger count, which is deliberate: a hard-coded number goes stale the first time a
regulator publishes something, and a stale number in a client document is a finding waiting to happen.
Ownership is explicit. Every trigger names who is accountable for noticing it. This is
where most frameworks fail in practice — not because the trigger was unknown, but because noticing it was
nobody's job. A vendor ships firmware on their release schedule, not yours; if no one owns that event, the
first time anyone assesses it is during an inspection.
A firmware release, OS update or protocol amendment reopens the assessment for the affected device only. Nothing else in the estate is disturbed.
The same loop, at the scale of a whole operation
Everything above describes one device moving through the loop. The identical method applied to an
entire clinical operation is what we call Digital Transformation of Clinical
Operations — inventory of every system and device that touches the trial, a Regulatory Impact
Assessment across the stacked perimeters, controlled change management for apps, firmware, operating
systems and algorithms, data integrity enforced on the edge devices themselves, and inspection-ready
evidence packs produced as a by-product rather than assembled under pressure.
It is not a different service. It is the same reproducible decision framework, run across the
estate instead of the device.
The questions the perimeters answer
Seven questions a sponsor has to be able to answer about every device in a protocol.
Is a wearable used in a clinical trial a medical device?
It depends on what the manufacturer intends and what your protocol asks of it. A consumer watch used for engagement may carry few obligations. Use it outside its intended purpose — to generate an endpoint, for example — and it can become an investigational device, the sponsor can become its manufacturer under MDR Article 16, or the use can trigger a clinical investigation. Data-integrity and data-protection rules can apply whatever its device status.
Does a device used in a trial need computer system validation?
If the device or its software forms part of a regulated record, yes — it needs validation and audit trail, plus electronic signature controls where e-signatures are used (21 CFR Part 11; for EU trials, the EMA 2023 guideline on computerised systems and electronic data in clinical trials).
Who is the manufacturer when a sponsor supplies a device to sites?
Handling a device can make a sponsor, CRO or vendor a manufacturer, importer, distributor, or system or procedure-pack producer under EU MDR, each with distinct legal obligations. A non-EU manufacturer also needs an EU authorised representative — a role taken on by written mandate, not by handling. Shipping a device across a border, relabelling it, or supplying it under your own name can create obligations you have not budgeted for.
What happens when firmware or an app updates mid-study?
It is a trigger. The affected device is re-assessed and the change is classified: minor (documentation only), moderate (bridging evidence) or major (full revalidation, plus any amendment or submission it triggers). The determination is written, dated and attributable.
Does the EU AI Act apply to an AI-enabled medical device?
Under Article 6(1) an AI system is high-risk when two conditions are met together: it is a safety component of, or is itself, a product covered by Annex I harmonisation legislation — which lists EU MDR 2017/745 and IVDR 2017/746 — and that product requires third-party conformity assessment. A self-certified Class I device does not meet the second condition. Under the AI Omnibus, Regulation (EU) 2026/1744, those obligations apply from 2 August 2028 — a fixed date, not a moving one.
What evidence does an inspector want for a digital health technology?
The decision, the reasoning behind it, who made it, when, and what would change it — plus validation evidence tied to the specific endpoint the device supports. An Inspection Readiness Evidence Index maps every obligation to the artefact that satisfies it.
Can a participant use their own phone in a regulated trial?
Yes, and it is the hardest case: hardware you did not supply, cannot configure and cannot recall, running an operating system that updates itself. It can still be a regulated part of the trial, which is why the assessment starts from the use rather than the hardware.
Two papers behind the method
A free account opens both. The framework on a page, just above, needs no account at all.
Turning the per-stakeholder assessment into a living, inspection-ready artefact in the technical file, the validation plan and the TMF — grounded in the risk-based quality management GCP already expects.
Bring one device and one protocol — a wearable, a sensor, an app, anything. We will tell you which regulatory perimeters it opens and what it takes to close them.
