MDR readiness for European medical device software
Asteron coordinates the management systems, lifecycle processes and regulatory evidence needed to bring medical device software through the European MDR route. We connect intended purpose, qualification and classification with quality management, risk, software lifecycle, cybersecurity, clinical evidence, technical documentation and post-market obligations. The Medical Device Track is designed for healthtech teams preparing products for the Netherlands, Germany and the wider European market.
- Intended purpose and classification route defined
- QMS, risk and software lifecycle integrated
- Technical and clinical evidence coordinated
- Notified-body readiness prepared
Medical Device Track from €30,000
What the MDR means for medical device software
Regulation (EU) 2017/745, commonly called the Medical Device Regulation or MDR, governs medical devices placed on the European market. For software manufacturers, MDR readiness begins before documentation is written: the intended purpose determines whether the product qualifies as a medical device, while its functions and the potential consequences of its decisions influence classification and the conformity-assessment route.
Software is not regulated as a medical device simply because it handles health data or is used in healthcare. The decisive question is whether the manufacturer intends it to perform a medical purpose such as diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. Qualification and classification must therefore be based on the product’s actual claims, users, outputs and clinical context.
MDR is not a single certification or a documentation bundle. It creates lifecycle obligations for the legal manufacturer, including quality management, risk management, clinical evaluation, technical documentation, post-market surveillance and vigilance. Depending on the device class and conformity-assessment route, an independent notified body may also be required.
The regulatory route starts with intended purpose. Product claims, software functionality and clinical impact must tell one consistent story across the website, technical documentation and conformity assessment.
Does your software qualify as a medical device?
Medical device software may include:
- – software that provides information used for diagnostic or therapeutic decisions;
- – software that monitors physiological processes or identifies clinically relevant deterioration;
- – software that calculates, predicts or recommends patient-specific medical action;
- – software that drives or influences the use of another medical device.
Administrative systems, general-purpose communication tools, storage systems and wellness products may fall outside MDR when they do not have an intended medical purpose. The boundary cannot be determined from a product label alone. A defensible assessment considers the intended user, target population, input data, output, clinical workflow and effect of an incorrect result.
Classification is equally product-specific. Rule 11 is frequently relevant to medical device software, but it should not be reduced to “all software is Class IIa.” The class depends on how the information is used and on the possible harm caused by an incorrect decision or failure.
From intended purpose to market readiness
The Medical Device Track follows one connected pathway. Each step builds on the previous decisions rather than restarting the regulatory case.
1. Intended purpose, qualification and classification
Define the product’s medical purpose, users, patient population, clinical context and claims.
Document whether the software qualifies as a medical device, assess the applicable MDR classification rules and map the likely conformity-assessment route.
2. Manufacturer responsibilities and quality system
Establish the legal-manufacturer role, management responsibilities, regulatory ownership and required quality processes.
Identify relevant economic operators and the need for a Person Responsible for Regulatory Compliance.
3. Product lifecycle controls
Connect ISO 14971 risk management, IEC 62304 software lifecycle activities, cybersecurity, usability and change control.
Requirements, risks, verification evidence and released functionality must remain traceable as the product evolves.
4. Clinical and regulatory evidence
Coordinate the clinical-evaluation strategy, available literature, product data and post-market evidence.
Map the General Safety and Performance Requirements to the evidence demonstrating how each applicable requirement is met.
5. Technical documentation and conformity assessment
Build a controlled technical-documentation structure covering product description, intended purpose, design and development evidence, risk, verification and validation, clinical evaluation, labelling and post-market plans.
Prepare the organisation and evidence for the applicable conformity assessment.
6. Market access and lifecycle operation
Prepare CE-marking dependencies, registration, UDI and EUDAMED activities, post-market surveillance, vigilance and periodic reporting where applicable.
The management system must continue operating after market entry rather than ending when the initial assessment is complete.
What the Medical Device Track coordinates
The engagement joins the regulatory, quality, lifecycle and evidence work under one plan so decisions and documentation remain consistent across the product.
Regulatory and product foundation
- – Intended-purpose and claims baseline
- – Qualification and classification rationale
- – Regulatory pathway and responsibility map
- – Quality-management-system scope
- – General Safety and Performance Requirements mapping
- – Technical-documentation architecture
- – Clinical-evaluation coordination
- – Labelling and instructions-for-use interfaces
Lifecycle and market evidence
- – Risk-management integration
- – Software lifecycle and traceability
- – Cybersecurity and vulnerability-management interfaces
- – Usability-engineering interfaces where applicable
- – Verification and validation evidence planning
- – Post-market surveillance and PMCF interfaces
- – Vigilance and corrective-action workflows
- – UDI, registration and EUDAMED readiness
The final scope is agreed after the pathway assessment. Specialist clinical, usability, laboratory, legal or authorised-representative work is included only when expressly stated in the proposal.
How MDR connects to the supporting standards
These standards support different parts of the regulatory case. Holding one certificate does not, by itself, demonstrate full MDR conformity.
Netherlands, Germany and wider EU market access
MDR creates a common European regulatory foundation, but market-entry planning must also consider national authorities, healthcare procurement and local requirements.
For the Netherlands, healthtech manufacturers may need to account for IGJ oversight, Dutch-language and registration requirements, hospital assurance expectations and NEN 7510 where the organisation processes health information. NEN 7510 supports Dutch health-information security but does not replace MDR conformity.
For Germany, manufacturers may need to consider BfArM interactions and, where relevant, the separate DiGA route. DiGA listing and MDR conformity answer different questions: MDR concerns medical-device safety and performance, while DiGA adds national reimbursement and evidence requirements. Neither route automatically replaces the other.
For products sold across several European countries, establish one controlled MDR evidence base and manage national extensions separately. Avoid creating conflicting claims or duplicated documentation for each market.
Medical Device Track pricing
From €30,000. The Medical Device Track may combine ISO 13485, ISO 14971, IEC 62304, IEC 81001-5-1 and the applicable MDR pathway in one coordinated engagement. Scope depends on device classification, product maturity, number of products, existing evidence, QMS status, clinical-evidence needs and the conformity-assessment route.
Larger, multi-product or higher-complexity programmes are scoped individually.
- – 40% at signing
- – 40% when the agreed audit-ready or assessment-ready milestone is reached
- – 20% after the contracted certification or regulatory outcome, where that outcome forms part of the engagement
Prices exclude VAT where applicable.
Independent assessment and external costs
Asteron can prepare the management system, coordinate specialists, organise the evidence and support the organisation through assessment. Asteron cannot act as both implementation partner and independent conformity-assessment body.
Where notified-body involvement is required, the notified body is selected and contracted separately by the client. Its application, assessment, travel, testing and certification fees are quoted independently and paid directly to that organisation. The same principle applies to laboratories, authorised representatives and other external specialists unless the proposal expressly states otherwise.
Notified-body involvement depends on the device class and chosen conformity-assessment route. Asteron does not publish a generic external-fee estimate because costs vary materially by product, scope and body.
Responsibilities and boundaries
Asteron
- – Structures the regulatory pathway and delivery plan
- – Builds or updates the agreed management-system processes
- – Coordinates regulatory, quality, risk, software and security evidence
- – Prepares teams and documentation for independent assessment
- – Tracks agreed findings through resolution
Your organisation
- – Owns the product, intended purpose and regulatory decisions
- – Provides accurate product, technical and clinical information
- – Assigns responsible management and product owners
- – Implements product or engineering changes
- – Contracts independent bodies and specialists where required
- – Maintains the system and post-market obligations after launch
Frequently asked questions
What is the EU Medical Device Regulation?
Regulation (EU) 2017/745 sets the requirements for medical devices placed on the European market. It covers manufacturer responsibilities, clinical evidence, technical documentation, quality management, conformity assessment and post-market obligations.
Is every health or wellness application a medical device?
No. Qualification depends primarily on the manufacturer’s intended purpose and the function the software performs. Software that only stores, transfers or displays information without a medical purpose may fall outside MDR.
What is MDR Rule 11?
Rule 11 is a classification rule commonly applied to software that provides information for diagnostic or therapeutic decisions or monitors physiological processes. The resulting class depends on the possible consequences of an incorrect output or failure.
Can medical device software be Class I?
Yes, when the applicable classification rules support Class I. However, many software products fall into higher classes under Rule 11. Classification must be assessed from the specific intended purpose and clinical impact.
Does ISO 13485 certification prove MDR conformity?
No. ISO 13485 provides a recognised quality-management framework, but MDR conformity also requires product-specific regulatory, clinical, risk, technical and post-market evidence.
Does every MDR software product need a notified body?
No. Notified-body involvement depends on the device class and conformity-assessment route. Many software products classified above Class I require independent notified-body assessment.
What clinical evidence is needed?
The evidence must be proportionate to the product’s intended purpose, claims, risks and maturity. It may include literature, existing clinical data, performance evaluation, usability evidence and post-market information.
Is DiGA approval the same as MDR conformity?
No. MDR conformity is a European medical-device requirement. DiGA is a separate German pathway with additional reimbursement, evidence and service requirements.
How much does MDR preparation cost?
Asteron’s Medical Device Track starts from €30,000. Final scope depends on classification, QMS maturity, product complexity, existing evidence, clinical needs and the assessment route.
Are notified-body fees included?
No. Independent notified-body and other third-party fees are quoted by those organisations and paid directly by the client unless a proposal explicitly states otherwise.
Official references
- – Regulation (EU) 2017/745 on medical devices
- – European Commission Medical Devices portal
- – MDCG 2019-11 rev.1 on software qualification and classification
- – MDCG 2020-1 on clinical evaluation of medical device software
- – MDCG 2019-16 rev.1 on medical-device cybersecurity
- – European Commission EUDAMED information
Last reviewed: July 2026
Asteron is not endorsed by or partnered with the European Commission, any competent authority or notified body.
Related services and frameworks
Establish a defensible MDR pathway before documentation and product claims drift apart
Asteron will assess your intended purpose, classification assumptions, existing evidence and target markets, then define the practical route to MDR readiness.