What Is MDCG 2019 11 Really Used for?
If you sell, or plan to sell, medical device software in the EU, mdcg 2019 11 is usually one of the first documents to check before the technical file work starts. It helps answer two basic questions: whether the software is Medical Device Software, often called MDSW, and how it should be classified under MDR or IVDR. For more regulatory topics around EU compliance, you can also visit the Regulatory section.
The current official entry on the European Commission guidance page lists MDCG 2019-11 Rev.1 as the June 2025 version under new technologies. The document is a 36-page MDCG guidance, first issued in October 2019 and revised in June 2025. It is endorsed by the Medical Device Coordination Group, but it is guidance, not binding law. Only the Court of Justice of the European Union can give binding interpretations of EU law. (health.ec.europa.eu) (health.ec.europa.eu)
A Qualification Check for Software
The first use of the guidance is simple on paper: decide whether the product falls inside the medical device rules. In real projects, this is often where the debate starts. A hospital dashboard, a mobile app, a cloud algorithm, and a software module inside a scanner can look similar to users, but their intended purpose can send them into very different regulatory routes.
A Classification Map for MDR and IVDR
Once qualification is clear, the next step is risk class. MDCG 2019 11 connects the intended purpose with MDR Annex VIII and IVDR Annex VIII. For MDR software, Rule 11 is usually the rule that gets the most attention. For IVD software, the data source and clinical purpose can move the product into IVDR classes A, B, C, or D.
A Practical Source for Borderline Cases
The guidance is useful because it gives examples instead of only rule text. It discusses software that reads images, calculates risks, sends alarms, supports treatment choices, or only stores data. These examples help teams catch weak claims before they become a submission problem. A small wording change on a website, sales sheet, or IFU can change the whole classification debate.
How Does Rev.1 Change the Software Discussion?
Rev.1 did not rebuild the EU system. It matters because it uses wording that fits how software is now built and sold. In daily work, this means cloud delivery, app stores, connected modules, EHR workflows, algorithm-based functions, and medical functions mixed with admin tools in one platform.
Clearer Intended Purpose Wording
Rev.1 gives more weight to a clear intended purpose. The guidance says the intended purpose should cover all medical-purpose functions and leave no ambiguity about scope and use. This sounds basic, but many teams still write broad claims such as supports patient management before they know what the software actually calculates, flags, or recommends. That order creates problems later.
More Focus on Apps and Cloud Use
MDCG 2019 11 says apps are covered regardless of where they run, including mobile phones, cloud systems, and other platforms. It also says the older standalone software language is no longer the main lens. For a manufacturer, the main question is not where the code sits. The question is what the manufacturer says the software is for. (health.ec.europa.eu)
Fresh Attention to Modules and EHR Interoperability
Rev.1 adds more detail on modules and EHR links. If an MDSW module depends on a host platform, user interface, or data exchange layer, the boundary should be clear. The manufacturer should also show how medical and non-medical functions interact. This is where real project work gets messy: a scheduling function may not be medical by itself, but it may still affect safe use if the clinical module relies on it.
When Does Your Software Become MDSW?
The core test is the intended medical purpose. Software is not MDSW only because it is used in a clinic, runs on hospital hardware, or handles patient names. It becomes MDSW when it is intended to serve a medical purpose stated in MDR Article 2 or IVDR Article 2, such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or providing information from in vitro examination.
Medical Purpose Comes First
A general patient portal that stores appointments may stay outside MDSW. A module in the same portal that calculates stroke risk from patient data may cross the line. MDCG 2019 11 gives the working rule: intended purpose drives qualification and classification. So every claim in labels, IFU, website copy, demos, and sales material should be matched to the function that performs it.
Processing Medical Information Matters
The guidance draws a line between simple search and processing that contributes to a medical purpose. Simple retrieval of records usually does not qualify as MDSW. But software that analyses, interprets, calculates, modifies, or creates medical information may qualify when that output supports a medical purpose. The difference can be one hidden algorithm, not a flashy screen.
Location Does Not Decide Status
MDCG 2019 11 states that software may qualify as MDSW whether it runs in the cloud, on a computer, on a phone, or as part of a hardware medical device. The connection method also does not settle qualification. Wi-Fi, Bluetooth, cables, embedded code, or remote hosting do not keep a medical function outside MDR or IVDR. (health.ec.europa.eu) (health.ec.europa.eu)
How Should You Apply Rule 11?
Rule 11 is the part many software teams worry about, and there is a reason for that. It can move software above Class I quickly. The rule applies to software used to provide information for diagnostic or therapeutic decisions and to software intended to monitor physiological processes.
Class IIa as the Common Starting Point
Under Rule 11, software intended to provide information used for decisions with diagnosis or therapeutic purposes is Class IIa, unless the decision impact is more severe. The same rule places software intended to monitor physiological processes in Class IIa, unless vital parameters create immediate danger. The official text also says all other software is Class I, but that last bucket should not be treated as an easy exit. (health.ec.europa.eu)
Escalation to Class IIb or Class III
If wrong output could cause serious deterioration of health or lead to surgical intervention, Rule 11 can point to Class IIb. If the decision could cause death or irreversible deterioration, Class III can apply. A triage recommendation in oncology, an insulin dose calculator, or radiotherapy planning support will not be reviewed like a low-risk wellness chart.
Class I Is Narrower Than Many Teams Expect
Class I can still exist for software, and Rev.1 even added a Class I example. Even so, teams need to be careful. Many products that look harmless provide information that a clinician or patient uses for diagnosis, therapy, or monitoring. If that output changes what someone does next, Class I may not hold up in a notified body review. See also: Implants.
What Evidence Should Support Your Classification File?
A good classification rationale is not a one-page opinion. It should connect intended purpose, functions, data inputs, outputs, users, patient population, claims, risk, and clinical evidence. If a reviewer cannot follow that chain, the file will feel weak even when the final class is correct.
Intended Purpose Traceability
Start with a traceability table. Put each claim beside the software function, input data, output data, user action, and related regulatory rule. For example, if the app provides a 10-year cardiovascular risk score from user-entered data, state who uses the score, what decision it supports, and whether it points to MDR Rule 11 or IVDR rules.
Clinical and Performance Evaluation Records
MDCG 2020-1 describes clinical evaluation for medical device software as a planned, continuous process to generate, collect, analyse, and assess clinical data for safety, performance, and clinical benefit. For IVDR software, performance evaluation needs scientific validity, analytical performance, and clinical performance. A classification position is much easier to defend when the evidence file uses the same language as the intended purpose and risk class. (health.ec.europa.eu)
Module Boundary and Change Control Evidence
For modular software, document each regulated module, each non-medical module needed for operation, interfaces, data flows, and user messages. MDCG 2019 11 Rev.1 says manufacturers should define module boundaries and interdependencies, assess the whole architecture, and consider how input data, output presentation, usability features, and interfaces affect safety and performance. It is better to show this plainly in diagrams and change records than to leave it for the reviewer to work out. (health.ec.europa.eu)
What Common Mistakes Slow Down EU Market Access?
Most delays do not come from one big failure. They come from small mismatches that pile up. A marketing claim says therapy, while the technical file says wellness. The software architecture diagram leaves out the user interface. The clinical report studies one output, while the IFU promotes three. Reviewers notice these gaps.
Marketing Claims That Outrun the Evidence
Article 7 of the MDR and IVDR makes unsupported or misleading claims a serious issue. MDCG 2019 11 Rev.1 also warns that medical-purpose claims need an appropriate level of clinical evidence. In plain words: do not sell diagnosis if the file only supports display. Do not say treatment support if the software only logs symptoms.
Treating Non Medical Modules as Invisible
Non-medical modules can still matter. A login module, data import tool, report template, notification layer, or host interface can affect whether the right user sees the right output at the right time. Rev.1 is clear that features tied to safe and effective performance should be considered. This is not fancy work, but it often prevents hard questions later.
Ignoring Update Impact After Release
Software changes fast. A small update may change an algorithm, add a patient group, alter an alarm threshold, or connect to a new data source. MDCG 2019 11 says manufacturers should evaluate how changes affect qualification, classification, intended use, design, and the combination with other devices across the software lifecycle. A release note can become regulatory evidence sooner than the product team expects.
FAQ
Q1: Is MDCG 2019 11 Legally Binding? A: No. It is MDCG guidance, not binding EU law. Still, it is widely used because it shows how MDR and IVDR may be applied to software qualification and classification.
Q2: Does Cloud Software Escape MDR or IVDR Classification? A: No. MDCG 2019 11 says location does not decide qualification. Cloud, mobile, desktop, and embedded software can all qualify if the intended purpose is medical.
Q3: Is Every Hospital Software Product MDSW? A: No. Admin tools, billing, scheduling, simple record storage, and simple search may fall outside MDSW. The result changes when the software creates or modifies information for a medical purpose.
Q4: Does Rule 11 Always Mean Class IIa? A: No. Class IIa is a common starting point for diagnostic or therapeutic decision information, but Rule 11 can move software to Class IIb or Class III when a wrong decision may cause serious or irreversible harm.
Q5: What Should You Prepare Before a Notified Body Review? A: Prepare the intended purpose, claim traceability, Rule 11 or IVDR classification rationale, architecture diagrams, module boundaries, clinical or performance evaluation records, risk management, and change control history.