Regulatory Open Forum

I don't see a problem with the exclusion. This is clearly a contract manufacturer that does not design the device.

For one point, for example, if they don't design the device, then design inputs are not applicable.

There is a potential disconnect. You say they follow Part 820, but you did not say if they tailored it.

For example, 820.1(a)(1) says, "If a manufacturer engages in only some operations subject to the requirements in this part, and not in others, that manufacturer need only comply with those requirements applicable to the operations in which it is engaged". If your client doesn't perform installation or servicing, then they don't need to comply.

Similarly, 820.1(a)(3) has a discussion of "where appropriate".

It would be nice if the quality manual identified both the ISO 13485:2016 exclusions and the QSR not applicable and nonimplementation, but it is not a requirement, so could not be an audit conformance. Also recall, that QSR does not require a quality manual.

That changes the situation.

It looks like they have an outsourced process, the requirements of 7.3, so they need to follow 4.1.5 and 7.4. It now sounds as if they have confused exclusion with outsourced process. The exclusion is not correct.

That changes the situation.

It looks like they have an outsourced process, the requirements of 7.3, so they need to follow 4.1.5 and 7.4. It now sounds as if they have confused exclusion with outsourced process. The exclusion is not correct.

That changes the situation.

It looks like they have an outsourced process, the requirements of 7.3, so they need to follow 4.1.5 and 7.4. It now sounds as if they have confused exclusion with outsourced process. The exclusion is not correct.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

When reading FDA's design control regulations in 21 CFR @820.30, it may not be immediately clear that FDA's design control process applies to the design of the device and its manufacturing process.  Here is some supporting background:

• Remember that a preeminent part of the total finished design output is the Device Master Record which embodies, among other things, the manufacturing process specifications, methods, and procedures. The fact that the manufacturing process is officially recognized and defined as part of the design output is probably the purest regulatory evidence showing that FDA's design control process is required to be applied to the design of the device manufacturing process, not just the device. This fundamental is shown for example by FDA's corresponding 21 CFR @820.3 definitions.

• It's also important to remember that FDA's design verification requirement intrinsically demands that each design output (e.g., the manufacturing process specifications, methods, and procedures) is to objectively correlate with a corresponding design input(s).  This is a further example showing how design of the manufacturing process is to be integrated into the design control process.

• Also noteworthy is FDA's design control guidance document reminding us that, "…Design control begins with development and approval of design inputs, and includes the design of a device and the associated manufacturing processes…[T]he development of production processes is a design rather than a manufacturing activity…"

Other examples can also be cited, but hopefully this sheds at least some light on the subject.

Finally, don't forget that this principle is also integrated into ISO 13485, for example where clause 7.3.3(e) therein states, "…[design inputs] shall include…requirements essential for the design and development of the product and processes."

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

When reading FDA's design control regulations in 21 CFR @820.30, it may not be immediately clear that FDA's design control process applies to the design of the device and its manufacturing process.  Here is some supporting background:

• Remember that a preeminent part of the total finished design output is the Device Master Record which embodies, among other things, the manufacturing process specifications, methods, and procedures. The fact that the manufacturing process is officially recognized and defined as part of the design output is probably the purest regulatory evidence showing that FDA's design control process is required to be applied to the design of the device manufacturing process, not just the device. This fundamental is shown for example by FDA's corresponding 21 CFR @820.3 definitions.

• It's also important to remember that FDA's design verification requirement intrinsically demands that each design output (e.g., the manufacturing process specifications, methods, and procedures) is to objectively correlate with a corresponding design input(s).  This is a further example showing how design of the manufacturing process is to be integrated into the design control process.

• Also noteworthy is FDA's design control guidance document reminding us that, "…Design control begins with development and approval of design inputs, and includes the design of a device and the associated manufacturing processes…[T]he development of production processes is a design rather than a manufacturing activity…"

Other examples can also be cited, but hopefully this sheds at least some light on the subject.

Finally, don't forget that this principle is also integrated into ISO 13485, for example where clause 7.3.3(e) therein states, "…[design inputs] shall include…requirements essential for the design and development of the product and processes."

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Another great couple of questions Julie about CMOs and 510(k)s.

We definitely have an interesting puzzle on our hands when grappling with FDA's statements that design control includes the design of a device and the associated manufacturing processes, and that the development of production processes is a design rather than a manufacturing activity.  FDA also gave additional guidance in its Device Advice website guidance where the agency stated, "…all of that [referring to device processing and the manufacturing process] needs to be considered during your design and development…"  Similarly, when Kim Trautman was still with FDA, she stated that, '…we were teaching that design and development covered the product, its processes, its testing and everything – it was a point that you could see from the comments was sometimes not well understood…"  I'm confident she still maintains this position.

Be aware that FDA is intent on enforcing design controls in accordance with certain explanations cited in such guidance.  In fact, a couple years ago a new client came to me whose PMA review had been put on hold, due specifically to insufficient design inputs.  In that case, FDA quoted directly from its guidance document in asserting the agency's terms and requirements for lifting the hold.

Another indication of FDA's position that I've mentioned before to the Forum pertains to 21 CFR 820.70(b) (manufacturing process change control) and the requirement therein to verify or validate such changes.  FDA has reminded us that this needs to be done according to 820.30 design controls and is really just a redundant reiteration of the design control requirement.

A few other parties that have reiterated how design inputs need to include prescription for the development of the manufacturing process are, for example, AdvaMed (in its Points to Consider document) and Vern Geckler in his book covering design controls.

Also of note is that the aforesaid PMA sponsor was in fact a "virtual" firm (a Specification Developer) who outsourced the entire manufacturing process, yet the PMA hold letter nonetheless included citations against the manufacturing process (process validation specifically).  Therefore, take care not to decouple a Specification Developer's ultimate responsibility for the development of the manufacturing process, even when that development is outsourced.

ISO/TC 210 gives similar hints about the relationship between the manufacturing process and the design and development process in its ISO 13485:2016 practical guide where it reiterates the aforementioned FDA concurrent engineering principles, stating that, "…This addition [ISO 13485:2016] highlights the need to consider manufacturability in the design and development process…the manufacturing process should be capable and stable to consistently produce product that is safe and performs as intended…", moreover showing that process design inputs are needed for in-house and outsourced manufacturing alike.

I remember a case a few years ago where, prior to my involvement, a client (also a Specification Developer) launched a new implantable product into the market.  Though implantable, the product had a very "simple" design with an "easy" manufacturing process that was well understood by the expert well known CMO.  With that mindset and an incomplete understanding of the regulatory requirement for including process development in the design control process, the firm launched with full-scale manufacturing without first proving the capability of the manufacturing process.  All of the resulting product, hundreds of thousands of units, turned out to be nonconforming.  This resulted in a very costly and embarrassing market entry.  That could have been avoided with proper manufacturing process design inputs and corresponding verification and validation.  Accordingly, this isn't just a regulatory requirement, it seems to make critical business sense.

Therefore, a key lesson learned is to assure not to end up with orphaned design outputs (e.g., manufacturing process specifications and methods) that can't objectively be linked back to corresponding design inputs, and forward to corresponding design verification and validation.

In my opinion, this actually doesn't need to be a big undertaking, and many organizations are probably already doing much of what is required to meet this requirement.  As an example of how to implement this, consider the most basic manufacturing design input, which is whether the product will be manufactured in-house or by a CMO.  Then consider things like how capable the process (whether in-house or outsourced) needs to be.  For example, some may find it valuable to have a manufacturing design input stating that the process needs to achieve a Cpk of 1.33 or better (by the way, I'm no process capability expert, so don't let me leave you with that impression).  That approach gives more objective credence to the acceptance criteria later written into the process qualification/validation studies.  Another very common example of a manufacturing process design input is the usual specification related to sterile products that many organizations already state in their design inputs, namely that the sterilization process must achieve a specified SAL.

Regarding how the FDA section 510(k) process fits into this equation, it is indeed true that 510(k)s can and do get cleared even if the manufacturing process has yet to be developed.  In fact, I've gotten 510(k) clearances even before the device design efforts are finished.  The reason for this is that there is a unique statutory/regulatory purpose for a section 510(k) Notification.  Namely, that purpose is to show substantial equivalence to another legally marketed device.  In other words, a 510(k) is, at its statutory heart, supposed to be just a comparative effort.  A 510(k) is not intended to prove device safety, efficacy, or full compliance with design controls [though FDA in my opinion pushes that envelope with the Special 510(k) paradigm, and also even in traditional 510(k)s where, again in my opinion, FDA seems often to exceed the boundary of the substantial equivalence concept, delving into requests that are more akin to proofs of safety and effectiveness.  But that pet peeve is another discussion entirely, so I'll get back to the question at hand].  Indeed, certain design outputs, verification, and validation are often needed to justify a 510(k) substantial equivalence claim.  But I recommend that we don't let that muddy the waters between the intent of 21 CFR 820.30 vs. Part 807.  Most, if not all, of the supporting data in a 510(k) are in fact deliverables from the design control process, but not all design control deliverables are needed to support a substantial equivalence claim.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.

Another great couple of questions Julie about CMOs and 510(k)s.

We definitely have an interesting puzzle on our hands when grappling with FDA's statements that design control includes the design of a device and the associated manufacturing processes, and that the development of production processes is a design rather than a manufacturing activity.  FDA also gave additional guidance in its Device Advice website guidance where the agency stated, "…all of that [referring to device processing and the manufacturing process] needs to be considered during your design and development…"  Similarly, when Kim Trautman was still with FDA, she stated that, '…we were teaching that design and development covered the product, its processes, its testing and everything – it was a point that you could see from the comments was sometimes not well understood…"  I'm confident she still maintains this position.

Be aware that FDA is intent on enforcing design controls in accordance with certain explanations cited in such guidance.  In fact, a couple years ago a new client came to me whose PMA review had been put on hold, due specifically to insufficient design inputs.  In that case, FDA quoted directly from its guidance document in asserting the agency's terms and requirements for lifting the hold.

Another indication of FDA's position that I've mentioned before to the Forum pertains to 21 CFR 820.70(b) (manufacturing process change control) and the requirement therein to verify or validate such changes.  FDA has reminded us that this needs to be done according to 820.30 design controls and is really just a redundant reiteration of the design control requirement.

A few other parties that have reiterated how design inputs need to include prescription for the development of the manufacturing process are, for example, AdvaMed (in its Points to Consider document) and Vern Geckler in his book covering design controls.

Also of note is that the aforesaid PMA sponsor was in fact a "virtual" firm (a Specification Developer) who outsourced the entire manufacturing process, yet the PMA hold letter nonetheless included citations against the manufacturing process (process validation specifically).  Therefore, take care not to decouple a Specification Developer's ultimate responsibility for the development of the manufacturing process, even when that development is outsourced.

ISO/TC 210 gives similar hints about the relationship between the manufacturing process and the design and development process in its ISO 13485:2016 practical guide where it reiterates the aforementioned FDA concurrent engineering principles, stating that, "…This addition [ISO 13485:2016] highlights the need to consider manufacturability in the design and development process…the manufacturing process should be capable and stable to consistently produce product that is safe and performs as intended…", moreover showing that process design inputs are needed for in-house and outsourced manufacturing alike.

I remember a case a few years ago where, prior to my involvement, a client (also a Specification Developer) launched a new implantable product into the market.  Though implantable, the product had a very "simple" design with an "easy" manufacturing process that was well understood by the expert well known CMO.  With that mindset and an incomplete understanding of the regulatory requirement for including process development in the design control process, the firm launched with full-scale manufacturing without first proving the capability of the manufacturing process.  All of the resulting product, hundreds of thousands of units, turned out to be nonconforming.  This resulted in a very costly and embarrassing market entry.  That could have been avoided with proper manufacturing process design inputs and corresponding verification and validation.  Accordingly, this isn't just a regulatory requirement, it seems to make critical business sense.

Therefore, a key lesson learned is to assure not to end up with orphaned design outputs (e.g., manufacturing process specifications and methods) that can't objectively be linked back to corresponding design inputs, and forward to corresponding design verification and validation.

In my opinion, this actually doesn't need to be a big undertaking, and many organizations are probably already doing much of what is required to meet this requirement.  As an example of how to implement this, consider the most basic manufacturing design input, which is whether the product will be manufactured in-house or by a CMO.  Then consider things like how capable the process (whether in-house or outsourced) needs to be.  For example, some may find it valuable to have a manufacturing design input stating that the process needs to achieve a Cpk of 1.33 or better (by the way, I'm no process capability expert, so don't let me leave you with that impression).  That approach gives more objective credence to the acceptance criteria later written into the process qualification/validation studies.  Another very common example of a manufacturing process design input is the usual specification related to sterile products that many organizations already state in their design inputs, namely that the sterilization process must achieve a specified SAL.

Regarding how the FDA section 510(k) process fits into this equation, it is indeed true that 510(k)s can and do get cleared even if the manufacturing process has yet to be developed.  In fact, I've gotten 510(k) clearances even before the device design efforts are finished.  The reason for this is that there is a unique statutory/regulatory purpose for a section 510(k) Notification.  Namely, that purpose is to show substantial equivalence to another legally marketed device.  In other words, a 510(k) is, at its statutory heart, supposed to be just a comparative effort.  A 510(k) is not intended to prove device safety, efficacy, or full compliance with design controls [though FDA in my opinion pushes that envelope with the Special 510(k) paradigm, and also even in traditional 510(k)s where, again in my opinion, FDA seems often to exceed the boundary of the substantial equivalence concept, delving into requests that are more akin to proofs of safety and effectiveness.  But that pet peeve is another discussion entirely, so I'll get back to the question at hand].  Indeed, certain design outputs, verification, and validation are often needed to justify a 510(k) substantial equivalence claim.  But I recommend that we don't let that muddy the waters between the intent of 21 CFR 820.30 vs. Part 807.  Most, if not all, of the supporting data in a 510(k) are in fact deliverables from the design control process, but not all design control deliverables are needed to support a substantial equivalence claim.

Looks to me like the discussion got right on target once the necessary background information was provided.  I've often found as a Forum respondent that when we as posters ask for more details before responding, then oftentimes more information is not forthcoming, and it just delays getting needed information to the requester.  So I've generally made it a practice to do the best I can to respond with the information provided, yet by explaining the presumptions (or inferences as Dan likes to say) on which my response is contingent.

Anyhow, a few more quick points that reinforce the general consensus reached here:

1. ISO 13485 'Design and development' and FDA design controls fundamentally and specifically demand that the responsible organization not only design the product, but also the manufacturing process.  Therefore, design inputs, outputs, verification, validation, etc., are required for both the product and the process.

2. If FDA were to inspect this firm (i.e., the responsible organization), the agency would demand that the firm produce a full Design History File for the subject device.  Likewise, a proper ISO auditor would also demand the same.  Ultimately this means that if the responsible organization's DHF is currently lacking, then it would receive a corresponding FDA 483 Observation and/or ISO audit Nonconformity (perhaps even categorized as a Major depending on the extent of the deficiency). Therefore, an internal audit should categorize these findings accordingly.

3.  I believe that the organization could support an argument that the bulk of the written design control process operating procedures for the device are to be established by the contract designer.  In this setup, the responsible organization's written design control procedures could be commensurately limited in scope.  Specifically, detailed operating procedures for the various product design phases could be left to the quality management system of the contract designer, with only basic explanation of this approach being stated in the responsible organization's quality management system.  The viability of this arrangement would be contingent on the responsible organization assuring, under ISO 13485 clause 4.1.5 and 21 CFR 820.50, that proper design control operating procedures are in place at the contract designer.  As part of this, the responsible organization's design control operating procedure would need to carefully explain that the responsible organization would be appropriately involved with the design effort when the contract designer executes the project.  For example (not exhaustive), the responsible organization would need to be deeply involved with the derivation of the design plan and the design inputs; yet those steps could be moderated/orchestrated/executed under the covering of the contract designer's quality management system with copies of the deliverables from these steps (i.e., the final approved design plan and design inputs) needing to be filed in the responsible organization's DHF.  Note that this scenario is not a clear candidate for ISO 13485 clause 1 "non-application" of design controls [21 CFR 820.1(a)] because the responsible organization described in this scenario would in my opinion still need to have corresponding design control procedures in place to be sure each party's responsibilities and the related logistics are clearly established.

4. Finally, as other respondents have stated, ISO 13485 clause 1 "exclusion" is not applicable in any event unless there is an applicable regulatory exclusion such as the 21 CFR 820.30(a) exclusion for certain FDA class I devices.