Implementing Design Procedures - Medical Device Design: Innovation from Concept to Market - page 63

Note that after each procedural step there is an opportunity to review the outputs ( Table 4.1 ,
Row #8: Design Outputs) and confirm whether they are appropriate, correct, and meet
expectations. Clearly, if all is well they are approved; this is done formally with a signature and
date. A good way of doing this is to have a single product/project approval form with all sign offs
listed sequentially. Also, it is worth taking the opportunity to review the design history file after
each procedure. This enables you to see if anything has been missed or if any procedures have
been incorrectly applied. It is far more efficient to keep this file up to date as you progress along
the design path, to try and assemble it at the end - this way madness lies.
Furthermore, this is the opportunity to review any risk analysis - the risk analysis for the design
is alive and changes as the design develops. It is, therefore, good practice to undertake a risk
analysis review (Section 4.5.6) as a part of each approval stage as this will inform any feedback.
For example, your design for a clinical thermometer may not quite meet a requirement to
measure temperature up to 42°C; it actually measures up to 39.95°C. According to the criteria
this is a failed design and must be rejected. However, you conduct a risk analysis that actually
suggests this is acceptable and poses no risk, so the design can go forward.
Alternatively you may have an automated insulin injection system that should not be able to
overdose a patient, but under certain circumstances it provides a 110% dose. Here the risk analysis
states the risk is unacceptable and hence the design is rejected with the feedback attached.
Hence a good risk analysis is a very valuable tool for the project leader! If all is not well,
the noncompliance, and its root cause , needs to be passed back to the appropriate source.
Identification of the root cause is very important - the risk analysis helps with this as does
the “5 Whys.” Note that even though the design may be rejected, the DHF is still reviewed
because we still need to ensure that all has been done properly. Equally, as stated before, we
need to learn from failures and be seen to be doing so.
After each of the individual subprocedures has been followed, a completed final product
should be ready for release. At this point the Design History File/Design File/Technical File
is closed as a new product. It now becomes the “bible” for that device and is maintained with
the utmost care. However, as we shall see later, it will be reopened on a regular basis as the
effects of postmarket surveillance kick in.
4.5.2 Clarification/Product Specification Procedure
This procedure is important as it meets all of the requirements associated with input in
the FDA guidelines and in ISO 13485. This is, by far, the hardest of all the procedures to
develop as the potential inputs are infinite. However, I have tried to summarize the sources in
Figure 4.4 - this is the bare bones of such a procedure.
Figure 4.4 illustrates the process to develop the full product specification. There are numerous
influences on the product specification and, much like a cloud, they tend to hover above