Medical Device Design Transfer: 5 Things You Need to Know
By Charlie Sears – VP of Operations & Project Management
There are many publications that discuss product development. However, an area that I find challenging within medical device companies is effectively transferring a product from concept development (R&D) to production (sustaining engineering). Why is design transfer a challenge?
● Knowledge. Product teams don’t fully understand what’s necessary for design transfer. During the product development process, due to the developmental nature of R&D, decisions are made quickly without much thought toward what’s necessary for design transfer.
● Time. Product teams don’t have enough time or resources to create the documents while the work is being done. Product team members tend to be subject matter experts and will do/know what’s necessary to make the product work.
Typically, it’s the pressure of time and a lack of knowledge that will force the team to backtrack their work to provide objective evidence that the product conforms to requirements. If the documentation doesn’t conform to the requirements of the company’s QMS, it’s effectively useless.
If we add time back to the product teams by improving their knowledge and understanding of the requirements for design transfer, we will improve the design transfer process. How do we improve knowledge and understanding?
1. Clearly capture the requirements for design transfer.
Establishing a procedure to ensure the device design is translated into production specifications is a requirement of 21 CFR 820.30 (h) – Design Transfer. While a single procedure may be too high-level to properly document the data necessary to complete the transfer, the information should be captured in the product development plan. The plan should document all necessary records to ensure the documentation is complete and well supported by required verification and validation records. While it may be difficult to have a single checklist that covers all transfers within an organization, it still must be understood what is required to be reviewed. You should never have someone withholding approval due to missing information if it wasn’t a documented requirement.
2. Create a quality system that allows for a level of control appropriate for the activity at the time of the activity.
Part of the reason why things aren’t done when they should be is due to the amount of time and effort to get them completed. Typically, it’s not the authoring of documents that takes a lot of time, but the review and approval process that leads to delays. Keep the review and approval process to a minimum level necessary for the stage of product development.
3. Leverage the engineering build process to create your design transfer documentation.
This is the most important thing that you can do. Experience has taught us that it is much easier to document as you go rather than look back and document what was done. At a minimum, work with the teams to properly identify procedural changes via redlines or a deviation process. Do not forget about documenting inspection aids, fixtures, and custom tools. These tend to be developed as necessary and evolve over time; however, if you can document as you develop, you’ll have much less frustration at design transfer.
4. Maintain a flexible, risk-based approach to vendor selection and product purchasing.
R&D teams will purchase anything from anyone; therefore, a fast, flexible purchasing procedure that will allow the product team to quickly procure components while remaining compliant to the QMS is a must. Categorize components based upon a risk-based assessment into purchasing categories. Then connect the categories to vendor selection criteria and component inspection requirements.
5. Create and utilize a compliant supply chain process for the manufacture and purchase of products for verification and validation.
Products (non R&D) that will be used to produce records, which will be used for submission or other regulated activity, carry a greater burden to ensure compliance to specifications than products purchased for R&D. This does not mean that the process needs to be difficult and the specifications complex. Prior to purchasing, (using the risk-based approaches mentioned earlier) the product team must ensure that the requirements of the component are clearly documented and understood. The greater the risk, the greater the requirements. This also includes the vendor. A vendor that’s acceptable for R&D purchasing may not be acceptable for later purchasing.