Tag Archives: verification

Three ways to smooth your path for device development

Medical Device Development routemap v5.0 narrow viewSpring of 2013 still seems recent, so I was surprised to realise that the route map for medical device development will shortly be 3 years old. If it were a child in the UK, we would be able to get 15 hours free childcare a week from this September.

Children learn and grow at an alarming rate, especially when you’re looking back over what seems like a very short time and realise that the baby you remember holding in your arms “yesterday” is now a teenager.

The route map too is growing up fast. It’s being used across the world, from Australia, through Asia to Europe and on to North America. Users have fed back great experiences. Uses ranging from a desktop aide mémoire, a teaching aid, through to a planning and design review tool!

There comes a time when a child learns new skills, and naturally integrates them into their daily lives and toolkit.

We’re proud to announce the launch of the route map for medical device development 5.0 today. Numerous user suggestions have been incorporated in this new version, along with two new tracks; Intellectual Property and Market Research.

The route map continues to help you in three ways, it;

  1. Describes the journey you’ll embark upon, from a device idea through to launch.
  2. Sets out the main activities for each of 9 disciplines, through four stages of product development.
  3. Identifies the points where there are major interactions between disciplines.

And here it is…

Click to open a pdf version you can download

Click to open a pdf version you can download

You may already see how this picture will be helpful, whether you’re working in medical devices, combination products, pharmaceuticals, aerospace, defence, electronics…..

Send me your thoughts on how you can use the route map, because having a straightforward, independent view is always valuable.

FDA finalises Human Factors Guidance – Part 2

In this series of posts, we’re taking a look at the recently published final version of CDRH’s guidance “Applying Human Factors and Usability Engineering to Medical Devices”.

FDA HF guidance FINALIn part 1, we looked at both the Human Factors Engineering process and Risk Management and Human Factors, two of the key topics covered by the Center:

  • Human Factors Engineering process
  • Risk Management and Human Factors
  • Design Verification
  • Summative Human Factors testing
  • Changes to products already on the market
  • Human Factors Engineering Summary report

Lets look at how the topic of Design Verification may impact what you’re either already doing, or plan to do.

Design Verification

Design Verification has vanished from a Human Factors perspective – probably a relief for device development teams who were scratching their heads about what was needed in addition to Design Verification as described in ISO 13485 and 21 CFR §820.30 Design Controls.

So now, we can focus on Design Verification being all about confirming that the design outputs (i.e. the device design and associated specifications for performance and attributes) meet the design inputs (what you wanted the device to be able to do). It’s about physical evaluation and testing of devices to confirm, for example, that the force required to turn a dial meets your specification limit. To confirm that the robustness and mechanics of your design function as intended.

Now that might sound straightforward, just get some sample devices from (pre-)production and test them, right?

Design Verification tests shouldn’t be “tick box” tests. Sadly, that’s often what is done by way physical testingof Design Verification, however this misses the fundamental point of verifying the design – to confirm that the device performs as required, throughout the range of your specifications. Design Verification demonstrates that devices manufactured/assembled with components from all across your specified ranges actually do work together, and more than that, they work as intended. Verification shows that your “design envelope” works in practice. It also gives you reasonable confidence that, when your manufacturing and assembly processes vary (within your specification) which they will do, the end product is safe to place on the market. And in the long run, that should mean less surprises.
Certainly, the scale of Design Verification can vary hugely, depending upon the number of components, their manufacturing process variability and so on. But it doesn’t need to be a big deal.

You need to be able to rely on the results of Design Verification

Taking care to plan, design and execute DV is a great step on your journey to getting your product on the market. Consider how you will know you can rely upon the data that are generated and analysed.

We’re often asked whether test equipment need to be qualified and test methods validated? You could take the approach of using development equipment and test methods that are not yet optimised. How will you be able to show, to your board and investors, that DV is truly representative of production data?

The long and the short of it is;

  • Qualify your test equipment before using it for DV,
  • Optimise and then validate the test methods you plan to use during DV.

Take both steps and you’ll have a high degree of confidence that the results you get are translatable to production and routine inspection situations. And there’s the added bonus that you would have needed to do the work anyway during industrialisation and launch preparation.

Spare yourself the nightmare of discovering at that late stage that there was a critical issue with the way you planned to release batches of product onto the market.

When is the guidance effective?

You will have some time to assimilate the requirements…

A whole 6 weeks, as they go live on 3 April 2016.

How will the changes will affect your product development?
What impact they will have upon your Human Factors Engineering programme?

Get in touch today to discuss how you can best navigate the changes and emerge with a Design Verification programme that is “just right” – you know, “fit for purpose”.

Is your product development missing these key activities?

With the much anticipated and long overdue update to ISO 13485 moving out to the end of the year and probably into 2016, it looks like medical device companies can breathe easy for a little while longer, before beginning the revamp of their Quality Management System.

Is it time to relax though?

Time to breathe easy?Before you relax too much, consider that people often miss out chunks of the current version of the standard, or focus on its content; forgetting about hot topics that are not currently well defined. Their absence in development projects gives me a headache on a regular basis. Headaches that are cured when we resolve things like;

  • Traceability from the initial requirements through to what has been validated and is (hopefully) about to be manufactured for the market. Often traceability is done late on in development and unsurprisingly, holes are found in the design and testing. Sometimes it’s that critical or frequently used functions were overlooked in test design, other times that testing crept to include parameters or functions that weren’t part of the device design.
  • Test results during development that can be held up to scrutiny (i.e. the equipment was qualified and the method validated). Quick and dirty tests are often called for by design engineers, and certainly have a place in concept development. Saying its “just for development” or the data is “for information only” may seem fine at the time, but as soon as you try to use the data to support a decision… or, I hesitate to say it, transfer a test method from supplier to manufacturer, what then? This seems particularly prevalent where computers, software and spreadsheets are brought into the mix.

Continue reading

Zen and the Art of Design Controls

There are days when I think “is it me?” Especially when it comes to appreciating Quality Systems. I confess I do like logic and I even get a buzz when I see a logical progression in project deliverables, moving from A to B to C and so on. It’s wonderful, having links and traceability.

I must make it clear I have never been part of a Quality Department. I have been involved in medical device development for many years and lived through, what I now think of as the unenlightened times (although immensely fun), when we defined our own ways of working, prior to the introduction of Design Controls and ISO 13485; having standards and guidance is now quite comforting for me. This probably explains why I find it distressing when I come across people who do their level best to ignore or get round the logical order laid out in Design Controls.

I struggle to grasp why it is faster to go from A to C and then back to B and then try to jump to D. Worse Tortoise and Hareyet are those who think they can start at C and miss out A & B, until they reach stage F. I have experienced this in various guises and I don’t think I have ever seen a project delivered anywhere close to the original time lines when run like this, usually missing the mark by several years.

Hind sight is a wonderful thing and yes I have on occasion been known to fall back on it, having been carried along with the fast track idea. However, when it comes to building up a sound development package, skipping through stages invariably comes back to bite you if you choose to miss bits out.

Filling documentation gaps that should have been produced much earlier in a project is always fun.

No, I am lying, it really isn’t.

If you have ever had to do this you’ll know that you find out why your project hasn’t gone as swimmingly as you had hoped it would (back to that pesky hindsight thing). Here are three real life examples:

  • Producing the User Requirement Specification for a product when the product design is already decided and having the realisation that the wrong (unjustifiable) features have been added or that critical features are missing from the design is always a hoot.
  • Completing a design FMEA and dreaming up a raft of new and impossible to execute tests after all of the Verification testing has finished.
  • Finally a personal favourite, conducting usability studies with no idea; who the target audience is, what their requirements are or how the device is intended to work.

There has been much in the press lately about the brilliance of 3D printing and undeniably it is fantastic what can be achieved. But there is a flip side; 3D printing has made the possibility to jump around Design Control stages even easier. Designers can now generate what looks like a finished product before anyone else has even had the chance to think about what the problem is that the development team are trying to solve.

It is all too easy to focus on refining or “optimising” this nearly finished product. Contrast this with concepts presented as block models, sketches or simulations. There’s an inherent understanding that much work lies ahead to turn the best concept into a fully fledged, marketable device.

Design Controls CascadeThere are many graphics out there that try to explain Design Controls. The one thing they have in common is that; to get a good output you need a good input, to get a good input you need a good understanding of the problem you are solving.  For me following the flow of Design Controls takes away a lot of development pain and anguish of trying to guess what comes next.

Design Controls is basically a logical progression built from the years of knowledge of other people who have already suffered in development limbo and have found a clear, signposted way through.

“Begin with the end in mind”
Stephen Covey

Look out for our post later this month that may help you think about the point of each stage in Design Controls, enabling you to get the most out of each stage of development.