AIHealth
On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.
Discover AIHealth →
Digital Health
Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.
Discover →
Cyber Security
Healthcare data protection, GDPR, vulnerability analysis for clinical infrastructure. CISO-as-a-service consulting.
Discover →The new regulatory framework
On 5 May 2017 the European Union published Regulation (EU) 2017/745 on medical devices — the Medical Device Regulation (MDR) — set to replace Directive 93/42/EEC (MDD) that had governed the sector since 1993. This is not an incremental update: the MDR entirely redesigns the regulatory framework for the design, manufacture, placing on the market and post-market surveillance of medical devices in the Union.
The shift from Directive to Regulation is significant: a directive requires transposition by each Member State, with inevitable national variations; a regulation is directly applicable across all Member States, eliminating the regulatory asymmetries that had characterised the previous regime.
From MDD to MDR: what changes
Directive 93/42/EEC had served for over twenty years, but presented increasingly evident gaps — particularly around medical software classification, required clinical evidence and device traceability. The MDR addresses multiple levels:
- Classification: classification rules increase from 18 to 22. The new Rule 11 introduces specific criteria for software, filling a regulatory gap that under MDD had left wide margins for interpretation
- Clinical evidence: the MDR requires more robust clinical data to support conformity, including structured clinical evaluations and, for high-risk devices, specific clinical investigations
- UDI (Unique Device Identification): every device must be uniquely identifiable through a harmonised coding system — a radical change from the lack of systematic traceability under MDD
- Post-market surveillance: manufacturers must implement active, continuous Post-Market Surveillance (PMS) systems, with stricter reporting obligations
- EUDAMED: the European database on medical devices becomes the central instrument for market transparency and traceability
- Person Responsible for Regulatory Compliance (PRRC): the MDR introduces the obligation to designate a qualified individual responsible for compliance
Software as a medical device
Under MDD, standalone software was a grey area. The interpretive guidance document MEDDEV 2.1/6 attempted to clarify when software qualified as a medical device, but classification often remained uncertain and subject to divergent interpretations across Member States.
The MDR addresses the issue directly. Rule 11 establishes that:
- Software intended to provide information used to take decisions for diagnostic or therapeutic purposes is classified at least as Class IIa
- If such decisions may cause serious deterioration of health or a surgical intervention: Class IIb
- If they may cause death or irreversible deterioration: Class III
- Software intended for monitoring physiological processes is classified as Class IIa (or IIb if monitoring vital parameters with immediate risk)
- All other software is classified as Class I
The practical consequence is that many software products classified as Class I under MDD are upclassified under MDR. This reclassification imposes stricter requirements: involvement of a Notified Body, a certified quality management system (ISO 13485), risk management according to ISO 14971, and more extensive technical documentation.
The Class I path for diagnostic support
In MDR classification, Class I remains the category with the least onerous regulatory requirements. For Class I devices, no Notified Body involvement is required (with exceptions: sterile devices, devices with a measuring function, reusable surgical instruments). The manufacturer proceeds by self-declaration of conformity, but must still ensure:
- Complete technical documentation in accordance with Annex II of the MDR
- Risk management system compliant with ISO 14971
- Documented clinical evaluation
- Post-market surveillance system
- Registration in EUDAMED and affixing of the CE marking
Software that provides ancillary information to the clinician — without replacing their judgement and without the output being directly used for diagnostic or therapeutic decisions — can qualify as a Class I device. The distinction is subtle but decisive: the software must support, not determine the clinical decision.
The SleepActa experience
noze managed the EU medical device Class I certification pathway for SleepActa, the startup born from noze’s research on machine learning applied to polysomnography and actigraphy.
The SleepActa system processes time series of physiological signals acquired during sleep — brain activity, breathing, eye movements, muscle activity, activity-rest cycle — and provides the clinician with support information for sleep analysis. The architecture is designed as a diagnostic support tool: the software produces analyses and classifications that the physician uses as an additional element in their decision-making process, without the system’s output replacing or constraining clinical judgement.
The certification pathway required:
- Compliance by design: software architecture, technical documentation and validation processes were set up from the design phase to meet regulatory requirements — not adapted after the fact
- Structured technical documentation: device description, risk analysis, clinical evaluation, instructions for use, design and manufacturing specifications in accordance with MDR Annex II
- Risk management: systematic risk analysis according to ISO 14971, with identification of mitigation measures for every identified risk scenario
- Software validation: software verification and validation processes compliant with IEC 62304, the standard for the medical software lifecycle
- Post-market surveillance: definition of the PMS plan, with procedures for collecting and evaluating post-market data
What this means for the sector
The MDR structurally raises the barrier to entry for the European medical device market. For companies developing medical software, the implications are concrete:
- Certification timelines lengthen — even for Class I, the required documentation is significantly more extensive than under MDD
- Regulatory expertise becomes a competitive factor, not an administrative cost
- Companies that have already gone through the certification process have a tangible advantage in designing new compliant devices
- Medical device cyber security becomes an explicit requirement: the MDR requires that information security risks be managed within the overall device risk management framework
noze’s experience with SleepActa — from architecture design to technical documentation, from risk management to validation — is a concrete example of how to approach the certification pathway by integrating machine learning, digital health and regulatory compliance expertise within a single team.
Regulatory references: Regulation (EU) 2017/745, Directive 93/42/EEC, ISO 14971, ISO 13485, IEC 62304, MEDDEV 2.1/6.