Dual-Regime SaMD/IVD Engineering: EU MDR + EU AI Act + FDA PCCP

AI-enabled medical software creates a regulatory engineering problem that is different from conventional software development. A single product may need to operate within the EU MDR, the EU AI Act, and the U.S. FDA framework for a Predetermined Change Control Plan (PCCP), while maintaining one controlled product baseline.

The three frameworks do not regulate the same thing. The MDR and IVDR establish requirements for medical devices and in vitro diagnostic devices, including software. The EU AI Act adds requirements addressing risks specific to AI systems where its provisions apply. FDA PCCP provides a mechanism for defining and controlling certain planned modifications to AI-enabled device software through a marketing submission. The European Commission and MDCG explicitly describe the MDR/IVDR and AI Act as complementary frameworks that can apply simultaneously.

For engineering teams, the practical consequence is significant: regulatory strategy has to be reflected in architecture, requirements, data pipelines, model lifecycle controls, verification, validation, release management, and post-market monitoring from the beginning.

1. Why Dual-Regime Engineering Changes the SaMD Development Model

A conventional software lifecycle often treats a release as the primary unit of change: requirements are defined, software is implemented, tested, released, and maintained.

For SaMD and AI-enabled medical products, that model is incomplete because the behavior of the product can depend on more than source code. A model version, training dataset, preprocessing pipeline, threshold, feature set, inference engine, or external dependency can alter clinical performance.

Consider an AI diagnostic application that analyzes laboratory results and generates a risk classification. A software release may contain unchanged application code while introducing a retrained model. From an engineering perspective, the change may look small. From a regulatory perspective, its effect depends on intended purpose, risk, performance, and the nature of the modification.

This means the controlled product baseline should encompass more than compiled software:

• Intended purpose and clinical claims
• System and software requirements
• Architecture and interfaces
• Source-code and build versions
• Model architecture and model version
• Training and validation datasets
• Data-preparation and preprocessing logic
• Verification and validation results
• Risk controls and residual-risk assessment
• Cybersecurity controls
• Clinical or performance evidence
• Released configuration

The objective is not three independent documentation systems. It is a single engineering evidence model capable of producing the evidence required by different regulatory pathways.

2. Establishing the Regulatory Baseline

Under the MDR/IVDR framework, software qualification and classification depend on its intended purpose, irrespective of whether the software is embedded, cloud-based, or deployed on another platform. MDCG 2019-11 Rev.1 provides updated guidance for qualification and classification of medical-device software under both MDR and IVDR.

For MDR software, classification can depend on the information produced and the decisions it supports. For example, MDR Rule 11 distinguishes software providing information used for diagnostic or therapeutic decisions according to the potential impact of those decisions.

IVD software requires its own classification analysis under the IVDR. The European Commission published revised MDCG classification guidance in September 2026, reinforcing that classification remains dependent on the applicable IVD rules rather than being inferred simply from the presence of AI.

The AI Act introduces another layer. Under Article 6(1), an AI system that is itself a product, or a safety component of a product, covered by specified Union harmonisation legislation can be high-risk where the applicable third-party conformity-assessment conditions are met. The MDCG/AIB FAQ specifically addresses this interaction for medical devices and IVDs.

Therefore, the regulatory baseline should explicitly map:

Intended purpose → device qualification → device classification → AI functionality → conformity-assessment route → applicable AI Act obligations → evidence requirements.

That mapping should be controlled configuration information, not an informal regulatory assessment.

3. Architecture, Traceability, and Design Controls

For regulated medical software, traceability needs to cross technical boundaries.

A useful engineering chain is:

Intended purpose → user needs → system requirements → software requirements → architecture → implementation → model/data configuration → verification → validation → clinical/performance evidence → released configuration.

Each release should be reconstructable from this chain.

For an AI-enabled device, model traceability should additionally capture:

• Model identifier and version
• Training-data version
• Dataset inclusion/exclusion criteria
• Preprocessing pipeline
• Training configuration
• Performance metrics
• Validation datasets
• Applicable subgroups
• Acceptance thresholds
• Known limitations
• Approval and release records

This becomes particularly important when medical device software development uses automated ML pipelines. Continuous integration may be technically capable of producing a new model every week, but regulatory controls should determine which models are eligible for release.

Configuration management therefore needs to treat the model and its supporting data as controlled product components rather than disposable development artifacts.

4. AI/ML Change Management and FDA PCCP

The FDA's PCCP framework addresses a specific problem: how an AI-enabled device can undergo defined modifications without requiring a new marketing submission for every modification covered by an accepted PCCP.

The FDA's August 2025 final guidance recommends that a PCCP describe the planned modifications, the methodology for developing, validating, and implementing those modifications, and an assessment of their impact. The approach applies to AI-enabled devices reviewed through 510(k), De Novo, and PMA pathways.

A PCCP is therefore not a generic "future updates" statement. It needs bounded change logic.

For example, an AI imaging device might define an allowable model-update protocol involving:

1. Retraining using a predefined class of eligible data
2. Preservation of the intended use and output type
3. Predefined performance metrics and thresholds
4. Testing across specified clinical subgroups
5. Regression testing against the previously released model
6. Cybersecurity and software integration testing
7. Impact assessment
8. Controlled deployment with monitoring and rollback criteria

The FDA's guiding principles describe PCCPs as focused and bounded, risk-based, evidence-based, transparent, and considered across the total product lifecycle.

The engineering implication is important: foreseeable change must be designed into the product architecture and verification strategy before the change occurs.

A PCCP does not eliminate ordinary change control. It defines a controlled regulatory pathway for specific changes that fall within its approved boundaries.

5. EU MDR + EU AI Act Engineering Intersection

The European model requires engineers to think about two complementary risk dimensions.

The MDR/IVDR framework addresses the safety and performance of the medical device. The AI Act introduces additional requirements relevant to AI-specific risks, including requirements concerning risk management, data and data governance, technical documentation, record keeping, transparency, human oversight, accuracy, robustness, and cybersecurity for applicable high-risk AI systems.

The joint MDCG 2025-6 FAQ explicitly states that MDR/IVDR requirements address risks associated with medical-device software, while the AI Act complements them with requirements addressing risks specific to AI systems.

This creates several engineering intersections.

Risk management: AI-specific hazards such as dataset limitations, performance degradation, distribution shifts, inappropriate outputs, and automation-related use errors should be assessed within the device's overall risk-management framework.

Data governance: Dataset provenance, relevance, representativeness, quality controls, labeling processes, and validation datasets should be controlled rather than treated as research-only artifacts.

Human oversight: Where human review is part of the intended workflow or risk control, the architecture should make that interaction explicit. The control should not exist only as a statement in the technical file.

Technical documentation: Evidence should connect the AI system's technical characteristics to the medical device's design, risk controls, verification, validation, and intended purpose.

Post-market surveillance: Production performance signals should feed into a controlled assessment process. A detected drift signal may trigger investigation, additional monitoring, retraining, corrective action, or a formal change assessment depending on its significance.

6. Building One Engineering Evidence Framework

The most sustainable approach is to maintain one engineering baseline and generate jurisdiction-specific evidence views from it.

A practical evidence architecture can contain a common core.

The point is not to create identical documents. It is to prevent contradictory evidence.

For example, if Model 4.2 is released, the system should be able to answer one question consistently:

What changed, why did it change, what requirements and risks were affected, what data and model configuration were used, what testing was performed, what clinical/performance evidence supports it, and under which regulatory mechanism was the release authorized?

That question should have one controlled answer, even when the evidence is presented differently to different regulators.

7. Practical Engineering Takeaways

For teams developing an AI medical device across EU and U.S. markets, several engineering principles follow:

• Establish intended purpose and classification before freezing architecture.
• Treat models, datasets, preprocessing pipelines, and software builds as controlled configuration items.
• Build bidirectional traceability from requirements through code, data, models, tests, and releases.
• Define foreseeable AI/ML changes early enough to determine whether they can be bounded within a PCCP.
• Separate routine software change control from changes with potential clinical or regulatory impact.
• Make performance thresholds, rollback mechanisms, and monitoring triggers executable engineering controls where practical.
• Connect post-market performance signals directly to risk management and change assessment.
• Maintain a common evidence baseline rather than creating disconnected EU and U.S. development processes.

Conclusion

The central engineering challenge is not choosing between the EU MDR, EU AI Act, or FDA PCCP. A regulated product may need to operate within all three frameworks, each addressing a different part of the product lifecycle.

The stronger approach is to design the software lifecycle, AI/ML lifecycle, quality system, and evidence architecture as one integrated system. Requirements, data, models, software, risks, tests, clinical evidence, releases, and post-market signals should remain connected throughout the product lifecycle.

That architecture gives regulatory teams a defensible evidence trail while giving engineering teams a controlled mechanism for evolving an AI-enabled device without losing sight of intended purpose, safety, performance, or configuration integrity.