ISO 13485 · MDR Article 10(9) · process architecture
How to structure a medical device quality management system
Build one operating system around the work your company performs, then map ISO 13485 and MDR obligations into it.
A useful QMS is not a collection of templates arranged in regulatory clause order. It connects management decisions, product development, suppliers, evidence, release and post-market feedback through defined owners and controlled records.
See the architecture ↓How this manufacturer operates
Sites · people · technology · supply chain
What the MDR adds
Strategy · evidence · UDI · PMS · vigilance
ISO 13485 foundation
Governance · resources · lifecycle · improvement
Consistent decisions and objective evidence for each released device
The direct answer
Structure the QMS around processes, not around a folder tree
Start with the decisions and work that move a device through its lifecycle. Requirements from ISO 13485 and the MDR should be mapped into those processes, not implemented as parallel systems.
Shows how work moves
- Each process has an accountable owner
- Inputs lead to defined decisions and outputs
- Interfaces between functions are visible
- Records prove that the process operated
- Feedback changes products and controls when needed
Shows only where documents are stored
- One procedure is created for every clause
- ISO and MDR duties are duplicated
- Templates exist without operating responsibility
- Technical files are detached from the QMS
- Complaints and changes do not update evidence
Use one process for one real flow of work. Add every applicable regulatory requirement to that process, identify the product-specific records it creates and maintain a matrix showing where each ISO and MDR requirement is covered.
Three connected layers
Separate the sources, integrate the controls
Select a layer to see its purpose. The layers explain where requirements originate, but the final QMS should combine them into shared operational processes.
A disciplined management system
ISO 13485 provides the framework for process control across management responsibility, resources, product realization, measurement, analysis and improvement.
- GOVERN
Quality policy, objectives, roles, management review and resource decisions
- CONTROL
Documents, records, competence, infrastructure, suppliers and validated processes
- IMPROVE
Feedback, complaints, audit, nonconformity, CAPA and data analysis
Device and market decisions required by the MDR
Article 10(9) names subjects the QMS must address, while other MDR provisions define records, reporting, registration and lifecycle obligations that must connect to those processes.
- ROUTE
Regulatory strategy, classification, conformity assessment and management of modifications
- EVIDENCE
Risk management, clinical evaluation, PMCF, GSPRs and technical documentation
- MARKET
UDI, registration, PMS, vigilance, economic operators and authority reporting
Controls shaped by the actual business
The QMS must fit the manufacturer’s technologies, sites, organisation, outsourced work and markets. These controls make the formal framework usable in daily operations.
- FIT
Define workflows for the actual team, products, software tools, sites and suppliers
- EXTEND
Add cybersecurity, business continuity, technology transfer or other relevant controls
- SIMPLIFY
Remove duplication while preserving responsibility, evidence and regulatory traceability
One complaint should enter one controlled process
That process can satisfy ISO 13485 complaint requirements, MDR vigilance and PMS duties, company service commitments and risk-management feedback at the same time.
A practical process map
Four process groups form the operating system
The exact names may vary. What matters is complete coverage, clear ownership and functioning interfaces between governance, the product lifecycle, enabling processes and feedback.
Set direction and accountability
- Regulatory strategy
- Quality policy and objectives
- Roles, PRRC and resources
- Management review
Create and maintain conformity
- Requirements and design
- Risk and clinical evidence
- Purchasing and production
- Verification and validation
- Release and market access
Keep work competent and reproducible
- Documents and records
- Competence and training
- Infrastructure and software
- Supplier and validation control
Return evidence to decisions
- PMS and PMCF
- Complaints and vigilance
- Nonconformity and CAPA
- Audit and change control
Risk · clinical evaluation · design · suppliers · strategy · management review
Every process starts with controlled information
Approved requirements, data, events, decisions or records enter through a defined trigger.
Criteria convert input into action
Responsibilities, acceptance criteria, escalation rules and required reviewers must be explicit.
Records prove the result
The process creates an approved record and sends relevant information to the next process.
MDR Article 10(9) coverage
Translate each legal subject into a process and record
The matrix is not the QMS itself. It is the coverage check showing where the legal requirement operates and which objective evidence an assessor can sample.
Regulatory compliance strategy
Management responsibility and resources
Risk management
Clinical evaluation and PMCF
Product realization and series conformity
UDI and registration data
PMS, vigilance and reporting
Improvement and corrective action
Requirements should point to processes, and processes should point to requirements
This makes omissions visible during implementation and helps an auditor move from a legal requirement to evidence or from a sampled process back to its regulatory basis.
Document architecture
Use the smallest hierarchy that keeps control clear
A large hierarchy does not create a mature QMS. Each level should have a distinct purpose, and product-specific evidence should remain connected without being copied into every procedure.
- 01DIRECTIONWHY
Policy and QMS scope
Commitments, system boundaries, exclusions and overall responsibility
- 02PROCESS CONTROLWHO · WHAT · WHEN
Process maps and procedures
Ownership, sequence, criteria, interfaces, outputs and records
- 03EXECUTION DETAILHOW
Work instructions and specifications
Task-level methods where consistency depends on detailed instruction
- 04OBJECTIVE EVIDENCERESULT
Forms, logs, reports and product records
Proof that decisions and activities met defined requirements
Describe the real process
Do not copy a standard into a procedure. Define how this organisation meets the requirement.
Reference authoritative records
A procedure may point to the risk file, technical documentation or register without duplicating it.
Delete fictional controls
If a step is not required or performed, do not include it merely because a template contains it.
Run the workflow before approval
Use a real device, supplier, complaint or change to reveal missing decisions and interfaces.
Implementation sequence
Build from scope to evidence, not from templates to signatures
The sequence below keeps documentation connected to the actual device, operating model and conformity route. Each gate produces inputs needed by the next one.
- 01SCOPE
Define products, legal entities, sites and markets
Fix the intended QMS boundaries, outsourced processes, applicable regulations and any justified non-applicability.
OUTPUTApproved scope and applicability register
- 02WORK
Map the real processes and their interactions
Identify inputs, outputs, owners, decisions, records, metrics, interfaces and external providers.
OUTPUTProcess architecture and responsibility map
- 03COVERAGE
Map ISO 13485 and MDR requirements
Assign every applicable requirement to a process and identify missing controls or evidence.
OUTPUTRequirements-to-process matrix and gap list
- 04DOCUMENT
Create procedures and controlled tools
Write only the detail needed for consistent decisions, then create forms, registers and templates that capture the required evidence.
OUTPUTApproved document set ready for use
- 05OPERATE
Train people and generate real records
Run design, supplier, production, release, complaint, PMS and change workflows using actual products and data.
OUTPUTImplementation evidence and corrected interfaces
- 06CHALLENGE
Audit the system and review performance
Complete internal audit, CAPA, management review and readiness checks before relying on the QMS for declaration or certification.
OUTPUTVerified effectiveness and management decisions
Test the architecture
Use two traces to find broken interfaces
A document review can confirm coverage. A trace shows whether the QMS actually controls a device and responds when new information arrives.
Follow one released device forward
- Intended purpose and regulatory route
- Requirements, risks and design outputs
- Suppliers, verification and clinical evidence
- Release, declaration, label and registration
- PMS plan and current lifecycle status
The same configuration, claims and decisions should remain visible throughout.
Follow one signal backward and forward
- Complaint, trend, audit finding or change
- Reportability and risk assessment
- Investigation, cause and corrective action
- Updates to design, evidence and documentation
- Effectiveness check and management visibility
No signal should stop inside the department that first received it.
Can the organisation explain why this exact device remains conforming today?
The answer should be reconstructed from current controlled records, not from undocumented knowledge held by one employee or consultant.
Common structural failures
Six ways a complete document set becomes an ineffective QMS
Most structural failures are interface failures. Each function may have documents, while the decision or information needed by the next function never arrives.
The standard is copied into procedures
Staff receive regulatory prose instead of roles, criteria and steps suited to the company.
MDR duties sit outside the QMS
Clinical, UDI, registration or PMS work is treated as a regulatory file with no controlled operating process.
Every clause becomes a separate SOP
One real workflow is split across overlapping documents with conflicting owners and records.
Templates arrive before the process
Forms collect convenient information rather than the evidence required for a defined decision.
Outsourced work leaves the system
Consultants and suppliers perform critical tasks without approved inputs, acceptance criteria or change notification.
Post-market data reaches a dead end
Complaints are closed without updating risk, clinical evaluation, design controls, CAPA or regulatory strategy.
Practical questions
Medical device QMS structure FAQ
Open the question that affects your certification route, documentation hierarchy or process architecture.
Does the MDR require ISO 13485 certification?+
The MDR requires manufacturers to establish, document, implement, maintain, keep up to date and continually improve a quality management system. It does not state that every manufacturer must hold an ISO 13485 certificate. ISO 13485 is the usual framework and certification is normally part of a Notified Body route, but the applicable conformity-assessment procedure and device class determine the external assessment.
Can the QMS consist only of ISO 13485 procedures?+
Not safely. ISO 13485 provides the management-system foundation, while the MDR adds device-specific and market-specific obligations such as regulatory strategy, clinical evaluation, UDI, registration, post-market surveillance, vigilance, economic-operator controls and procedures for regulatory reporting. The QMS must show where these duties are performed and recorded.
Does every MDR requirement need a separate procedure?+
No. The MDR prescribes subjects that the QMS must address, not one procedure per paragraph. Related requirements may be combined when responsibilities, inputs, decisions, records and interfaces remain clear. One integrated post-market process, for example, may connect complaints, PMS, vigilance, trend reporting, CAPA, risk management and clinical evaluation.
Should the QMS follow the clause order of ISO 13485?+
A clause-based matrix is useful for demonstrating coverage, but the operating system is usually clearer when structured around actual processes. Management, product lifecycle, supply, support and feedback processes can follow the way work moves through the company while a separate applicability matrix maps them to ISO 13485 and MDR requirements.
Can one QMS cover several device families and risk classes?+
Yes. Corporate processes can be shared, but device-specific requirements must remain visible. Intended purpose, classification, conformity route, evidence, suppliers, release criteria, UDI data, PMS methods and reporting outputs may differ. Use controlled product or family records beneath the common QMS framework.
How detailed should procedures be?+
Detailed enough for competent personnel to make consistent decisions and generate the required records. A procedure should define scope, ownership, inputs, sequence, decision criteria, outputs, records, interfaces and escalation. It should not reproduce legislation or describe steps the company does not perform.
What is the fastest way to test whether the QMS structure works?+
Trace one current device and one real issue through the system. Follow the device from intended purpose and requirements through risk, design, suppliers, verification, clinical evidence, release and registration. Then follow a complaint or change through assessment, escalation, CAPA and updates to risk, clinical and regulatory records. Broken links reveal structural gaps quickly.
Primary sources and next steps
Verify the architecture against the current requirements
The system must reflect the manufacturer, device types, risk classes, conformity routes and markets. Confirm current legal and normative requirements before approving the final structure.
Regulation (EU) 2017/745
Article 10(9), Articles 13 to 15, Annexes II, III and IX
ISO 13485:2016
Official ISO overview of the medical-device QMS standard
Harmonised standards
European Commission information and current references
MDCG guidance index
Current guidance on QMS-connected regulatory subjects
MDR QMS checklist
Review the implemented system against 84 detailed checkpoints
Regulatory compliance strategy
Structure the device-specific decisions required by Article 10(9)(a)
Build a QMS that your team can operate
Need to structure or simplify your medical device QMS?
MDRC can map applicable requirements, design the process architecture, define responsibilities and records, prepare the controlled procedures and test the implemented system before certification or authority review.
