EU MDR Classification Memo: Single-Lead ECG AFib-Flagging App, Likely Class IIa (Rule 11)

Reading of inputs: "Paired wearable" is taken to be a manufacturer-specified ECG sensor (wrist or similar) whose single-lead signal the app analyses; the app, not the hardware, is the product assessed. "Adult consumers" is taken as over-the-counter, lay-user use, with no clinician-facing output. The EU market under Regulation (EU) 2017/745 is the single framework applied. The EU AI Act and national rules were not researched.

1. Verdict, with confidence

Device (software, MDSW): likely Class IIa under MDR Annex VIII Rule 11(a), with a realistic risk of Class IIb if the output is positioned as guiding a physician's diagnosis. Confidence: Medium.

The "detects AFib" claim gives the app a diagnostic and monitoring purpose, so it is a device. The class turns on Rule 11 wording and the notified body's view of the consequence of a wrong output. The closest EU precedent I could verify is a Class IIa declaration for a display app that shows an AFib detection output (Withings, below). It is a precedent for a similar function, not for this exact product.

2. Qualification reasoning

Legal definition: MDR Article 2(1) covers software intended by the manufacturer for human beings for "diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease". Flagging possible atrial fibrillation from an ECG is a disease-detection purpose. It meets the definition.
Intended purpose controls, not the label. Marketing "detects AFib" is itself the medical claim. Guidance says wellness or fitness apps do not qualify as MDSW (MDCG 2019-11 Rev.1, June 2025), but an app that targets a named arrhythmia is not a wellness app.
Direct guidance match: MDCG 2019-11 Rev.1 lists, as an example of qualifying MDSW, a smartwatch app that sends alarm notifications when it recognises irregular heartbeats for the purpose of detecting cardiac arrhythmia.
"No diagnosis shown to clinicians" does not take it out of scope. MDCG 2019-11 says Rule 11(a) is generally applicable to all MDSW with a medical purpose, because MDSW works by providing information used in decisions. A lay user deciding to see a doctor is such a decision (inferred).
Machine learning: it changes the evidence and lifecycle burden, not qualification. I found no MDR rule that classifies software higher merely for using ML (inferred from Annex VIII Rule 11 text).
IMDRF SaMD framework: MDCG 2019-11 maps IMDRF categories to Rule 11 in its Annex III. I did not extract a category for this product; this is open (section 7).

3. Classification table

Rule/code	Class	Rationale	Citation
Annex VIII Rule 11, first three paragraphs (sub-rule 11a) governs	IIa (default); IIb if decisions may cause serious deterioration of health	Software intended to provide information used for diagnostic or therapeutic decisions is IIa, unless decisions could cause death or irreversible deterioration (III) or serious deterioration or surgical intervention (IIb). A missed or false AFib flag leads to a consumer's choice whether to seek care; a "see a doctor" prompt supports IIa.	MDR Annex VIII
Rule 11(a), IIb limb (second and third paragraphs; rejected as default)	IIb	MDCG gives an example where a mobile app analysing heartbeat and informing a physician to guide diagnosis is IIb. Your app is consumer-facing with a doctor prompt, not physician-guiding, so it differs, but a notified body may read it closer to this example.	MDCG 2019-11 Rev.1
Rule 11, fourth paragraph (11b, monitoring)	IIa (IIb if vital parameters with immediate danger)	Applies to software intended only for monitoring. MDCG says 11b is a specific rule for monitoring-only MDSW; this app also flags disease, so 11a is the better fit. Heart rate is "vital", but AFib flagging is not immediate-danger continuous surveillance (inferred).	MDCG 2019-11 Rev.1
Rule 11, fifth paragraph (11c)	I	"All other software" is Class I. Not available: the app has a diagnostic claim.	MDR Annex VIII
Implementing rule 3.3	Same class as the driven device	If the app drives or influences a separate ECG hardware device, it takes that device's class; the Withings declaration cites it. MDCG states independent MDSW is classified in its own right.	MDCG 2019-11 Rev.1

4. Applicable standards

Standard	Status found	Why it applies
EN ISO 13485:2016 (with AC:2018, A11:2021)	Listed in consolidated Decision 2021/1182 (consolidated version identified as 17 June 2026 by its CELEX URL; annex rows read via an extraction tool)	Quality management system, assessed by the notified body.
EN ISO 14971:2019 (with A11:2021)	Listed in the same consolidated decision	Risk management, including false negatives and false positives.
EN 62304:2006+A1:2015 (software lifecycle)	Appears in the Commission standardisation request annex (C(2021) 2406) list of standards to be harmonised, deadline 27 May 2024; Official Journal status not verified	Lifecycle for software that is the whole product.
EN 62366-1:2015+AC+A1:2020 (usability)	Same annex; OJ status not verified (may already be listed; check)	Lay users must interpret the flag correctly.
EN 82304-1:2017 (health software)	Same annex; OJ status not verified (may already be listed; check)	Product-safety requirements for standalone health software.

I did not verify cybersecurity guidance (MDCG), clinical evaluation guidance (MDCG 2020-1) or IEC 60601-2-47 for ECG performance in this run. Whether the wearable hardware needs the IEC 60601 family depends on who is the manufacturer of the sensor (open).

5. Pathway and key steps

Fix the intended purpose and claims in one document (user, population, output wording, "see a doctor" prompt). The class follows it.
Establish the QMS to ISO 13485 and the risk file to ISO 14971; apply software lifecycle and usability processes.
Choose a notified body. Class IIa generally needs a notified body (inferred; not checked against the MDR text in this run). The Withings Class IIa display app was assessed under Annex IX Chapters I, II and III by TÜV SÜD (body 0123) (declaration of conformity; signature date not stated in the extract). I did not verify the other available Class IIa routes in the MDR text.
Clinical evidence: a clinical evaluation including algorithm performance on adjudicated ECG data. The FDA predicates show the shape of data expected: Samsung's ECG classification showed 98.1% AFib sensitivity and 100% sinus rhythm specificity in a 544-subject study. That is US evidence, not an EU threshold.
Technical documentation, declaration of conformity and CE mark with the notified body number.
Registration: actor and device registration and UDI in EUDAMED; I did not fetch these requirements, so confirm them.
Post-market surveillance and vigilance obligations apply; details not verified in this run.

6. Comparable devices

Device	Holder / number	Date	Indication (abridged)	Similarity / difference
Withings ECG App Display	Withings; Basic UDI-DI 3700546711459V6; EU declaration	Not stated; EC certificate expires 2030-07-17	A software accessory that displays the ECG Monitor 2's atrial fibrillation detection output and the filtered ECG	Declared Class IIa, Rule 11 (applying implementing rule 3.3). Closest EU analogue; but the detection runs in the hardware and the app is an accessory, unlike your app, which analyses.
Samsung ECG Monitor App (FDA 510(k) K201168)	Samsung Electronics; product code QDA; 21 CFR 870.2345, Class II	4 Aug 2020	OTC single-channel ECG app for adults 22 and over, labelling AFib or sinus rhythm to aid heart rhythm identification	Same function and consumer use. US route, so no EU class is implied. Page is an Innolitics copy of FDA records, not the FDA database page.
Samsung ECG Monitor App with Irregular Heart Rhythm Notification (K230292)	Samsung Electronics; QDA and QDB	2 May 2023	Adds PPG-based irregular rhythm notification and prompts the user to record an ECG	Adds PPG monitoring you do not have. Its predicates were Apple DEN180042 and K201168.

I did not locate a second EUDAMED listing, and EUDAMED itself was not queried.

7. Borderline risks and open questions

"Detects AFib" vs "suggests an irregular rhythm": softer wording does not take the app out of scope, since both are arrhythmia-detection purposes (inferred from the MDCG smartwatch example). It can change how a notified body reads the decision impact.
Clinician-facing output or shareable reports: raises the chance of the IIb example (app informs a physician to guide diagnosis). Today's "no clinician output" supports IIa. Note the Samsung apps generate a PDF the user can share.
Use by people with known arrhythmia, children, or monitoring or treatment guidance (such as anticoagulation advice): each moves the decision toward IIb or III (inferred from Rule 11 tiers).
Hardware ownership: if the wearable is branded or specified by you, it may be a combined device and rule 3.3 may apply.
Missing facts: who manufactures the sensor; false-negative impact in your risk file; IMDRF category; AI Act status; whether harmonised standards 62304, 62366-1 and 82304-1 are listed in the Official Journal.

Do next

Write a single intended-purpose statement and claims list; test it against Rule 11 wording.
Ask two notified bodies for a pre-application view of IIa vs IIb.
Confirm the OJ harmonisation status of EN 62304, EN 62366-1 and EN 82304-1.
Plan clinical performance study on adjudicated single-lead ECG data.
Check AI Act and cybersecurity obligations separately.

Coverage note: EUR-Lex HTML pages returned errors for direct fetch, so the MDR text came via an extraction tool; EUDAMED, Official Journal standards list, NANDO and FDA's own database pages were not reached; FDA records were read through an Innolitics mirror.

Preliminary analysis, not legal or regulatory advice; the notified body or regulator makes the determination.