SaMD Quality Lead
Holds quality for software that is itself the medical device — where the release cadence software culture expects meets a regime designed around physical product.
8 FACETS · THREE ALTITUDES · FREE, NO ACCOUNT REQUIRED
What a role map is not
A role map is orientation — not a job description, a competency framework, or a statement of what any employer expects of you.
Kept on this device, and on your account when you are signed in. It orders your route; it never hides a page, and it is not a judgment about you.
You are responsible for quality at a company whose product is software that does a medical job, so the software is the device.
You run a quality management system covering software design controls, risk management, verification and validation, and post-market surveillance, and you decide which changes are significant enough to require regulatory action before release.
Every practice your engineers regard as modern — continuous delivery, rapid iteration, learning from production — is a change-control question here, and answering it well rather than obstructively is the whole job.
YOUR NEIGHBOURHOOD, IN ONE CONNECTED SYSTEM
Inside the software developer, where the product and the device are the same artefact.
- Product definition and the intended-use statement that classifies it
- Release of a version to users
- Any regulatory submission for the product
- A stable intended-use statement — the classification follows from it
- Engineering practices that produce design and verification evidence as a by-product
- Post-market signal reaching the quality system rather than only the support queue
- Engineering, for a workable release path
- Regulatory, for submission evidence
- Clinicians and patients using the software
- The quality system covering design, risk and post-market activity
- The significance assessment on each change
- Post-market surveillance and complaint handling
- The clinical use of the software by a practitioner
- The intended-use statement itself, which the business sets
- Engineering’s internal tooling choices
- Company leadership, where a release would proceed without the required evidence
- The regulator, for reportable post-market events
- Design history and risk management files
- Verification and validation records tied to specific versions
- Change significance assessments and post-market surveillance records
WHAT THIS ROLE CAN EVIDENCE · 1
Mapped to this role in the published registry. Nothing on this site assesses them yet, so this is what the standard says the work involves — never a claim about you.
STARTER KIT · 4
Templates and working tools for what this role produces or decides first. A starting shelf, not a complete one.
A role map is Locate, moment 2 of 5: what surrounds your work, what you own, and what you escalate. It does not teach the practice or test it. Next is Learn — the Medical Device Quality pathway, then Practise in a scenario, then what any of it evidences. Skip any of them — the order does not change.
The regulations and standards this pathway anchors on. SPEQ decodes and cites each one; the authoritative text lives at the official source.
- IEC 62304:2006+A1:2015Medical Device Software — Software Life Cycle ProcessesIEC · last revised 2015-06-01
- IEC 82304-1:2016Health Software — Part 1: General Requirements for Product SafetyIEC · last revised 2016-01-01
- IMDRF/SaMD WG/N10Software as a Medical Device (SaMD): Key DefinitionsIMDRF · last revised 2013-12-09
- ISO 14971:2019Medical Devices — Application of Risk Management to Medical DevicesISO · last revised 2019-12-01
- ISO 13485:2016Medical Devices — Quality Management Systems — Requirements for Regulatory PurposesISO · last revised 2016-03-01