The Design Process - Medical Device Design: Innovation from Concept to Market - page 48

Firstly, it is important that the specification for the new product/device/piece of software
is robust. It must be developed as a whole, and not by a single individual sitting alone in a
darkened office. It is far too important to treat without due consideration.
Secondly, the expansion of the project by the generation of ideas is critical. The project
must avoid “sacred cows.” No stone should be left unturned; all ideas are valid until proven
otherwise.
Thirdly, the reduction of the design space to a single potential solution is critical. This process
must be robust in itself.
Fourth, the detailed design of the new product must, in itself, be robust. And the evaluation
that the design meets the requirements laid down by the specification is paramount.
Only when these steps have been employed do we have robust design control. However, it
is important that the lessons of the serial, collaborative, concurrent, and holistic models are
learned. Try to be proactive and not reactive. Build iterative loops into your design to enable
your design to change as it develops. Make sure you use all the modern communication tools
to communicate with any of your potential stakeholders. And, finally, bring people into the
design process as early as possible - this will make your life a lot easier in the long run.
3.4 Cross-Reference with Regulatory Requirements
As stated earlier, there are four main documents we must be sure we comply with. The first
two are the FDA CFR 21 and 93/42/EC (the two main regulatory documents, as presented
earlier). However their implementation is also covered by ISO 13485 and the FDA's Design
Control Guidance for Medical Device Manufacturers (note: the FDA refers to ISO 9001). In
essence, with respect to design, they all say the same thing - do the right things and ensure
you do them properly . To paraphrase, they all state that we must listen to the customer
and end-user, and produce a specification. They all state that we need to perform a robust
design analysis, and they all ask for a final document (the technical file or design folder) that
describes the final design and how it was arrived at. Up to now we have discussed models of
design; now we need to leave the world of models and start to implement. At the same time
we need to make sure that our design activities cross-reference with the relevant regulatory
document(s).
As an example, I will cross-reference with the FDA document Design Control Guidance for
Medical Device Manufacturers ( FDA, 1997 ). Figure 3.21 takes the divergent-convergent model
presented earlier and maps this to the essential sections described in the FDA guidelines.
Figure 3.21 demonstrates that internally we can use whatever language we like. However,
when it comes to the regulatory authorities we must understand their requirements and their
language. All that we do must map onto their framework. It is pointless to base your model on