Skip to content

EU MDR Annex VIII Rule 11 — SaMD Classification for EPPA

Classification is provisional

EPPA is currently a research-use tool and is not placed on the EU market. The classification reasoning below describes the likely class of EPPA if and when it is placed on the EU market as a medical device. Until that point, the non-device disclaimer in 91-non-device-disclaimer.md governs.

1. Document identity

Field Value
Document title EU MDR Annex VIII Rule 11 Classification — EPPA
Document ID EPPA-MDR-CLS-001
Version 0.1 (draft)
Status Draft — not approved for submission
Effective date n/a
Owner LABIS UCA — Regulatory lead (pending)
Linked documents 00-overview.md, 01-intended-use-statement.md, 11-iec-62304-lifecycle.md, 12-iso-14971-risk.md

2. Regulatory anchors

  • Regulation (EU) 2017/745 ("EU MDR"), in particular:
    • Art. 2(1) — definition of "medical device".
    • Art. 7 — claims.
    • Art. 10 — general obligations of manufacturers.
    • Art. 51 — classification of devices.
    • Art. 52 — conformity assessment procedures.
    • Art. 56 — certificates of conformity.
    • Art. 61 — clinical evaluation.
    • Art. 87 — reporting of serious incidents and field safety corrective actions.
    • Annex VIII — classification rules (Rule 11 applies to software).
    • Annex IX — conformity assessment based on a quality management system and on assessment of technical documentation.
  • MDCG 2019-11, "Guidance on qualification and classification of software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR".
  • MDCG 2019-16 Rev.1, "Guidance on cybersecurity for medical devices".
  • IMDRF/SaMD WG/N12FINAL:2014, "Software as a Medical Device: Possible Framework for Risk Categorisation".

3. Qualification — is EPPA "software as a medical device" (SaMD)?

The first question is qualification: does EPPA fall within the definition of a medical device in Art. 2(1)? The decision logic in MDCG 2019-11 §3.2 is applied below.

Step (MDCG 2019-11) Question EPPA answer Result
Q1 Is the software a Medical Device Software (MDSW)? Does it perform an action on data different from storage, archival, communication or simple search? Yes — EPPA computes geometric metrics from marker placements (segment angles, alignment offsets) and qualitative classifications (e.g. "left deviation"). Proceed
Q2 Is the action for the benefit of an individual patient? Yes — output is generated per patient session and is attached to the patient's research record. Proceed
Q3 Is the intended purpose any of: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, or compensation for an injury or disability, or investigation/replacement/modification of anatomy or a physiological process? At commercial intent: monitoring of postural alignment and diagnosis-supporting outputs. At current research-use phase: explicitly not claimed (see 01-intended-use-statement.md §8). Conditional

Qualification is intent-driven

Per Art. 2(1) and MDCG 2019-11 §3.1, qualification turns on the intended purpose declared by the manufacturer. As long as EPPA carries the non-device disclaimer and the intended-use statement in 01-intended-use-statement.md §2, EPPA is not a medical device. Once a future version drops the disclaimer and adds diagnostic / monitoring claims, EPPA becomes MDSW and Rule 11 applies.

4. Classification — Rule 11 walkthrough (post-market-placement)

Rule 11 of Annex VIII has the following structure (paraphrased; consult the authoritative EUR-Lex text for precise wording):

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause:

  • death or an irreversible deterioration of a person's state of health, in which case it is in Class III; or
  • a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as Class IIb.

Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb.

All other software is classified as Class I.

4.1 First branch — does EPPA "provide information used to take decisions with diagnosis or therapeutic purposes"?

Sub-question EPPA answer
Are EPPA outputs used by a clinician as input to a diagnostic / therapeutic decision? At commercial intent: yes — the clinician would consider postural-alignment metrics when planning posture-correction or physiotherapy interventions.
Is the decision impact "death or irreversible deterioration"? No. Postural assessment errors do not cause death; an incorrect "right deviation" classification leads, at worst, to mis-prescribed corrective exercises with reversible consequences.
Is the decision impact "serious deterioration or surgical intervention"? No. EPPA is explicitly out of scope for pre-operative planning (see 01-intended-use-statement.md §5).

The conclusion is Class IIa under Rule 11 first sub-paragraph, first indent. MDCG 2019-11 §5.2 confirms that "software intended to provide information to clinicians for postural / musculoskeletal interpretation" falls in this branch.

4.2 Second branch — does EPPA "monitor physiological processes"?

EPPA captures static snapshots of standing posture, not a continuous physiological signal. It therefore does not fall under the physiological-monitoring branch of Rule 11. This branch is mentioned here for completeness only.

4.3 Final classification — Class IIa

EPPA is classified Class IIa under EU MDR Annex VIII Rule 11, first sub-paragraph, first indent.

Why not Class I

The "all other software" residual is Class I (per Rule 11 third sub-paragraph). EPPA does not qualify because its outputs are intended for diagnostic / therapeutic decision support. Class I would only apply to purely descriptive or storage software (e.g. an image viewer with no measurements).

5. Conformity assessment route

For Class IIa devices, conformity assessment is governed by Art. 52(6), which refers manufacturers to:

  • Annex IX, Chapter I (assessment of QMS), and
  • Annex IX, Chapter III, Section 4 (assessment of technical documentation on a representative basis per generic device group), or
  • Annex XI Part A (production quality assurance), or
  • Annex XI Part B (product verification).

The practically standard route for Class IIa SaMD is Annex IX Ch I + Ch III § 4 — a notified-body QMS audit plus technical-documentation review on a representative sample.

5.1 Required artefacts for the technical file (non-exhaustive)

Artefact EU MDR reference Owner EPPA status
Device description and intended purpose Annex II §1 Regulatory DRAFT in 01-intended-use-statement.md
Risk management file (ISO 14971) Annex I §3, Annex II §5 Quality DRAFT in 12-iso-14971-risk.md
Software lifecycle artefacts (IEC 62304) Annex I §17 Software DRAFT in 11-iec-62304-lifecycle.md
Cybersecurity assessment (MDCG 2019-16) Annex I §17.2, §17.4 Security DRAFT in 50-secdev-checklist.md
Clinical evaluation report (Art. 61, Annex XIV Part A) Art. 61 Clinical Missing
Post-market surveillance plan Art. 83, Annex III Regulatory Missing
Periodic safety update report (PSUR) Art. 86 Regulatory Missing (post-launch)
Declaration of Conformity Art. 19, Annex IV Regulatory Missing
UDI assignment Art. 27, Annex VI Regulatory Missing
Instructions for use and labelling Annex I §23 Regulatory DRAFT (intended-use serves as the seed)

5.2 Notified body selection

Class IIa SaMD requires a notified body designated under EU MDR for software medical devices. As of the date of this document, notified-body capacity for SaMD is constrained (MDCG 2022-14). The regulatory lead must:

  1. Shortlist notified bodies designated under EU MDR with the relevant codes — for software, MDS 1011 (active non-implantable medical devices) and the horizontal software competence per MDCG 2019-6.
  2. Request a quotation and a slot. Realistic backlog: 6 to 12 months as of 2026.
  3. Open a designation file once a notified body is engaged.

Indicative notified-body candidates (verify designation status before engagement):

  • TÜV SÜD Product Service GmbH — NB 0123.
  • BSI Group The Netherlands B.V. — NB 2797.
  • DEKRA Certification B.V. — NB 0344.
  • DNV Medcert GmbH — NB 0124.
  • TÜV Rheinland LGA Products GmbH — NB 0197.

Verify designation

Notified-body designations change. The authoritative list is the NANDO database — https://ec.europa.eu/growth/tools-databases/nando/. Before any commercial engagement, confirm that the candidate is designated for Regulation (EU) 2017/745 (not the legacy MDD 93/42/EEC) and for the relevant codes.

6. EUDAMED registration

Pursuant to Art. 29 (UDI) and Art. 30 (electronic system for registration of economic operators), and Art. 33 (European database on medical devices — EUDAMED), the following EUDAMED actions are required before placing EPPA on the EU market.

Action EUDAMED module Trigger Owner
Register as a manufacturer (Actor module) Actor registration Before any other EUDAMED action LABIS UCA Regulatory
Obtain SRN (Single Registration Number) Actor registration Output of the above Automatic
Assign a Basic UDI-DI UDI module Before declaring conformity Regulatory
Assign a UDI-DI per device version UDI module Per release Regulatory
Register the device UDI/Device module Before placing on the market Regulatory
Upload certificate references Certificates module After notified-body issues the EC certificate Notified body or Regulatory
Upload SSCP (Summary of Safety and Clinical Performance) Certificates / SSCP Required for implants and Class III; Class IIa optional but recommended for trust Regulatory
Report incidents Vigilance module On occurrence (Art. 87) Regulatory + Quality
Submit PSUR Vigilance / PMS module Per Art. 86 cadence (every 2 years for Class IIa) Regulatory

EUDAMED status (2026)

EUDAMED has been rolled out in stages. The Actor, UDI/Device and Certificates modules are live. The Vigilance and Clinical Investigation modules' mandatory-use date has been deferred; confirm current state against the EU Commission's EUDAMED status page before sign-off.

7. Cross-references to MDCG guidance

MDCG guidance Relevance to EPPA
MDCG 2019-11 — qualification and classification of software Authoritative source for the Rule 11 decision in §4.
MDCG 2019-16 Rev.1 — cybersecurity Required input to the technical file; see 50-secdev-checklist.md.
MDCG 2020-1 — clinical evaluation of medical device software Required for the clinical evaluation report under Art. 61.
MDCG 2021-24 — guidance on classification of medical devices General classification reference; confirms Rule 11 logic for SaMD.
MDCG 2022-14 — notified body capacity Critical for planning the conformity-assessment timeline.
MDCG 2019-6 Rev.4 — notified body competence Used to verify notified-body designation scope for software.
MDCG 2018-1 Rev.5 — Basic UDI-DI and changes to UDI-DI Required for UDI assignment.

8. Reasonably foreseeable misuse — classification impact

ISO 14971 §4.2 requires consideration of reasonably foreseeable misuse. The following misuse scenarios were considered when classifying EPPA, and do not change the Class IIa conclusion:

  • Use on paediatric patients (contraindication C2) — misuse, but does not escalate the harm severity into Class IIb territory because mis-prescribed paediatric exercise interventions remain reversible.
  • Use as the sole basis for surgical planning — explicit non-claim (intended use §8). If misuse were widespread enough to be foreseeable, the classification would arguably escalate to Class IIb; the mitigation is the non-device disclaimer plus the surgical-planning non-claim.
  • Use on smartphone with insufficient calibration — gives wrong absolute measurements but does not yield qualitatively different decisions of higher severity.

9. Open questions for the regulatory lead

  1. Confirm Rule 11 first indent vs. Annex VIII Rule 12 — Rule 12 concerns "active therapeutic devices intended to administer or exchange energy". EPPA does not administer energy and Rule 12 does not apply. Confirm in writing.
  2. Confirm UDI issuing entity — GS1, HIBCC or ICCBBA. GS1 is conventional for software in Europe.
  3. Confirm classification reasoning against MDCG 2019-11 §5.2 examples, especially the example on "musculoskeletal screening software".
  4. Confirm whether common specifications under Art. 9 apply — none currently for postural-assessment software, but confirm.
  5. Confirm SSCP requirement — Class IIa does not require an SSCP under Art. 32 (which is Class III and implantables only) but voluntary publication may be advisable for trust.

References