Change Is the Risk: Managing App, OS and Firmware Updates Across a Live Trial
A feature added in a routine update can cross a perimeter mid-study. Why change is a regulated event — and how to tell which changes are material.
REGULATORY OPERATIONSEvery app, OS, permission or model update that reaches a live trial is a regulated event, and its materiality must be assessed and recorded — either way.
“Just an update” is the assumption that no perimeter was crossed; where nobody checked, the next inspection will. Separate the change you release from the change the platform pushes, set written materiality criteria before the next release, bound foreseeable change in a PCCP-style plan, and monitor a device / OS range.
Five kinds of change cross perimeters — and each has its own control
| Kind of change | Why it is a regulated event | Example control |
|---|---|---|
| New app feature | Can move the software into medical-device territory mid-study | Materiality determination before release; re-assess classification |
| OS / firmware upgrade | Can alter the measurement and break comparability with prior data | Specified device / OS range; compatibility test; hold or re-validate |
| Permission / SDK change | Can change the data-flow and privacy position | Permission review; SBOM and data-flow check before deployment |
| Model retrain | Changes device behavior; engages change-control obligations | Predetermined change control plan (PCCP; QPP-16); bounded retraining |
| Config / MDM change | Can change the managed-platform and routing position | Change request through MDM governance; re-baseline the configuration |
Four positions that turn maintenance into a controlled, regulated event
Validation is a snapshot of a configuration. 21 CFR Part 11, EMA/INS/GCP/112288/2023, ICH E6(R3) and GAMP 5 require change to be assessed, re-validated where material and recorded.
FDA’s DHT guidance expects a record of every DHT update and continued fitness for purpose; an EU change with substantial impact on safety or data reliability is a substantial modification.
510(k) software-change logic and MDR Annex IX s.4.10 approval or s.2.4 notification bind only a marketed device; the Art. 120(3c)(b) test belongs to legacy devices.
OS and firmware upgrades arrive on the vendor’s timetable and cannot be held back on BYOD. The sponsor still detects, assesses and acts; a monitored device / OS range makes that possible.
Six actions that make change detectable, assessable and defensible
- 1Map controllable vs uncontrollable change — separate what you release from what the platform pushes, and assign detection to each.
- 2Set the materiality criteria — define and document what counts as a significant change before the next release, not after.
- 3Bound foreseeable change in a PCCP-style change plan (QPP-16) for the app and model change you can anticipate.
- 4Specify and monitor the device / OS range so an uncontrollable upgrade becomes a detectable, assessable event.
- 5Wire change triggers into the RIA (QPP-00) and keep the Trigger Register (QPP-08) live.
- 6Assess every release with the eight materiality questions and record the answer, with rationale, material or not.
FDA DHT guidance · 21 CFR Part 11 and Part 11 Q&A · 21 CFR 812.35 · EMA/INS/GCP/112288/2023 · ICH E6(R3) · GAMP 5 · EU MDR Art. 75, Annex IX, Art. 120(3c)(b) · FDA 510(k) software-change and PCCP guidance · EU AI Act
© qointa 2026 – Public – Uncontrolled when printed · Not legal advice; this summary does not classify any device.
sales@qointa.com · qointa.com
More from the library
Digital Health Technologies in Clinical Trials — A Regulatory Position-Paper Series
One device, several perimeters: a framework for assessing the regulatory impact of the technologies a trial relies on.
Read more →Who Is the Manufacturer? Economic-Operator Roles in DHT Supply Chains
How provisioning, importing, kitting and modifying a device assign manufacturer, importer and distributor duties — often by operation of law.
Read more →You Can Delegate the Work, Not the Accountability: Vendor Qualification and Oversight under ICH E6(R3)
The sponsor’s duty to qualify and oversee its DHT vendors — distinct from who holds the economic-operator role.
Read more →Talk to a specialist
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.
Book a 15-minute call