Vendor track · Module 7 · 50 min
Build Your QMS & Lifecycle Plan
The operating system behind everything you have written, learned through a change-impact exercise: quality-management processes and owners, design and change control for software that ships continuously, supplier and foundation-model dependencies, post-market surveillance, PMCF, vigilance and CAPA — ending in a learner-authored QMS & Lifecycle Plan and the assembled Regulatory Readiness Blueprint v1.0.
After this module you can
Turn the regulatory position into a system that keeps the product controlled as the model, the data, the suppliers and the claims change.
- Describe a quality management system as a set of connected processes rather than a document set
- Name who owns each lifecycle decision and which record proves it
- Design change control that copes with model, data, supplier and claim changes
- Manage foundation-model and supplier dependencies as a regulatory risk
- Describe post-market surveillance as a feedback system feeding risk, evidence and change
- Distinguish a defect from an incident escalation without deciding reportability yourself
- Work out which saved artefacts a given change forces you to revisit
Your Blueprint is now complete across all ten sections. The last step assembles it, carries every unresolved question forward, and hands it to a competent reviewer.
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
A QMS is the operating system, not a binder
The MDR requires manufacturers to have a quality management system, described as processes: regulatory strategy, requirements, design and development, resource and supplier control, risk management, clinical evaluation, product realisation, post-market surveillance, communication with authorities, incident and corrective action management, and change management. Read it as an architecture diagram, not a table of contents.
For a software company that means an operating system, not paperwork. Every one of those processes already happens in some form — you decide what to build, review code, release, handle bugs, answer complaints. The regulatory question is whether those activities are defined, followed, evidenced and improved, and whether the person accountable for each is named. Remove one link and the others quietly go out of date, which is what the exercise on the next step shows.
Standards are how most companies implement this, and their status is worth being precise about. A quality management system is a legal requirement. Specific standards — for quality systems, risk management, software lifecycle or health software — are widely used industry practice, and where a standard is harmonised and cited in the Official Journal, conformity with it can give a presumption of conformity with the corresponding requirements. Using a standard is not the obligation itself, and a certificate against a standard is not a conformity assessment of your device.
Management
Owns the quality policy, resources and the decision to release. Evidence: management review records with decisions, not attendance.
Regulatory and quality
Owns intended purpose control, the documentation set, reportability assessment and the audit trail. Evidence: controlled documents and decision records.
Clinical and evidence
Owns the clinical evaluation, the evidence plan and the acceptance criteria. Evidence: the evaluation plan and report, kept current.
Engineering and product
Owns requirements, traceability, verification and validation, configuration and release. Evidence: traceable requirements-to-test records.
Security
Owns threat modelling, vulnerability handling and dependency monitoring. Evidence: assessments and a handled-vulnerability history.
Supplier management
Owns contracts, change notification and evidence access for model and API providers. Evidence: agreements and monitored change logs.
The MDR also requires a manufacturer to have available a person responsible for regulatory compliance, with defined qualification requirements and defined responsibilities, and it makes proportionate provision for micro and small enterprises. Treat it as a named accountability to plan for, and take advice on how it applies to your organisation.
0 of 7 steps complete
- 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 sourceRegulation (EU) 2017/746 (IVDR), consolidated text 02017R0746 — 10.01.2025
Article 2(2) in-vitro diagnostic definition and Article 2(4) accessory definition.
Open sourceRegulation (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 sourceMDCG 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 sourceMDCG 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 sourceMDCG 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 sourceMDCG 2025-10, Post-market surveillance guidance
Used for the surveillance, PMCF and vigilance loop taught in Module 7.
Open sourceMDCG 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