Summary
- The problem
- Requirements, design outputs and verification live in separate documents joined by a spreadsheet matrix. A requirement with no test is a blank cell that nobody notices until an audit or a field problem.
- Seal’s approach
- Each design input links to its outputs, verification, validation and reviews. The traceability matrix is a view of those links, and a design change flags the outputs and verification it affects.
- What changes
- Gaps are visible while the design is developed, and the Design History File is organised from records maintained throughout development rather than assembled before an audit.
- Where to start
- One device programme or subsystem: import its requirements, link them to outputs and verification, and review the gaps. Book a demo.
1A requirement is controlled only when it is verified.
Consider a handheld device with a design input copied from a predicate: “Activation force shall not exceed 2 N.” Nobody questioned whether 2 N suited the intended users, and nobody defined a test for it. The traceability matrix showed input, output and verification for every other requirement. This row had a blank cell, and a blank cell in a spreadsheet is easy to miss.
The same device illustrates a second gap. Even a verified 2 N limit can be wrong if the users are elderly patients with arthritic hands. Verification asks whether the design output meets the input. Validation asks whether the device meets the user’s need. Design controls exist to catch both kinds of gap during development, when they are cheapest to fix.
2Documents alone make fragile connections.
In many organisations, design controls are a documentation exercise. Requirements live in one document, design outputs in another and the traceability matrix in a spreadsheet that is updated when someone remembers. Verification protocols are written, executed and filed. The Design History File is assembled before an audit, often by someone who was not involved in the development, from files on shared drives.
Documents and signatures exist, but the connections between them are maintained by hand. When a requirement changes, someone has to update the matrix. When a protocol is written, someone has to check that every requirement has a test. When the DHF is compiled, someone has to decide whether it is complete. Each of those checks depends on a person noticing the gap.
2.1Why teams choose Seal for design control
A manually maintained spreadsheet matrix joins design-control documents, but a requirement with no test is a blank cell nobody notices. Seal records inputs, outputs, verification, validation and reviews as connected records rather than lines in separate documents. The traceability matrix is a view of those relationships, so a missing link is visible when it is created, and a design change shows the outputs and verification it affects before it is approved.
| Documents and a spreadsheet matrix | Seal | |
|---|---|---|
| Traceability | A matrix maintained by hand | A view computed from linked input, output and verification records |
| Gaps | Found when someone reviews the matrix | Shown as missing links while the design is developed |
| Design change | A revised document; downstream impact traced manually | Linked outputs and verification flagged for review |
| Design History File | Assembled from shared drives before an audit | Organised from the design records maintained during development |
3Traceability is a view of real relationships.
- 47 design inputs (not met)2 have no linked output
- 42 design outputs (not met)2 have no verification
- 38 verifications (not met)1 input has no test
- 8 reviews (met)All signed
- 54 risk items (met)All controlled
A design input in Seal is a record with its source, acceptance criteria and owner. A design output links to the inputs it addresses. A verification record links to the outputs it verifies. Because the relationships are recorded, the matrix can show an input without an output, or an output without verification, as soon as the gap exists.
Designs change: user feedback reveals gaps, testing finds issues and manufacturing identifies producibility problems. A design change links to the records it affects, so its impact assessment starts from the recorded relationships. A changed input flags the outputs that address it for review; a changed output flags its verification and any validation for reassessment. Traceability is maintained through the change rather than repaired after it.
4Inputs, outputs and verification each answer a different question.
Design inputs come from several sources. User needs define the problem the device solves and for whom. Clinical requirements specify outcomes, populations and indications. Regulatory requirements follow from applicable standards, such as IEC 60601 for electrical safety or ISO 10993 for biocompatibility. Risk inputs come from hazard analysis, because the design must address identified risks.¹
Each input should be specific, measurable and traceable to its source. “Easy to use” is not a design input. “Activation force shall not exceed 2 N” is, although the team still needs evidence that 2 N suits the intended users.
Design outputs are the design itself: specifications, drawings, software architecture and manufacturing procedures. Each output addresses one or more inputs. An output that traces to no input raises a question about why it exists; an input with no output is a gap in the design. Outputs are controlled documents with versions, approvals and change history.
Verification is objective evidence that an output meets its input: the activation force was measured, documented and assessed against the limit. Validation tests the device with representative users under defined conditions, so a device can pass every verification and still fail validation. Keep both linked to the requirements they address.²
5Design reviews close with their actions resolved.
A design review is a cross-functional checkpoint. Engineering presents the design status, quality reviews completeness, regulatory assesses the applicable requirements and manufacturing evaluates producibility. The review evaluates the design against defined criteria for its stage: whether inputs are finalised, outputs documented and verification planned.
Action items from a review link to it in Seal, with owners and due dates. Configure the review so that it cannot close while its actions remain open. The record then shows what was found, what was done and who accepted the result.
6The Design History File grows with the design.
The design history file (DHF), which ISO 13485 calls the design and development file, is the record of the design process: inputs, outputs, reviews, verification, validation and changes.³ When it is assembled before an audit, documents go missing, versions disagree and the result is uncertain.
Design records are linked as they are created, so the DHF can be organised from those records during development rather than reconstructed afterwards. Review its completeness against your procedure and the applicable requirements before relying on it for an audit or a submission. The same linked evidence supports submission preparation, such as V&V summaries for a 510(k).
7Neil prepares the structure; engineers own the design.
Describe the device to Neil, for example a Class II cardiovascular device subject to IEC 60601-1, IEC 60601-1-2 and ISO 10993. Neil can propose a design control structure: requirement categories, candidate inputs drawn from those standards and verification approaches for each. The engineering and quality teams review the proposal against the device and its intended use before adopting it.
During development, Neil can flag requirements that lack measurable acceptance criteria and inputs with no linked output. When preparing the DHF, it can assemble the design inputs, outputs, verification and reviews and list incomplete sections for the team to address. When the next programme starts, it can propose which parts of the earlier structure apply and what is new. People decide what the design must achieve and approve the records.
8Close the gap during development.
Return to the activation force. The design input links to user research on the target population’s hand strength. The output is the specification that translates that need into a measurable criterion. The verification record holds the protocol, test method, results and conclusion, and the validation record shows the device tested with representative users. An unverified requirement shows up as a gap during development, not after release.
Start with one device programme or one subsystem. Import the existing requirements, link them to outputs and verification, and review the gaps the matrix shows.
References
- 1ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes, clause 7.3.3, Design and development inputs: inputs relating to product requirements, including functional, performance, usability and safety requirements, applicable regulatory requirements and standards, and outputs of risk management, must be determined and recorded. ISO
- 221 CFR Part 820, Quality Management System Regulation: incorporates ISO 13485:2016 by reference, effective 2 February 2026. eCFR
- 3ISO 13485:2016, clause 7.3.10, Design and development files: a design and development file is maintained for each medical device type or family, containing or referencing the records that establish conformity with design and development requirements, including records of design changes. The US Quality Management System Regulation (21 CFR Part 820, effective 2 February 2026) incorporates ISO 13485:2016 by reference and no longer uses the term design history file. ISO eCFR
AOperating model
Included in this blueprint
- Design input management
- Traceability matrix
- Design reviews
- V&V management
- Design transfer
- Linked DHF
- Software design controls
- Risk-driven requirements
- AI traceability gaps
- AI DHF compilation
Connected across Seal
BCapabilities
| Capability | What it covers |
|---|---|
| Design input management | Capture user needs, clinical requirements, regulatory standards and risk inputs, each with its source, measurable acceptance criteria and owner. |
| Traceability matrix | Link inputs to outputs, verification and validation. The matrix is computed from those links and shows inputs without outputs or outputs without verification. |
| Design reviews | Schedule reviews and record attendance, decisions and action items. Configure a review so it cannot close while its actions remain open. |
| V&V management | Manage verification and validation protocols, execution and results. Link results to the requirements they verify. |
| Design transfer | Track readiness for manufacturing. Process validation, equipment qualification, training, DMR completion. |
| Linked DHF | Organise the Design History File from the design records maintained during development, then review its completeness against your procedure. |
| Software design controls | Record software requirements, architecture, detailed design and unit and integration testing, with rigour appropriate to the IEC 62304 safety class. |
| Risk-driven requirements | Hazards from risk analysis become design inputs. Risk controls trace through design outputs to verification evidence. |
| AI traceability gaps | Neil can flag requirements without measurable acceptance criteria, inputs without outputs and outputs without verification while the design is developed. |
| AI DHF compilation | Neil can assemble the design inputs, outputs, verification and reviews into a DHF and list incomplete sections for the team to address. The team reviews completeness before relying on it. |
CConnected records
DQuestions and answers
How do you handle design changes after initial development?
Design changes follow the same process as new development. A change links to the records it affects, so the impact assessment starts from the recorded relationships, and review, V&V and traceability are updated as needed. The DHF records how the design evolved.
Can we import requirements from external tools?
Yes. Import design inputs from requirements management tools, Excel or Word documents. Once imported, requirements become traceable records in the design control system.
How do you link to risk management?
Hazards identified in risk analysis become design inputs for the controls that mitigate them. Design outputs address those inputs and verification confirms the controls work. The risk file and the DHF reference each other.
What about software design controls?
Software follows the same design control framework, with the additional rigour IEC 62304 requires for its safety class. Software requirements, architecture, detailed design and unit and integration testing are traced in the same way as the rest of the design.
How do you support 510(k) submissions?
The linked design records hold the evidence that supports a 510(k), such as V&V summaries and the basis for comparison with a predicate. Because the records are maintained during development, preparing the submission starts from current evidence rather than files gathered afterwards. The regulatory team still reviews and assembles the submission.
Can multiple teams work on the same design?
Yes. Role-based access controls determine who can create, edit and approve design records. Teams can work in parallel on different subsystems while maintaining traceability to system-level requirements.
How do you handle COTS components?
A commercial off-the-shelf component has its own design inputs: the specifications you require from the vendor. Verification confirms the component meets them. You are responsible for how the component is used in your device, not for the supplier’s own design history.
What about design controls for accessories?
Accessories and companion products have their own design control records linked to the primary device, with interface requirements between them. When a linked requirement on the primary device changes, the dependent accessory records can be flagged for review.
How do you handle post-market design changes?
Post-market changes follow the same design control process. The impact assessment identifies which inputs, outputs and verification need revision, and the change links to the complaint or field feedback that prompted it.