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.
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.
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. No scenario exercises this role yet, so Practise comes later for it, 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.
- 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