Your App Just Became a Medical Device. Now What?

You added one feature. Maybe an alert for an irregular heartbeat, or a recommendation based on a patient's symptoms. Your code barely changed. But in the eyes of the EU Medical Device Regulation (MDR), your app may now qualify as a medical device.

The software may stay the same, but the way you build, release and support it does not. Here is what really changes, and how to get ready without slowing your team down.

In This Blog Post

• Six areas of evidence and control that come with medical device software
• How to keep Agile development and CI/CD compatible with MDR requirements
• What AI-driven software changes mean for release control
• When and how to prepare for a Notified Body
• Why CE marking is the start of ongoing regulatory responsibilities

One Medical Claim, Six Areas of Evidence

A wellness app needs to work. A medical device needs to demonstrate that it works safely for its intended purpose, and continue collecting evidence throughout its lifecycle. A medical claim can bring six connected areas of responsibility into scope.

1. Clinical Evaluation

Evidence must support the clinical benefit, safety and performance claimed for the software. A technically accurate output is not necessarily sufficient evidence that the product delivers its intended clinical benefit.

2. Risk Management

Teams need a systematic way to identify patient and user risks, assess their severity and likelihood, implement controls and evaluate residual risk. Risk management should follow the product as it evolves.

3. Verification and Validation

Testing needs to demonstrate both that software requirements have been met and that the product is suitable for its intended use. Traceability links requirements, design decisions, risks and test evidence.

4. Post-Market Surveillance and Vigilance

Manufacturers need a process for gathering and analysing information once the device is on the market, handling complaints, identifying trends and reporting qualifying serious incidents and field safety corrective actions.

5. Supplier Controls

Cloud providers, software libraries, outsourced developers and other critical partners can affect safety or performance. Their role and associated risks need to be assessed and controlled.

6. Change Control

Software changes require an assessment of their impact on safety, performance, regulatory documentation and the approved configuration before release. The level of testing and approval should reflect the risk.

Agile Is Fine. Uncontrolled Agile Is Not.

The most common worry we hear from software teams is: “Does this mean the end of sprints and weekly releases?”

No. The MDR does not ban Agile development, continuous integration or frequent releases. What it requires is control and evidence that the product remains safe and performs as intended.

In practice, that means:

• Requirements are traceable to design, tests and relevant risks.
• Changes are assessed for their impact on safety, performance and regulatory obligations before deployment.
• Testing and review are documented at a level appropriate to the change.
• Releases are formally authorised, rather than treated as complete when code is merged.
• Your quality management system, with ISO 13485 and relevant IEC 62304 software lifecycle practices, fits how the team actually works.

This does not mean creating a parallel paper process for every sprint. It means integrating design controls, risk management, traceability and release approvals into the development workflow itself.

What If Your Software Uses AI?

AI adds another layer to change control. A model update, retraining activity or change in input data can affect clinical performance even when the user interface looks identical.

A model may be updated after launch, but not on the assumption that continuous learning is automatically acceptable. Changes need to be planned, assessed, verified and validated as appropriate, documented and evaluated for their regulatory impact before deployment. Some changes may require further conformity assessment involvement.

The goal is not to stop iteration. It is to make every release defensible.

Are You Ready for a Notified Body?

For Class IIa medical device software and higher, a Notified Body is generally involved in conformity assessment. Before that assessment, eight foundations should be taking shape:

1. A clear and consistent intended purpose
2. A documented risk management process
3. An established software lifecycle process
4. Design and development controls
5. A functioning change management process
6. Complaint handling procedures
7. A post-market surveillance and vigilance process
8. Defined management responsibility within the quality system

These elements do not all need to be perfect before an initial conversation with a Notified Body. In fact, early contact can help teams plan around limited assessment capacity and understand the expected route to certification.

Start with a clear intended purpose, an initial risk and classification rationale, and a credible development plan. Confirm that the Notified Body is designated for the relevant device scope.

What If You Also Want to Enter the US Market?

Do not assume that evidence prepared for one market automatically satisfies the other. The FDA has several regulatory pathways, including 510(k), De Novo and premarket approval, depending on the device. The EU MDR follows its own qualification, classification and conformity assessment rules, including Rule 11 for software.

Some technical, clinical and quality evidence may be reusable, but the regulatory strategy and resulting evidence gaps need to be assessed for each market.

CE Marking Is the Start Line, Not the Finish

The biggest mistake we see is treating CE marking as the finish line. In Europe, it is the start of the next phase of responsibility.

Clinical evaluation, post-market surveillance, vigilance, risk management and software maintenance continue throughout the device lifecycle. Significant updates must pass through change control, with their potential effect on certification and regulatory obligations assessed.

Teams that plan for this from day one are better positioned to move quickly later. Their documentation grows with the product, releases are already controlled and inspection preparation becomes less disruptive.

Build MDR Compliance Into the Way Your Team Works

Becoming a medical device manufacturer does not mean abandoning the development practices that made your product successful. It means adapting them so that safety, performance and regulatory evidence are built into the same workflow.

QbD Group helps digital health companies define their MDR strategy and build an ISO 13485-aligned quality management system that works with their software development process, from early qualification and design controls to Notified Body preparation and post-market obligations.

Moving from wellness to medical device software? Get in touch with our experts to build a practical, compliant route to the European market.