What determines the EU risk class of cardiovascular software?

A company preparing a cardiovascular software product for Europe needs to make several commitments before it can sell the product: what the first release will do, which clinical claims it will support, how the evidence will be generated, and how much time and funding conformity assessment will require. A provisional risk class can quickly become an assumption in all four plans.

The difficulty arises when the product team has agreed on the technology but has not agreed on its clinical role. Detecting an abnormality, helping a physician interpret it, and supporting a decision that treatment can safely wait are different propositions. An algorithm may look similar across these uses while the consequences of relying on its output change substantially.

EU classification connects the product’s intended clinical role to those consequences. Understanding that connection helps a company decide what it is actually preparing to bring to market.

First establish what the software does medically

A cardiovascular setting does not make every software function a medical device. The MDR definition includes software intended for specified medical purposes. MDCG 2019-11 rev.1 distinguishes medical device software from functions limited to activities such as storage, communication or simple search, while separately addressing accessories and software that drives a device. [1,2]

Consider a hypothetical ECG platform. A function that simply transfers and archives an existing report does not become diagnostic software because a cardiologist opens it. A function that analyses a patient’s ECG and identifies suspected rhythm abnormalities presents a different qualification question: it generates information for an individual patient’s diagnosis.

That distinction matters when defining the product boundary. A platform can contain both medical and non-medical functions; calling the whole platform a records system does not resolve the status of its diagnostic analysis. Equally, a non-device function should not be labelled Class I as shorthand for “low risk.” Qualification comes before that classification choice.

Follow the information into the clinical decision

For software supplying information for diagnostic or therapeutic decisions, MDR Annex VIII Rule 11 starts at Class IIa. The consequence of the decision can raise the class: serious deterioration or surgical intervention points to IIb; death or irreversible deterioration points to III. [1]

The June 2025 MDCG guidance explains this through the significance of the information and the clinical situation, including the impact of an incorrect decision. This is nonbinding interpretation of the MDR, not a separate classification law. [2]

For the ECG platform, the useful question is therefore what happens after an incorrect result. Suppose the proposed first release identifies candidate rhythm abnormalities in recordings for scheduled specialist review. The classification rationale needs to explain whether clinicians examine the underlying recordings, what the analysis influences, and what happens to a patient when an important finding is missed. “A clinician reviews the result” leaves those issues unresolved.

If that review genuinely identifies errors before they affect care, it is part of the clinical workflow being assessed. If the clinician relies on the software’s negative finding to decide that further assessment is unnecessary, the result has a different influence. A missed finding could delay appropriate treatment; an incorrect positive finding could lead toward an unnecessary intervention. The analysis must connect those possibilities to the actual patient group and decision, rather than treating any mention of cardiac disease as sufficient to establish the highest class.

A broader claim can change the analysis without changing the algorithm

Now suppose the same hypothetical company wants to use its output to support a decision that a patient with suspected dangerous arrhythmia can safely wait rather than receive urgent assessment. The commercial promise has changed: the product is helping to decide whether time-critical care can be deferred.

For this version, a false negative must be examined through that decision. If erroneous reassurance can lead to deferred care with death or irreversible deterioration as the consequence in the intended clinical setting, the Class III limb of Rule 11 becomes relevant. Where the supported consequence is serious deterioration or surgical intervention instead, the IIb limb is relevant. These are conditional applications of the rule, not final classifications of either hypothetical version. [1,2]

Scheduled review alone does not establish a lower class, and an urgent-care label alone does not complete the higher-class rationale. What makes the explanation defensible is the chain from output, to reliance, to clinical action or inaction, to harm.

This also explains why narrowing a claim can be a substantive product decision. Removing a rule-out use may require changes to the interface, instructions, evidence and sales proposition. Retaining the same clinical promise while adding a general disclaimer would not resolve the underlying inconsistency.

“Monitoring” does not settle the classification

Rule 11 also addresses physiological monitoring: generally IIa, or IIb for vital parameters whose variations could create immediate danger. Its residual category is Class I. Multiple applicable rules require the stricter result; software driving or influencing a device also requires the Annex VIII implementation analysis. [1]

A company should therefore be cautious about treating “cardiac monitoring” as a complete regulatory description. It might describe observing a parameter, interpreting that parameter to guide diagnosis, or influencing another device. Those functions create different analytical questions. MDCG 2019-11 rev.1 explains the monitoring provision as specific to software intended only for monitoring. [2]

The architecture label—cloud service, mobile application or embedded software—does not answer what clinical work the product performs.

Carry the reasoning into the evidence and commercial plan

Classification affects the conformity-assessment route: Class IIa, IIb and III devices involve notified-body assessment under Article 52. Clinical evaluation remains a requirement; the class does not itself specify an evidence program or study size. [1]

MDCG 2020-1 separates evidence of a valid clinical association, technical performance and clinical performance. That distinction is useful here. Demonstrating that an algorithm detects a pattern is not, by itself, the same as demonstrating that its output supports the proposed clinical use. [3]

For the hypothetical platform, Zaliance would recommend building the evidence plan around the use being sold. A scheduled-review claim raises questions about missed findings, false findings and the specialist’s interaction with the output. A claim supporting deferred urgent assessment requires evidence that addresses that decision and its consequences. The relevant population, reference standard and performance measures follow from those questions; they should not be inherited automatically from an earlier algorithm study.

This is also a budgeting issue. If the commercial team is still deciding between those claims, a single confident conformity-assessment estimate conceals an unresolved product decision. Zaliance recommends making the alternative scope assumptions explicit before committing to the evidence program and launch budget. That is a development-planning recommendation, not an additional MDR requirement.

A useful classification rationale ultimately explains why the intended use belongs in a particular class. Its value is that the same reasoning gives the product, clinical and commercial teams a shared basis for deciding which European product they are prepared to develop and support.

References

[1] Regulation (EU) 2017/745, consolidated 19 July 2026. Article 2(1), Article 51, Article 52, Article 61; Annex VIII, sections 3.3, 3.5 and 6.3 (Rule 11). Current law; consolidated text is a documentation aid.
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:02017R0745-20260719

[2] MDCG 2019-11 rev.1, Guidance on Qualification and Classification of Software, June 2025. Sections 3, 4.1–4.2.1 and 7. Nonbinding guidance.
https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en

[3] MDCG 2020-1, Guidance on Clinical Evaluation / Performance Evaluation of Medical Device Software, March 2020. Sections 4.1–4.4. Nonbinding guidance.
https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2020_1_guidance_clinic_eva_md_software_en_0.pdf