Integrating Regulatory Requirements in Medical Device Design

April 21, 2014


• Categories: 04-Product Design & Development

New regulatory guidance, especially those on human factors, has pushed classic medical device companies to include user experience (UX) and industrial design (ID) as part of the development process. Since medical companies tend to be focused on the core technology, UX and ID are often outsourced to product design consultancies. This can sometimes create an unfortunate disconnect in the product design process. With any product design there are great advantages to having design and engineering teams working together in an integrated fashion throughout the process. In medical design, it is vitally important for the regulatory requirements to be equally integrated. This article will look at how the engineer responsible for meeting regulatory requirements can facilitate this integration and help development teams deliver better products. 

Whether design is done internally or outsourced, the regulatory engineer must make the regulatory needs consumable/accessible to the product designer. These needs are usually included in the product requirements document (PRD), which everyone on the team should be familiar with. The problem is that some of the items, as written in the PRD, are not very consumable. For example, requirements around drop and vibration might be easily interpreted as the need for ruggedness, but other items, such as radiated susceptibility, are not as easily understood. Radiated Susceptibility (aka Radiated Immunity) is the ability of the device to operate correctly in the presence of electromagnetic disturbances. 

Designers work by first developing a thorough understanding of the entire context around the product… everything from why the product exists, to how it will be made, how it will be used and dozens of other elements. They are able to hold the big picture context in their heads and allow informed intuition to lead them to some truly wonderful solutions. But if the regulatory requirements aren’t communicated in a way that allows them to be understood at this intuitive level, they can get lost along the way. Design fixes that happen later in the game to meet regulatory requirements are rarely satisfying for anyone. Last minute changes are more expensive than those that happen at the front-end of the process. This and tight timelines can lead to unsatisfying design patches that meet the requirements, but overall dilute the design intent and product impact. 

So how can regulatory engineers help integrate regulatory requirements into the process? The five steps below can be an effective framework to approach this problem: 

1. Gather regulatory requirements. Regulatory requirements for a given application must be pulled in early and be made understandable and consumable by all other disciplines. A common mechanism for this is a product requirements document where in addition to general product requirements regulatory requirements are also tucked away. 

2. Distill for Consumption by Product Design Team. Although the need for a PRD does not disappear, a more consumable mechanism should exist. These requirements need to be discussed in common terms to intimately inform the team of what is needed. The requirements don’t have to be completely softened to the point of the layman, but they must be general enough to exist as a concept that intuitively informs the design and is not an abstruse statement that reads as if written in a different language. Just having the statement that the product must meet “IEC 60601-1-2 for ESD” may not be as consumable as understanding that the device will be shocked with high voltage and needs to maintain operation. Therefore, the device should minimize direct air paths to internal circuitry, and must not use sensitive electronics for non-essential functionality. This kind of understanding could potentially and appropriately move a design team away from using touch screen which might have an amazing display, but contains very sensitive electronics. 

3. Design with Regulatory and Other Design Inputs. Innovative product design does not happen linearly. Often the product design team will organically churn on a problem trying different forms based on intuition. Designers don’t go sequentially through the list of requirements one at a time implementing solutions for each one in isolation. Instead, they develop a holistic view of the problem statement and create a product architecture and design that is a satisfying solution to the problem. This is where the direct need of “distilled” regulatory requirements must be present in the designers mind in terms that make sense. 

4. Test design (check design intent) against regulatory requirements. All regulatory needs should map to regulatory requirements that are testable. It may not be required to actually run all the final tests, but the requirements should at least be reviewed in order to check that the design intent of the product addresses these requirements. Often this process requires the integration and expertise of many different disciplines (electrical, mechanical, and even software). On subsequent iterations of the design, the set of regulatory requirements should be reviewed. It should be checked that the design changes did not inadvertently lose design intent while satisfying the regulatory requirements. For both designers and engineers, it can be challenging to keep the full list of requirements in mind while solving individual issues. It’s vital that they work do to so, however, as solving one problem may cause a new issue. For example, to satisfy drop testing a padding layer may be added between external pieces of the shell of the product, but once this addition could mean the product may not pass water ingress testing. There are many ways to run this review process and it should be up to the team to decide what makes the most sense. Regardless of what the formal review process, everyone on the team should be regularly checking that regulatory needs are being addressed. This can be as simple as dedicating a half hour each week to go through the list and do a quick mental check. 

5. Iterate. As always, product development is a highly iterative process. As a product evolves through the development process, it may be necessary to go through this cycle multiple times. 

Whether you follow this specific framework or not, it is vital to find ways to integrate regulatory requirements into the front-end of the design process in a highly-consumable way. Effective and early integration of regulatory requirements enables design and development teams to create products that will not only gain regulatory approval, but will achieve their highest design intent and, by so doing, find success in the marketplace.