Clinical trial software has moved out of the clinic and into the patient’s pocket. As decentralized trials become the default for many studies, the software powering them faces continuous updates—bug fixes, security patches, protocol adjustments, and feature enhancements. Understanding post-market change expectations for SaMD in decentralized trials is no longer optional for sponsors and developers. In 2026, the two most influential regulators—the US FDA and the European Union’s Medical Device Regulation (MDR)—have evolved divergent stances on what triggers a new pre-market review and how post-market vigilance should operate. This article provides a side-by-side reality check of these regimes, highlighting where they actually differ and what that means for your trial software.
The Shifting Landscape of Decentralized Trial Software
Decentralized trials rely on an ecosystem of software: ePRO apps, electronic consent platforms, remote monitoring tools, and algorithms for data cleaning or patient engagement. Unlike traditional medical devices, these tools are constantly iterated based on user feedback, cybersecurity advisories, and evolving protocol requirements. The regulators recognize this reality, but their frameworks for managing changes after market authorization remain stubbornly different.
For FDA, the centerpiece is the 2019 software pre-specification (SPS) and predetermined change control plan (PCCP) paradigm, now being reinforced by recent guidance. For EU MDR, the emphasis falls on post-market surveillance (PMS) and a strict interpretation of “significant changes” that could invalidate a Notified Body’s certificate. In practice, this creates a compliance minefield for global decentralized trials, where a single software version update might require vastly different actions in Boston versus Berlin.
FDA’s Risk-Based Approach to Post-Market Changes
FDA has long championed a risk-based, total product lifecycle approach. In 2026, this translates into a more explicit acceptance of iterative software development, provided the original marketing authorization includes a clear PCCP. Under this framework, an SaMD sponsor can define in advance the types of changes that are considered part of the device’s “predetermined” evolution—for example, adding a new questionnaire interface or adjusting a glucose measurement algorithm within predefined accuracy bounds.
21 CFR Part 820 vs. Software Pre-Specifications
The recent alignment of 21 CFR Part 820 with ISO 13485 has further clarified expectations. For decentralized trial software, changes that stay within the SPS and PCCP require only a documented risk assessment and update to the submission’s design history file. No fresh pre-market review is needed. However, any change that falls outside those pre-approved boundaries—say, using a new machine learning model for symptom prediction without prior specification—triggers a new 510(k) or De Novo request. The catch is that many trial software developers still do not write robust PCCPs, assuming that clinical research software is exempt. That is a dangerous assumption, especially when the software is patient-facing and influences treatment decisions.
Real-World Evidence and Continuous Monitoring
FDA’s post-market surveillance for decentralized trial software increasingly relies on real-world evidence. Under the updated guidance, sponsors must monitor user-reported issues, cybersecurity logs, and algorithm performance in real-world settings. But the agency does not mandate a rigid timeline for periodic safety reports; instead, it expects dynamic updates to its earlier documentation. This flexibility is a double-edged sword—it allows faster iteration but demands a mature quality system that can distinguish a trivial change from a significant one without asking for permission.
EU MDR’s Vigilance and Post-Market Surveillance Requirements
Across the Atlantic, EU MDR takes a more restrictive path. Under MDR Article 120 and Annex IX, any modification that could “significantly” affect safety or performance requires a new conformity assessment with the Notified Body. The European Medical Device Coordination Group (MDCG) has issued guidance on what constitutes a significant change, but for software, the thresholds remain murky. A change that increases the scope of patient monitoring—for example, adding a fall-detection feature to an ePRO app—might be viewed as significant because it introduces a new clinical function, even if the underlying algorithm is unchanged.
The Challenge of MDR Article 120 and Transition Periods
Many decentralized trial software products were initially certified under the Medical Devices Directive (MDD) and have relied on transitional arrangements. In 2026, the final transition period under MDR has ended, forcing those legacy products to undergo a full MDR assessment if they have not already done so. Post-market changes made during this transition—including simple UI updates—often triggered ambiguity about whether the change allowed an extension or invalidated the grandfathering. The European Commission has tried to clarify, but sponsors still report backlogs at Notified Bodies, making any change that requires a new certificate extremely disruptive for active trials.
When Changes Trigger New Notified Body Involvement
Under EU MDR, the trigger for re-involvement is not the existence of a PCCP (which is not a recognized mechanism in the same way as FDA’s), but the classification of the change. The MDCG 2020-3 guidance lists examples: changes to the device’s intended purpose, changes to the design or raw materials that could affect safety, and changes to the operating software that could influence interaction with patient data. For decentralized trial software, this means a simple adjustment to a data encryption protocol might be viewed as a change to “operating software” if it alters the software’s security architecture. That forces a dialogue with the Notified Body, and often a new audit, with real costs and delays.
Key Divergence: Change Classification Thresholds
The most practical difference between FDA and EU MDR lies in how they classify changes. FDA relies on the sponsor’s prior declaration and a self-assessment against the PCCP. EU MDR relies on a list of pre-defined criteria that are interpreted by the Notified Body. This creates asymmetries:
- Bug fixes: FDA generally permits bug fixes that do not affect performance or safety without prior review, as long as they are documented. EU MDR requires a formal evaluation even for bug fixes if they occur in software that manages patient treatment, because any malfunction could be seen as a safety issue.
- Security patches: Both regimes expect a rapid response to cybersecurity vulnerabilities. Under FDA, a patch can be deployed immediately if it falls within the PCCP’s cybersecurity section. Under EU MDR, a patch that changes the software’s integrity verification may necessitate a Notified Body notification, potentially delaying deployment.
- Algorithm updates: If a machine learning algorithm updates automatically, FDA supports this if the training process was validated and limited to pre-specified performance bounds. EU MDR views automatic adaptation as a fundamental change, often requiring a new conformity assessment unless the developer can prove the algorithm is a “locked” version.
This divergence is not academic. A sponsor running a global decentralized trial may need to delay a beneficial software update in Europe while rolling it out immediately in the US, creating protocol inconsistencies and potential patient safety risks.
Practical Strategies for 2026: Aligning FDA and EU MDR Expectations
Given these differences, what should an SaMD developer and trial sponsor do to avoid regulatory gridlock? The answer is not to choose one regime over the other, but to build a change management framework that satisfies both from the outset.
Building a Unified Change Management Framework
Start with the most stringent requirements from each regime. Defined a set of “pre-authorized change categories” that mimic FDA’s PCCP but also align with EU MDR’s need to document every change’s impact on safety and performance. Keep a living change log that records not just the change itself, but a clinical impact analysis. This allows you to quickly produce evidence for a Notified Body if they argue a modification is significant. Additionally, consider using voluntary EU MDR consultation for changes that are clearly borderline, rather than waiting for an inspection.
Using Digital Twins and Simulation for Impact Assessments
One innovative approach gaining traction in 2026 is the use of digital twins—virtual replicas of the SaMD’s performance—to simulate the impact of a proposed change. Instead of arguing subjectively about “significance,” sponsors can generate data showing that a change does not alter the device’s risk profile. FDA has been receptive to this type of evidence, and even the EU’s MDCG has begun to discuss how simulation models can support post-market documentation. For decentralized trial software, this is especially valuable because the data set is rich and continuous, making change impact assessments more objective than in traditional devices.
The reality check is clear: FDA and EU MDR may share the same ultimate goal—patient safety—but their post-market change expectations for SaMD in decentralized trials are far from aligned. FDA trusts the sponsor’s process with a predetermined plan; EU MDR trusts the Notified Body’s evaluation of each specific tweak. Until the regulators harmonize further, the burden falls on software teams to create a dual-regime change management strategy that is both agile and compliant. Start by mapping your most likely software changes against both thresholds, and leave yourself a clear audit trail. That is the only way to keep your decentralized trial moving without hitting a regulatory wall.
