Medical software · regulatory engineering · EU market access
How to obtain CE marking for medical software
The software build and the regulatory build must reach release together
CE marking is not a logo added after development. It is the visible result of a system connecting the intended purpose, software architecture, clinical evidence, risk controls, quality processes and post-market responsibilities.
Open the release pathway ↓One product, two synchronized builds
A reliable application is not automatically a compliant medical device. The product and its regulatory evidence must describe the same intended purpose, the same risks, the same functionality and the same released version.
Build the function
Requirements, architecture, implementation, interfaces, verification, usability, cybersecurity, configuration and controlled release.
Build the argument
Qualification, classification, risks, GSPR, clinical or performance evidence, QMS, conformity assessment and lifecycle control.
01
First decide whether the software is a medical device #
Medical Device Software is software intended to be used alone or in combination for a purpose covered by the definition of a medical device or an in vitro diagnostic medical device.
It may qualify as MDSW when it supports diagnosis or treatment decisions, monitors physiological processes, calculates patient-specific treatment, analyses medical images, interprets diagnostic data or predicts clinically relevant outcomes.
The software does not need to control a physical device or act directly on the human body. A standalone application can be a medical device in its own right when its intended purpose is medical.
- Diagnostic or therapeutic decision support
- Patient-specific calculations or predictions
- Analysis of images, signals or physiological data
- Monitoring of physiological processes
- Interpretation of laboratory or other diagnostic data
Not every digital health product is MDSW. Software used only for scheduling, invoicing, communication, storage, archiving, lossless transfer or general wellness may fall outside the MDR and IVDR if it does not perform a medical function.
Do not begin by selecting a risk class. Begin by deciding whether the product is a medical device, an IVD, an accessory or a non-device product.
The current European approach is explained in the European Commission’s MDCG 2019-11 rev.1 guidance. MDRC also discusses the boundary in the article on software as a medical device or an accessory.
02
Define the intended purpose before building the pathway #
The intended purpose is the foundation of the conformity assessment. It determines what the software promises, which regulation applies, what evidence is needed and what can happen if the output is wrong.
A useful intended-purpose statement identifies the medical function, users, patient population, use environment, inputs, outputs and clinical context. “Software for healthcare professionals” does not define a regulated product.
- The medical function and clinical claim
- The intended patient population and user
- The use environment and workflow
- The input data and generated output
- The role of that output in a medical decision
The product boundary matters equally. A digital platform may combine a regulated clinical function with communication, storage or administrative modules. Those functions do not automatically share one regulatory status. The manufacturer must show which components belong to the medical device and which remain outside it.
A clear regulatory strategy prevents the marketing claims, technical architecture and conformity route from drifting apart during development.
03
Determine whether the MDR or IVDR applies #
Software generally falls under the MDR when its purpose concerns diagnosis, prevention, prediction, prognosis, monitoring, treatment or alleviation of disease without meeting the specific definition of an IVD.
Software may fall under the IVDR when it provides information by examining data derived from human specimens and that information serves an IVDR purpose, such as identifying a pathological condition, determining predisposition, predicting treatment response or monitoring therapeutic measures.
The data source is relevant but not decisive by itself. The intended purpose, the nature of the generated information and the way that information is used must be assessed together.
Information or functions serving a medical purpose outside the specific scope of in vitro examination.
Information generated from the examination of specimens derived from the human body for an IVDR purpose.
A laboratory information system that only stores and transfers results may not be an IVD. Software that interprets laboratory measurements and produces patient-specific diagnostic information may be one.
The legal definitions appear in the official texts of the Medical Device Regulation and the In Vitro Diagnostic Medical Device Regulation.
04
Classify the software according to its clinical impact #
Qualification asks whether the product is a medical device. Classification asks how much regulatory control it requires.
Medical software under the MDR is commonly classified using Rule 11 of Annex VIII. Software providing information used for diagnostic or therapeutic decisions is generally Class IIa. It moves to Class IIb or Class III when an incorrect decision may lead to more serious consequences.
Software monitoring physiological processes is generally Class IIa. It may become Class IIb when it monitors vital parameters whose variation could create immediate danger. Software outside those parts of Rule 11 may remain Class I.
For IVDR software, classification follows its intended purpose and the applicable IVDR rules. Independent software is classified in its own right. Software that drives or influences an IVD generally follows the class of that device.
The classification rationale should connect the intended purpose, applicable rule and foreseeable clinical consequences. Class I should never be selected merely because the product is “only software.”
05
Establish a quality system that controls the real development process #
Every manufacturer needs a quality management system appropriate to the product, risk class and activities it performs. The QMS must control more than software coding.
Regulatory strategy, intended purpose, requirements and development controls
Risk management, clinical evaluation, verification, validation and usability
Suppliers, outsourced processes, releases, changes and configuration
PMS, vigilance, cybersecurity, CAPA and continuing compliance
EN ISO 13485 is widely used to structure this system and may provide evidence of conformity within its scope. It does not replace the MDR or IVDR. The manufacturer must still demonstrate that every applicable regulatory obligation is addressed.
For software requiring Notified Body involvement, the QMS will normally be assessed as part of the conformity assessment. A polished set of procedures will not be enough if the development records show that the procedures were not followed.
06
Build lifecycle evidence, not an IEC 62304 claim #
IEC 62304 provides a recognised framework for software lifecycle processes. It addresses planning, requirements, architecture, detailed design, implementation, integration, testing, release, maintenance, configuration management and problem resolution.
It is important, but it is not the complete regulatory answer. IEC 62304 does not by itself demonstrate conformity with all General Safety and Performance Requirements. It does not replace risk management, usability engineering, clinical evidence, cybersecurity, labelling, quality management or post-market surveillance.
Software lifecycle processes and controlled maintenance
Medical-device risk management across the product lifecycle
Usability engineering and control of use-related risks
Security activities within the health-software lifecycle
Quality management processes supporting consistent conformity
Standards are generally voluntary and should be selected according to the product and its risks. Where a standard is harmonised and cited in the Official Journal, its use may provide a presumption of conformity only for the requirements it covers. The European Commission maintains current information on harmonised medical-device standards.
Further lifecycle considerations are discussed on the MDRC pages covering IEC 62304 compliance and cybersecurity for medical software.
07
Technical documentation should tell one coherent story
The technical file is not a warehouse of disconnected documents. It is a traceable argument showing how the software was conceived, developed, evaluated, released and placed under lifecycle control.
The intended purpose leads to requirements. Requirements lead to risks and controls. Controls lead to verification, clinical evidence and the final benefit-risk conclusion.
It should connect every applicable requirement to specific controlled evidence. A broad statement such as “compliant with IEC 62304” is not a substitute for this traceability.
08
Demonstrate clinical or performance value #
Software can function exactly as designed and still fail clinically. A technically accurate algorithm is not automatically clinically meaningful.
The manufacturer must demonstrate that the relationship between the software output and the targeted clinical condition is valid and that the software performs adequately in its intended population, environment and workflow.
Valid clinical association, technical performance and clinical performance support the clinical evaluation.
Scientific validity, analytical performance and clinical performance support the performance evaluation.
The evidence may include literature, analytical studies, retrospective datasets, prospective investigations, usability evidence, real-world data and post-market information. A clinical investigation or performance study is not automatically required for every product. The evidence needed follows from the claims, novelty, risk, inputs, outputs and intended population.
The European Commission’s current guidance collection includes MDCG 2020-1 on clinical and performance evaluation of MDSW. MDRC provides further guidance on clinical evaluation for software-centred medical technologies.
09
Put the regulatory roles, UDI and registration in place #
Every manufacturer must have at its disposal at least one Person Responsible for Regulatory Compliance who meets the Article 15 qualification requirements. Micro and small enterprises may use an external PRRC, but the person must remain permanently and continuously available.
A manufacturer established outside the European Union must designate a sole EU Authorised Representative for at least all products belonging to the same generic device group. The relationship is established through a written mandate accepted by the representative.
Regulatory oversight with the qualification and availability required by Article 15
Formal EU interface for manufacturers established outside the Union
Medical software is also subject to the UDI system. The manufacturer must establish the applicable Basic UDI-DI and UDI-DI structure, follow the selected issuing entity’s rules and determine how the identifier is presented for the software.
A new UDI-DI may be required when a modification changes the software’s original performance, safety, intended use or interpretation of data. The Basic UDI-DI is not the identifier for an individual software version.
The relationship between these identifiers is explained in the MDRC article on UDI-DI, Basic UDI-DI, GTIN and GMN.
Since 28 May 2026, the first four EUDAMED modules have been mandatory. Actor and UDI/device registration therefore belong in the active market-access plan. The current status is set out in the European Commission’s EUDAMED overview.
10
Complete the applicable conformity assessment #
The conformity route follows from the regulation and risk class. Class I software under the MDR and Class A software under the IVDR can generally be self-declared. These routes still require complete technical documentation, a compliant QMS, evidence, risk management, registration and post-market planning.
Self-declaration is not exemption. It means that the manufacturer performs the conformity assessment without routine Notified Body involvement.
For higher software classes, a Notified Body assesses the applicable QMS and technical documentation. The Notified Body does not grant the CE marking. It issues the relevant certificate after successful assessment. The manufacturer then draws up the EU Declaration of Conformity and affixes the CE marking. Where a Notified Body is involved, its four-digit identification number accompanies the mark.
Preparation should begin before the formal application. The manufacturer needs a Notified Body whose designation covers the relevant regulation and device or IVD codes. The assessment will examine whether the intended purpose, classification, risks, evidence, software lifecycle and QMS describe one consistent product.
The MDRC page on Notified Body readiness explains how to prepare for that review.
11
Treat CE marking as the beginning of the controlled lifecycle #
Medical software does not stop changing when it reaches the market. Operating systems evolve. Libraries are updated. Vulnerabilities appear. Data distributions shift. Users find unexpected workflows and clinical practice moves forward.
Complaints, performance, vulnerabilities, trends and real-world use
Clinical impact, risk, regulatory significance and need for action
Correction, update, communication, evidence and configuration
PMS reports, PSUR where applicable, CAPA and change records
Regression testing, security testing and effectiveness checks
Approved version, updated information and continuing conformity
A patch may be technically small but clinically significant. A model update may improve average performance while introducing a new risk for an underrepresented patient group. A new data source may change the regulatory boundary of the product.
Every change must be evaluated for its effect on intended purpose, classification, safety, performance, cybersecurity, clinical evidence, UDI and certification status.
Conclusion
CE marking is the release of a controlled medical technology
Obtaining CE marking for medical software is not a document-production exercise. It is the process of turning a medical idea into a controlled and evidence-supported product.
The intended purpose defines the promise. Classification reflects the possible consequences when that promise is not fulfilled. Risk management, lifecycle engineering and cybersecurity control how the software is built. Clinical or performance evaluation shows that its output matters. The quality system keeps those elements connected as the software changes.
When these parts are aligned, CE marking becomes more than permission to enter the European market. It becomes evidence that innovation has been translated into a medical technology that can be trusted, monitored and improved throughout its lifecycle.
What manufacturers most often underestimate
The hardest part is rarely one missing document. The real challenge is maintaining alignment across the entire product system.
Marketing claims exceed the intended purpose supported by evidence.
Classification is selected before the clinical consequences are understood.
Requirements cannot be traced to risks, controls and test results.
IEC 62304 is treated as proof of complete MDR or IVDR conformity.
Algorithm accuracy is demonstrated without showing clinical relevance.
Cybersecurity, UDI, EUDAMED and PMS are left until the end.
Software regulatory pathway
Need to align the product build with the regulatory build?
From the knowledge centre
