Rob Packard Neither 21 CFR 820 nor ISO 13485:2016 provide specific guidance on the requirements for review and approval of DHF documentation or changes to design. However, anyone involved in these processes should be able to demonstrate competency. This is typically done by providing records of previous design project experience at previous employers and records of training for design controls and risk management. The design team should be cross-functional, and therefore there should always be more than one approval of design changes if the product is already on the market. If the product is not on the market yet, then the primary impact of changes is schedule delays and cost increases. The design reviews will ensure that multiple people review and approve design inputs, outputs and the final release of products. You will also need an independent reviewer identified for each design review. There are many training resources out there that are inexpensive and web-based.

Mark Proulx, CQA, cSSBB Cassandra Corrao Robert is, again, spot on. If you don't have an in-house expert or an independent consultant that has been through this process and can guide you through the least torturous path to having all the necessary documentation to show proof that all elements (requirements/inputs to outputs/validations) have been fulfilled in a format that lends itself to auditing, you might want to think about hiring someone in to at least walk you through the steps to have a well-defined DHF. I know the FDA is very sensitive to medical devices that fail and have poor design controls and history. I, personally, have seen many companies get hit hard because their DHF was literally nonexistent or terribly unorganized.

Jonathan Wacks Ideally, you should update your Design and Development Plan ("DDP") under the "Roles and Responsibilities" section with any key personnel changes.

G M Butcher The organization should already have a 'Design Control' SOP, perhaps even several. Train on these, revise if they do n match what is current. However, a more basic question arises based on your above input. Are you in in charge of the DHF (a subprocess of design control) or are you in charge of design control (the process)? The duties for each are different.

Hi
You should write a " letter to file " that describe the current status and attached it to the DHF.
Try to make all issues cleared by the letter, QA/RA need to approve it.

Meena Chettiar I suggest reading Design Control section under QSIT, Quality System Inspection Technique practiced by FDA auditors. It lays out the details on design control phases. One needs to be very careful to verify and validate design changes before they are anchored in to your DHF as part of batch records for each lot manufactured under GMP environment.

Cassandra Corrao Thank you for the responses! We are a very small company with basic, non-detailed SOPs. I am the only quality person there, so, engineering of course is in charge of maintaining the file, but as QA I want to ensure they aren't doing anything I have to answer for in an audit. So, when we defined one Engineer to the project, but another one signed for some of the documents, it jumped out at me as something I couldn't readily defend.

Cassandra Corrao Here is a free guide on Design Controls: http://blog.greenlight.guru/design-controls.

We also have free, on-demand webinars that go into some more depth on the topic of Design Controls.

Let me know if I can be of any assistance.

Hi Cassandra,

We generally have a signature authority list in associated with our doc control procedure. We designated a primary and a secondary authority in the absence of the primary. We intelligently assigned the secondaries to be those who would have knowledge of the role in general and wouldn't have to get caught up too much. So if your engineer is documented to have the skills to make decisions in the tenured engineers absence go for it. There is more than one way to skin a cat, so if you have a larger org with multiple projects and teams, it may make sense to designate in the primary and secondary signature authorities in your program document.