How to create a process for ISO 13485
ISO 13485 makes the records evidence for a regulator: verification against the design input, validation against the user's need, a transfer gate, and a rationale on every kill branch.
A worked example, stage by stage
Regulation is a design input
Idea, screen, feasibility, concept, then "Identify regulatory requirements". It sits in the Quality lane while the business case is still being built rather than after a design exists. Intended use and the applicable regulation are inputs to be verified against later, not a review at the end.
A kill needs a reason on file
"Gate 1: develop or kill?" arrives with both stopping routes drawn: "Recycle" returns the case to "Build the business case" and "Kill" ends at "Idea shelved with rationale", a box whose purpose is its last word. "Go" arrives in the next stage. A gate that can only be passed is a milestone.
Two tests, one row on the chart
Rework goes back: "Design review passed?" sends it to "Develop the detailed design", and its "Passed" branch straight into "Plan and run validation testing". That row is the validation; no row verifies the output against the specification, and "Meets requirements?" fails back to the design too.
Transfer is a gate, not a handover
Design transfer belongs at "Run a limited production pilot": the point at which a design that works has to be shown to be manufacturable on the line that will make it. "Gate 2: approve launch?" then sends "Extend pilot" back to that pilot and "Kill" to "Launch stopped at gate 2".
How it works
Write the design inputs first
Intended use, user needs, the applicable regulatory requirements, and the risk controls that follow from them. These are the things verification will later be tested against, so a vague input makes verification unfalsifiable. An input that cannot be shown to have been met is an input that gets argued about at the audit.
Decide which records the file must hold
List them before drawing anything: review minutes naming the functions present, verification and validation protocols and results, the rationale behind each rejected option, transfer evidence, and the risk file at each stage. The map's job is to show where each of those is produced, so every record needs a row producing it.
Type the stages in, then add the missing test
One row per stage in the Box text column. Then add the row this example does not have: a verification step after "Build a working prototype", its Line to pointing at the design review, so the review reads verification results and "Plan and run validation testing" is left answering the user's question alone.
Give every gate a branch that stops it
Each gate takes Decision in the Shape column, with its outcomes in Line text in the order the numbers appear in Line to. Give the stopping outcome a Reject row of its own instead of an arrow into space: in a design file the route that was not taken is evidence somebody will have to read.
Check reviewer independence in the lanes
13485 wants each design review to include representatives of the functions concerned and someone independent of the stage under review. Typing every owner into the Vertical lane column makes that checkable: in the example "Design review passed?" sits in the Engineering / R&D lane, beside the prototype it is reviewing.
Trace one requirement through the file
Take one design input — a requirement from "Identify regulatory requirements" — and follow it forward. It should reach a row that verifies it against the specification, a row that validates it in use, and a review that read both results. A requirement reaching only one of the three is the gap an inspector finds.
Frequently asked questions
What is the difference between verification and validation?
Verification asks whether a design output meets the design input specified for it — a measured dimension against a drawing, a tested output against a stated requirement. Validation asks whether the resulting device meets user needs and intended use, under conditions representing actual use and on product made by the intended process. Verification can pass on a device that is wrong for its user; validation is what catches that. ISO 13485 requires plans, records and conclusions for both, separately.
What does ISO 13485 clause 7.3 require?
Planning, documented design inputs and outputs, reviews at planned stages, verification, validation, transfer, control of design changes, and a design and development file per device type or family. Each of those is a record obligation as much as an activity. The clause also requires the inputs to include applicable regulatory requirements and the outputs of risk management, which is what separates a 13485 development process from a stage-gate process with a quality step added to it.
What is design transfer in ISO 13485?
Design transfer is the verified translation of a design into production specifications: procedures, tooling, inspection methods, training and acceptance criteria that let the device be made repeatably. The standard requires transfer procedures with records verifying that design outputs are suitable for manufacturing before production begins. Treating it as the moment drawings reach the plant is why first production lots fail for reasons no prototype ever showed.
Is ISO 13485 stricter than ISO 9001 about procedures?
Yes, deliberately. ISO 9001:2015 lets an organisation decide what documented information it needs; ISO 13485:2016 names documented procedures clause after clause — design and development, purchasing, production control, complaint handling, corrective action — and keeps the quality manual requirement that 9001 dropped. The practical consequence is that a process map here is not optional supporting material: it is part of the procedure a regulator asks to see, at the revision that applied.