The short answer is: it’s complicated.
Design processes can be standardized, but workflow can change based on the project. A Class III medical device requires more evidence of reviewing design-related risks and subsequent risk controls than a Class I device. Connected devices can require reviews that ensure the proper implementation of cybersecurity in each stage of software design.
Whatever the project is, there must be a formal design review process in place, as part of the design controls mandated by the FDA. All of this must be documented in the design history file (DHF) for FDA reviewers. They do cite organizations on failure to establish, adhere to, or document design review processes.
However, because workflow can be fluid, what happens when teams discuss product design outside of the formal review setting? Is it necessary to document ad hoc design reviews in the DHF?
FDA does provide some clarification on the issue. In Design Control Guidance For Medical Device Manufacturers, they offer this take on the ad hoc design review:
Developers may conduct routine or ad hoc meetings to discuss an issue, coordinate activities, or assess development progress. Decisions from such meetings may not require formal documentation; however, if a significant issue is resolved, this should be documented. If the outcome results in change to an approved design document, then applicable change control procedures should be followed…
While this gives greater perspective into what FDA is looking for, the wording is still vague; “significant issue(s)” are not defined in any meaningful way within the guidance. Neither are the “changes” to an approved design document.
Given this, there are three questions are worth considering when an ad hoc review occurs:
1. Is the review addressing risk(s)?
FDA wants medical devices, pharmaceuticals, and combination products developed with inherent “safety by design.” Reviewers expect that product teams control and mitigate as much risk out of the device during the design process as possible. Any residual risks must have risk control procedures in place prior to any sort of approval.
Because FDA puts such emphasis on device safety, your team should be cognizant during an ad hoc design review if it addresses design-related risks or risk-related design features. Any decisions made and implemented, following best practices, are documented. This provides more evidence that your team approaches device design with safety in mind and properly assesses device features for risk.
2. How critical is the design aspect to device functionality?
Ideally, major design reviews and subsequent changes happen during and as a result of the formalized review process. However, influencing factors could push the team to skip a formal review in favor of accelerating design development.
If this is the case, teams need to keep in mind what the design aspect they’re reviewing is, and how critical it is to the overall design. If, for example, an ad hoc review results in changing the circumference of a syringe plunger, that impacts the rest of the design entirely. Something that major should absolutely be documented, regardless of what setting it happens in. FDA needs to see that such major changes aren’t haphazardly decided and devoid of subsequent risk evaluation.
3. Is there a negative impact to not documenting the review?
If an ad hoc design review is not documented, will any design changes that occur complicate the DHF? For example, if a design change happens from Requirement A to Requirement B as a result of a quick review and is not justified in the DHF, it could confuse reviewers. This is important to consider when you account for how large a DHF can be for a single submission. Precision and clarity within the file makes the review process smoother and easier for FDA, as they are parsing through pages and pages of design documents.
The question can also apply to the design process itself. When design reviews happen, teams identify tasks to assess the results and resolve any issues found. Assignment of tasks is often documented within the design review, helping keep team members accountable. If an ad hoc review occurs, a team member may overlook some of their delegated responsibilities if not documented for reference. Likewise, managers can lose track of what has been delegated, leading to a more chaotic design process. If there is a worry these things could occur, then product teams should take the safe route and make sure the meeting is documented.
There’s no necessarily right or wrong answer when it comes to addressing whether or not to document ad hoc design reviews. These three questions are worth considering in that calculation, but are only that: considerations. Best practice may be, regardless of how brief the meeting is, to document it. “If it’s not documented, it didn’t happen” is a common credo in the product development world.
How design reviews are handled are ultimately up to each organization and product team. But keeping in mind risk, design aspect criticality, and potential impacts can help teams make better decisions about how to handle ad hoc design reviews.
Interested in learning how Cognition’s Cockpit Platform can empower your organization’s design review process? Download our Design Controls Template paper to learn more, or request a Cockpit demonstration.
About the Author
Nick Schofield is a content creator for Cognition Corporation. A graduate of the University of Massachusetts Lowell, he has written for newspapers, the IT industry, and cybersecurity firms. In his spare time, he is writing, hanging out with his girlfriend and his cats, or geeking out over craft beer. He can be reached at firstname.lastname@example.org.