A design history file is the record of how a device was designed. ISO 13485 calls it the design and development file, in clause 7.3.10, and an auditor or a regulator reads it before accepting the device. It is easiest to understand as a V: needs become requirements and designs on the way down, and are checked on the way back up.
What clause 7.3 asks for
| Clause | Record |
|---|---|
| 7.3.2 | Design and development planning |
| 7.3.3 | Design inputs: the requirements the device must meet |
| 7.3.4 | Design outputs: drawings, specifications, software |
| 7.3.5 | Design reviews at planned stages |
| 7.3.6 | Verification: the outputs meet the inputs |
| 7.3.7 | Validation: the device meets the user's needs |
| 7.3.8 | Transfer of the design to production |
| 7.3.9 | Control of design changes |
| 7.3.10 | The design and development file itself |
Verification and validation are different questions
Verification asks whether you built the device right: does each output meet the input it answers? It is usually a test against a number. Validation asks whether you built the right device: does it meet the user's need in the intended use? It is done on production-equivalent units, with the people who will use them, in conditions like theirs.
Traceability is the thread
Each requirement should link forward to the output that answers it, the test that verifies it and the risk control it carries, and each test should link back. A table of those links, kept current, is what lets a reviewer check the file in hours rather than weeks. It is also what shows a gap: a requirement never verified, or a test with no requirement behind it.
How to keep it current
- Write each design input as a requirement that can be tested, and give it a number.
- Hold a design review at each stage, and record the decisions and the actions.
- Link each verification report to the requirements it verifies.
- Put each change through change control, with its effect on risk and on earlier verification.
- Keep one index of the file, so a reviewer can find any record in it.
Common mistakes
- Requirements that cannot be tested. "Easy to use" is a need; "set up in under two minutes by a trained nurse" is a requirement.
- Reviews with no minutes. A decision that was never written down cannot be shown to an auditor.
- Changes made in the drawings only. A change that skips change control leaves every earlier verification in doubt.
- Validation on prototypes. It has to be done on units that represent production.