Medical Device Quality — career pathway
The quality function for devices and diagnostics — design controls, risk management across the product lifecycle, and the post-market feedback loop that closes back onto the design.
What a pathway is not
A pathway is a reading route, not a qualification. Completing one evidences that you read it, and SPEQ says exactly that on the credential.
What the function does
Holds the quality system for devices and diagnostics — design controls, risk management across the product lifecycle, and the design history file that has to read as one coherent argument.
Closes the post-market loop: complaints, vigilance reporting and trending feed back into risk files, design changes and CAPA rather than dying in a spreadsheet.
- Design Assurance Engineer — Holds requirements traceability, verification and validation evidence, and the risk file through design changes.
- Complaint & Vigilance Specialist — Runs complaint intake and investigation, reportability decisions, and post-market trending.
- Device QMS Specialist — Maintains the quality system procedures, supplier controls and internal audits against ISO 13485 and the QMSR.
- Run design controls end to end — inputs, outputs, review, verification, validation, transfer and design changes.
- Apply risk management across the lifecycle and keep the risk file current as design and post-market evidence change.
- Assemble and defend the design history file so the design argument survives an inspection years later.
- Handle complaints and vigilance, decide reportability, and trend post-market signal back into design and CAPA.
- Qualify and monitor suppliers of components, sterilisation and contract manufacture.
The regulations and standards this pathway anchors on. SPEQ decodes and cites each one; the authoritative text lives at the official source.
- 21 CFR Part 820Quality Management System Regulation (QMSR) — 21 CFR Part 820FDA · last revised 2026-02-02
- ISO 13485:2016Medical Devices — Quality Management Systems — Requirements for Regulatory PurposesISO · last revised 2016-03-01
- ISO 14971:2019Medical Devices — Application of Risk Management to Medical DevicesISO · last revised 2019-12-01
- IEC 62304:2006+A1:2015Medical Device Software — Software Life Cycle ProcessesIEC · last revised 2015-06-01
Know · collaborate · escalate
- What design controls require at each stage and why traceability is the spine
- How risk management runs across the lifecycle, not just at design freeze
- What makes a complaint reportable, and to whom
- Trace every design output to an input and to its verification evidence
- Keep the risk file current through design changes and post-market signal
- Investigate complaints to a real cause and trend them
- Design reviews with R&D and manufacturing
- Reportability calls with Regulatory Affairs
- Design transfer with production and supplier quality
- Any signal suggesting a safety issue in a marketed device — immediately
- A design change proceeding without risk assessment or verification
- A reportability decision you are being pressed to soften
- That a design output is verified because it looks obviously correct
- That a risk file written at design freeze still reflects the marketed device
- That “no failure found” on a complaint means there is nothing to investigate
- R&D / Engineering — design inputs, design changes, and verification evidence
- Regulatory Affairs — submission content and reportability decisions
- Manufacturing & Supplier Quality — design transfer and component controls
Your first 30 / 60 / 90 days
- Read one product’s design history file end to end and map its traceability.
- Learn how complaints enter, get investigated, and become reportability decisions here.
- Own the traceability matrix for one design change through verification.
- Investigate complaints independently and draft the trending summary.
- Update a risk file from real post-market data and defend the change at design review.
- Present a post-market trend and its proposed design or CAPA response.
- Writing design outputs that cannot be traced back to a stated design input.
- Treating the risk file as a submission deliverable instead of a living record that post-market data updates.
- Confusing verification (built right) with validation (built the right thing) and evidencing only one.
- Closing complaints as “no failure found” without asking whether the trend says otherwise.
- Leading design reviews and defending the design argument to an auditor
- Running lifecycle risk management rather than a one-off hazard analysis
- Reading post-market data well enough to see a signal before it becomes a recall
- Owning the state of the design history file across a portfolio
- Owning the post-market surveillance system and its escalation path
- Owning supplier and sterilisation-partner quality relationships