Three Ways to Make Design Verification Faster

Why Design Verification Takes Longer Than It Should

Design Verification for medical devices often feels like a rush hour traffic jam. Deadlines are approaching, all buffers are used up, everyone feels stuck, some people start trying to switch lanes, some are honking, while others try being inventive by creating shortcuts, bypasses and speed lanes. 

If skilfully orchestrated shortcuts, bypasses and speed lanes can be used to great effect. Unfortunately, this often descends in total chaos. Then, management has to step in to calm the situation. Everything is put on hold, assessed, replanned, and the process starts anew. 

In this article I want to propose three approaches to reduce verification workload (ideally before verification even starts). 

A lot of delays come from verifying things that don’t actually require verification, redoing work that already exists, or failing late in verification.

Separate Project Objectives from Design Requirements

Many projects start with a long list of “requirements,” but only a portion of them actually fall under Design Controls. Many “requirements” don’t require verification at all. Teams often mix Design Input requirements with internal constraints, stakeholder preferences, team goals, wishes, or development goals. These elements are crucial to lead the project to success, but they do not need verification activities. 

Separating Project Objectives from Design Input requirements is one of the fastest ways to focus verification scope and eliminate unnecessary tests. Just ask a straightforward question for every item: Does this describe how the medical device must perform, function, or remain safe? 

If the answer is no, it’s a Project Objective, not a Design Input requirement. Track and report it according to the business and stakeholder expectations, but do not plan verification for it. 

And if it’s not a design requirement for medical device, it doesn’t belong in the verification matrix, so no test protocols, no verification reports, no verification summary reports etc. 

To give you a better feeling for Project Objectives, here are a few examples: 

1. Reduce BOM cost by 15% compared to the previous medical device generation 
2. Complete prototype build by the end of Q2 
3. Achieve compatibility with existing manufacturing lines 
4. Minimise the number of custom components 
5. Align industrial design with corporate branding guidelines 

Keeping such aspects out of requirements and verification documents also reduces the risk for odd findings during audits and prevents financially or legally sensitive information being submitted to notified bodies. 

Here is what you gain by implementing Project Objectives: 

• A cleaner, smaller set of Design Inputs 
• Fewer tests and simpler traceability 
• A verification package focused on what truly matters for safety and performance 

Most teams over-verify because their inputs were never filtered. A mindful clean up early in development can eliminate dozens of downstream test cases.

Turn Engineering Work into Verification Evidence

A surprising amount of verification evidence is actually generated long before the formal verification phase begins. Engineers run tolerance analyses, simulate loads, calculate safety factors and review interfaces. As engineers we want to design good medical devices. This means we need to check and prove that they meet requirements while creating the design. The mistake is treating such exercises as “informal”. Because if the original evidence isn’t traceable, usable (lack of quality or information) or even lost, well you need to redo everything. 

If you evaluate whether the design is sound (i.e. a requirement is met), capture the output immediately. Don’t let good work go to waste! 

Examples include: 

• Strength calculations confirming a safety margin 
• Simulations showing performance under expected loads 
• Battery life modelling 
• Interface compatibility checks (Tolerance Analysis etc.) 
• Engineering rationales 

When documented clearly (inputs, assumptions, acceptance criteria, results), these analyses are valid verification methods. No extra test needed. Clearly here means an independent reviewer can understand and reproduce the rationale, analysis or test. 

Here is what you gain by implementing “Verification on the Go”: 

• Less duplication of work 
• Reduced dependence on late physical testing 
• Stronger, earlier evidence for key requirements 

This is one of the highest-leverage improvements because it turns existing engineering work into formal verification without increasing workload. 

The ultimate time saver is if analysis and report creation are automated and can be updated on the go as the project progresses. 

Verify High-Risk Requirements First

Risk-based thinking is a central theme in medical device development. However, in the context of device verification the approach is different to ISO 13485 or project risks. The idea here is not to assess the risk for a patient or user, or to decide which requirements are important for the business. Instead, the focus should be on: 

• What is the technical relevancy of the requirement? 
• What is the technical confidence in the solution? 

Answering these questions highlights which requirements must be verified early because their failure would have significant impact on the medical device project timeline. These requirements carry the highest cost of late discovery. 

Furthermore, this method does not eliminate verification tasks, it optimises task sequencing. By verifying high-risk technical requirements earlier (during component evaluations, early prototypes or subsystem tests) you uncover fundamental issues at a point in the project where they are still manageable. 

Examples of high-risk technical requirements: 

• New features (especially the ones that have not been tested) 
• Performance specifications far outside the currently evaluated working conditions 
• Introduction of a new technology to meet an existing requirement 
• Interactions of complex and hard to predict systems 

Verifying these items early uncovers architectural or performance problems before they ripple through the entire medical device. By contrast, requirements with lower technical impact can be verified later without slowing the critical path. 

Here is what you gain by implementing risk-based prioritisation: 

• Early visibility into the real technical risks 
• Fewer late-stage surprises 
• More predictable verification schedules 
• Verified foundations before testing low-risk elements 

Again, this approach does not reduce verification – it reorders it so that engineering time is spent where it has the greatest impact. 

A Leaner Verification Strategy

These three methods focusing only on true design requirements, capturing analysis evidence during design, and prioritising based on technical risk—interlock naturally. Each reduces a different source of unnecessary work: 

• Filtering Design Inputs prevents over-delivering. 

• Verification by Analysis prevents rework. 

• Technical Risk Prioritisation prevents late-stage redesign. 

None of this requires new tools or regulatory reinterpretation. They are rooted in standard design control principles and aim to keep verification lean. 

When verification focuses on what truly matters, teams deliver better medical devices, faster and with fewer surprises along the way.

Disclaimer. The views and opinions expressed in this article are solely those of the author and do not necessarily reflect the official policy or position of Test Labs Limited. The content provided is for informational purposes only and is not intended to constitute legal or professional advice. Test Labs assumes no responsibility for any errors or omissions in the content of this article, nor for any actions taken in reliance thereon.