Vendor track · Module 1 · 40 min

Map Your Product

Before asking what class you are, build a stable picture of the thing you are regulating: the regulatory unit and its dependencies, the input → processing → output → user → action chain, generated versus pass-through information, patient-specific routes, supported configurations, use context, and the claims your company actually controls.

After this module you can

Create a stable, versioned picture of the thing you are actually regulating — before anyone argues about qualification or class.

Choose and state an explicit regulatory unit: whole product, one function, or a linked combination
Describe the supported product rather than the default demo
Map input → processing → output → user → downstream action in factual language
Separate information your product generates from information it only passes through
Record patient-specific routes, linked devices and module dependencies before interpreting them
Compare product reality with formal, commercial and restrictive wording
Recognise when the profile is still too ambiguous to support regulatory analysis

Module 2 interprets this profile. This module deliberately produces no conclusion about medical devices, the EU Medical Device Regulation (MDR), the In Vitro Diagnostic Medical Devices Regulation (IVDR) or class.

This course is educational decision support for vendors and is not legal advice. It structures regulatory reasoning and produces learner-authored working positions. It does not tell you whether your product is a medical device, whether MDR or IVDR applies, what class it is, which conformity route applies, whether a notified body is required, or whether your AI system is high-risk under the AI Act, and it produces no compliance or readiness score. It does not replace a competent regulatory review. MDCG and AI Board guidance is cited throughout because it is the practical reference practitioners use, but it is not binding law: only the regulations themselves bind, and only the Court of Justice of the European Union gives binding interpretations of them. Regulatory basis reviewed: 18 September 2026.

Step 1

What exactly are we regulating?

A regulatory discussion becomes unreliable when different people are silently talking about different products. A founder may mean “our platform”. Engineering may mean one model. Sales may mean the feature shown in a demo. A regulator or notified body — an independent organisation designated to assess conformity where the applicable route requires it — will need a much more precise answer: which software, function, configuration and intended use are you describing?

So draw a boundary. Sometimes the right unit is the whole product; sometimes one function needs describing separately because it has a different purpose, output or risk profile. Carving a module out does not make its dependencies disappear: if another module is necessary for it to work, or its output is consumed by a clinical function elsewhere, that relationship stays part of the factual record.

Version and configuration matter as much. “Our product does not use laboratory data” is only true if no supported deployment, connector or customer configuration can use laboratory data. A default setting, a system prompt, a sales policy or a banner is not the same thing as technical impossibility.

Your first task is deliberately non-regulatory: name the product or function, state the version or configuration, and list what it depends on. Resist labelling anything “medical” or “non-medical” yet.

Define the regulatory unit

Name the thing you are describing and the relationships that stay part of the record even if you analyse one module on its own.

Are you describing the whole product or one specific function or module?

Product or function name, as the team actually calls it

Current version or release identifier

Is this function being added to a product already placed on the market?

Module dependencies

What other modules or shared functionality does it depend on, and what depends on it?

Which external devices or systems does it operate, configure, control, enable or assist?

Merely receiving data from another system is not the same as operating, enabling or assisting it.

Name of that device or system, if any

Is the linked device a medical device, an IVD, or unknown?

Lab progress

0 of 7 steps complete

Your Blueprint

A · Product boundary — Not written yetNot written yet
B · Workflow and context — Not written yetNot written yet
C · Claims inventory — Not written yetNot written yet
D · Draft intended purpose — Not written yetNot written yet
E · Qualification assessment — Not written yetNot written yet
F · Classification position — Not written yetNot written yet
G · Conformity strategy — Not written yetNot written yet
H · Clinical evidence plan — Not written yetNot written yet
I · EU AI Act overlay — Not written yetNot written yet
J · QMS and lifecycle plan — Not written yetNot written yet

Your own writing, section by section. Nothing here is scored, and no section states device status, a class, a route or readiness.

Sources & evidence · 8 sources

This module cites primary legal, public or consensus guidance.

Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.

Regulation (EU) 2017/745 (MDR), consolidated text 02017R0745 — 19.07.2026
Article 2(1) and 2(12) definitions; Article 10 manufacturer obligations; Article 15 PRRC; Article 52 and Annexes IX–XI conformity assessment; Article 61 and Annex XIV clinical evaluation; Annex II technical documentation; Annex VIII implementing rules and Rule 11.
Open source
Regulation (EU) 2017/746 (IVDR), consolidated text 02017R0746 — 10.01.2025
Article 2(2) in-vitro diagnostic definition and Article 2(4) accessory definition.
Open source
Regulation (EU) 2024/1689 (AI Act), consolidated text — 27.07.2026
Article 3 definitions and actor roles, Article 6 high-risk classification routes, Articles 8–15 requirements for high-risk AI systems, Article 25 value-chain responsibilities and the transitional provisions.
Open source
MDCG 2019-11 rev.1, Qualification and Classification of Software in MDR and IVDR — June 2025
Figure 1 and Figure 2 decision sequences, §3.1–3.3, §4.2.1, Annex II examples and Annex IV classification examples.
Open source
MDCG 2021-24 rev.1, Guidance on classification of medical devices — April 2026
Supplementary Rule 11 teaching examples. Used as illustrative context, not as a determination.
Open source
MDCG 2020-1, Clinical evaluation of medical device software
Valid clinical association, technical performance and clinical performance as the structure of a software evidence plan.
Open source
MDCG 2025-10, Post-market surveillance guidance
Used for the surveillance, PMCF and vigilance loop taught in Module 7.
Open source
MDCG 2025-6 / AIB 2025-1, interplay between the MDR/IVDR and the AI Act
Used for how the two frameworks sit alongside each other, including integrated documentation and conformity work.
Open source