Key Takeaways 🔗
- FDA guidance emphasizes a risk-based approach, focusing on safety, effectiveness, and thorough documentation.
- Software changes, especially new features, may trigger 510(k) submissions, requiring clear justification.
- Comprehensive documentation is crucial for compliance, even if changes don’t require a 510(k) submission.
- Special 510(k) submissions offer faster FDA review within 30 days with less documentation.
- Collaboration between engineering and regulatory teams is key to reducing uncertainty in FDA submissions.
Resources 🔗
- Deciding When to Submit a 510(k) for a Change to an Existing Device
- Deciding When to Submit a 510(k) for a Software Change to an Existing Device
Transcript 🔗
Navigating FDA Device Changes and 510(k) Submissions: A Risk-Based Approach 🔗
Mary Vater: Okay. So, the purpose of today's talk is to go over device changes, planned changes, and the regulatory implications associated with them, as well as how to use FDA guidance documents to help make those decisions.
The two main guidance documents we're going to discuss are: first, deciding when to submit a 510(k) for a change to an existing device, which applies to both hardware and software devices. Second, for devices that include software or are Software as a Medical Device (SaMD), there's another guidance document that applies—deciding when to submit a 510(k) for a software change to an existing device.
If your device involves software, both guidance documents apply in all cases. If it does not involve software, only the general guidance applies. Today, we’re focusing on the two primary uses of these guidance documents, starting with what most people typically think of: a post-market evaluation, or "letter to file," as it's commonly called.
This refers to your change control documentation, which demonstrates that you followed the FDA guidance evaluation process to determine whether a new 510(k) submission is necessary based on the changes you’re making after your product has already received clearance and is on the market.
That’s essentially the original intended scope of the guidance documents, and it’s what is expected to be documented when changes are made. Some people may be unsure about what a "letter to file" actually is—whether it’s something you send to the FDA or not—but it’s simply a letter that goes into the design history file, which is the file we're referencing here.
This is internal documentation of the process you've gone through for the change evaluation. It's not something you send to the FDA; rather, it typically stays with your change record within your internal quality system.
Another aspect we’ll discuss is how to use these guidance documents for pre-market strategy. This allows you to proactively evaluate anticipated design changes. For example, if a company is developing a device with multiple possible functionalities to be rolled out over several releases, you can map out a timeline and assess which of these changes would require a new 510(k) submission. This helps you plan your broader regulatory strategy for the device.
Another strategic use is to evaluate which features to implement before the original pre-market submission. You can assess which changes would definitely trigger a new submission and which ones could be added later through a "letter to file." This helps prioritize changes that may require a new review, allowing you to postpone others that wouldn't trigger a submission.
Often, we see clients wanting to include certain features in their software, but the development required may delay the submission. By using this strategy, you might decide to delay the development of certain features in order to submit your 510(k) sooner.
We’ll explore both of these approaches in more detail. The key principle behind both guidance documents is a risk-based evaluation, focusing on the impact of the changes on the device's functionality and safety.
The first key principle is the intent to significantly affect safety or effectiveness. When evaluating and documenting your changes, consider the purpose of each change. Are you altering the functionality? Are you significantly improving it? If so, these changes may trigger the need for a new 510(k) submission.
With that in mind, you should always conduct a risk-based assessment for any changes. This is crucial because even changes not intended to significantly impact safety or effectiveness could still significantly affect the safety, performance, or other aspects of the software or device, potentially triggering a new 510(k).
Manufacturers should conduct a thorough risk-based assessment using FDA guidelines to evaluate each change. Both guidance documents provide extensive advice on what is expected for such risk assessments. A good practice is to take your risk analysis and identify which risks identified in the analysis apply to the changes you are making, or which could be impacted by these changes. Reference these risk IDs in your evaluation and assessment to base your decision.
And then also, If there are new risks or significant changes to the risk profile or functionality of the device, you must conduct the necessary Verification and Validation (V&V) activities associated with evaluating that change. This applies regardless of whether it results in a 510(K) submission or a letter to file. A crucial aspect of the letters to file is ensuring that the change has been adequately tested to meet your requirements without introducing unforeseen risks.
Lastly, another principle the guidance focuses on is comparative analysis. This involves comparing the change, or the cumulative changes over time, to the cleared version of the device. The guidance provides specifics on evaluating these cumulative changes. You may have heard of the term "catch-up 510(k)," which refers to situations where individually, the changes might not trigger a new regulatory submission. However, cumulatively, if enough changes are made, you need to consider if the device has deviated significantly from the originally cleared device to warrant a new submission to update the FDA's file on the device.
Oftentimes, companies can proactively handle this, but it might also arise during an FDA inspection. If the FDA reviews your design history file, letters to file, and change notes, they might suggest a catch-up submission if the cumulative changes are substantial. While not necessarily the core focus of these guidance, it's an important consideration if you plan to make many small changes to your device.
We've already touched on this, but essentially, how to use the guidance documents and what the FDA expects from a compliance perspective for your post-market change evaluation includes identifying the purpose and impact of the change, conducting a risk-based assessment, and utilizing the different flowcharts provided in the guidance. These flowcharts offer a step-by-step evaluation process for assessing changes. At every decision point in the flowchart, you should document your rationale behind the decisions that are guiding you toward a letter to file or a new regulatory submission.
The documentation of these activities forms a letter to file from a premarket strategy perspective. Of course, this is not about active changes to a marketed device, so the FDA is not as concerned with your proactive documentation, but it's still beneficial to go through the same processes that you would post-market. This includes identifying the purpose of the change, conducting the same risk assessment, applying the flowcharts, doing the step-by-step evaluation, and making a proactive determination as to whether a change would in the future require a new 510(k).
Once you've determined the necessary changes based on your anticipated or desired modifications, you may consider triaging the development activity to prioritize the implementation of changes that might trigger a new 510(k) over those that could be added as a letter to file.
Regarding post-market change control records, they are required once you start marketing your device. However, for premarket strategy, it's also beneficial as part of your regulatory strategy documentation to document the same types of evaluation.
You might have heard of a PCCP or be wondering how this relates to a Predictive Change Control Plan for medical devices. A PCCP is a plan that you can submit as part of your regulatory submission, which essentially pre-clears you to make changes after you receive clearance. The main difference between having a PCCP and just making regular changes documented as a letter to file comes down to the flowcharts and the decision as to whether a new filing case is going to be required. If you're looking at this proactively, evaluating a feature, and going through the flowcharts leads you to documentation only, that would not be subject to a PCCP.
The FDA wouldn't allow you to submit a PCCP for something that would otherwise just be documented as a letter to file. If your proactive evaluation and decision tree lead you to determine that a new 510(k) is required, those are the features or functions you could consider including in a PCCP.
Similar to how we discussed evaluating whether development activities should be prioritized based on what will require a new 510(k), if you have any changes that would trigger a 510(k) and you know you won't be able to implement them in time, then that might be a good opportunity for a PCCP.
There are essentially three categories that your planned changes or features could fall into. Following the FDA guidance for evaluating these changes and referencing the PCCP guidance will help you strategize the best route for planning your development activities, aligning with your timeline and marketing goals.
That’s an overview of the change control process and guidance at a high level. I also wanted to delve a bit deeper into some of the flowcharts and show you what those decision trees look like. This way, you can be aware of the types of questions you should be asking when faced with decisions about whether to implement changes now or later, or how significant the change is from a regulatory perspective.
As I mentioned, the FDA has useful flowcharts that you'll use when documenting your letter to file. However, don't just focus on the flowcharts. For each decision point, there is a more detailed description that includes important considerations for answering the question. If you're unsure how to answer a decision point in the flowcharts, I recommend referring back to the content in the accompanying paragraphs in the guidance for better insight.
Additionally, at the bottom of all these guidances, there are numerous examples. You can skim through these examples to see if one is similar to the change you're considering. The examples detail the change and the corresponding decision, which can be very helpful. Sometimes, you'll find a perfect example that directly represents the change you're contemplating.
I wanted to frame the guidance for you so that you understand the importance of going beyond the flowcharts, even though they are the basis for your decision documentation. The first flowchart comes from the general guidance and serves as a main flowchart pointing you to other relevant flowcharts for label changes, technology or performance changes, and material changes. These are the three main categories in the original guidance. Software, on the other hand, is addressed in an entirely separate guidance document that does not necessarily flow from these charts but is referenced as applicable.
We don’t need to get into the specifics of all these, but I wanted to show you an example.
So, I apologize for the small text, but the format on the left is typically how I document in a letter to file. I write out the decision tree in text and then answer it, providing justification or rationale for each decision point within the letter to file. Specifically for labeling, this doesn't just relate to the software label or the physical label on your product. It also pertains to changes in your indications for use and how you describe your product in marketing claims. If any changes you make would alter your intended use or add a function to it, then you would certainly need to consult this flowchart.
If you are working on a software device and think, "Oh, I'll just follow the software guidance," you may be overlooking crucial change evaluations. Ensure that your documentation process captures the necessary details from both guidance documents.
For labeling, it's important to note changes like going from prescription use to over-the-counter. For example, if a device normally used in a doctor's office is now intended for home use, that would trigger a need for a new 510(k). Also, if the device is going from single-use to reusable, that introduces a slew of new risks related to reprocessing, cleanliness, and restabilization, necessitating a new 510(k). If you’re merely clarifying how it's used to enhance understanding while keeping the same intent, there's some flexibility. However, adding new functions or making your indications more specific, such as for a particular disease, would likely trigger a new 510(k).
The next flowchart is for technology and performance. This also pertains to software and may not always be covered by the software guidance because it relates to the operating principles of the system and the core technological characteristics of how your device achieves its intended use. Some questions might not apply and can be skipped, but others, like B2, often trigger a new 510(k). The methods and protocols used to validate changes are also reviewed in this flowchart.
I'm going to move quickly through this because just a high-level overview isn't very helpful. What you need to do is work through the flowcharts for your specific change, delve into the paragraphs, and detail the guidance to help make and document these decisions. But I just wanted to outline that for you.
Materials changes are pretty self-explanatory and won't apply to software changes. This flowchart is from the software change guidance specifically, separate from the other flowcharts. It starts with evaluating whether the change is solely for cybersecurity. If that is the only reason for the change and the only impact, then it does not require a new 510(k). If the change merely returns the system to the specifications of a more recently cleared device, that also doesn't require a new 510(k). Then, you delve deeper into whether the change introduces or modifies a risk that could result in significant harm not effectively mitigated in the most recently cleared device.
It's important to note the term "significant harm" because sometimes you will encounter changes that, although modifying your risk assessment, are not significant enough to lead to significant harm. In such cases, you can justify why mere documentation is sufficient. This is also why it's crucial to trace back to your actual risk management documentation where the severity of risks is evaluated. If you can link to these risks and show they are of lower severity, then you have a complete paper trail to justify your decisions at this point.
Next, consider whether the change could significantly affect the clinical functionality or performance specifications directly associated with the intended use of the device. This consideration is crucial and relates to PCCPs. For example, algorithm changes that significantly affect clinical functionality require a clear definition within the context of your device and its intended use. Often, if a change necessitates new clinical data or a new clinical study, it will likely require a new 510(K)—a good rule of thumb when evaluating major changes within your intended use.
Beyond this, the FDA is not overly prescriptive but outlines additional factors that can influence the decision to file. These considerations are somewhat subjective, including the company's assessment of the impact of changes related to infrastructure, architecture, core algorithm adjustments that do or do not directly contribute to the intended use, clarification of requirements, any cosmetic changes or user interface alterations, and any re-engineering or refactoring. You must document whether any of these factors apply and evaluate their impact as part of your letter and file for software changes.
This was a high-level overview to ensure everyone is aware of the guidance documents, how to use them, and how to base your decisions on them. With that, the presentation slides conclude, and we can discuss specific examples if desired.
Reece, did you want to discuss the topic you had in mind?
Key Decision Points and Risks in Implementing Software Changes: Insights from Real-World Experiences with DICOM and PET CT Integration 🔗
Reece Steven: Sure. Thanks, Mary. This has been really helpful to walk through the flowcharts. I worked with them a long time ago and had forgotten most of the details, so this has been a great refresher. The example I recently encountered involves a client developing a tool that includes a DICOM viewer. They want to perform measurements on findings from CT and MR, and they're considering expanding their use case to include measurements on PET CT Fusion. The reason for this is it enables certain clinical assessments that are currently done on the device but require manual input of information that would typically be automatically measured from PET CT. The client has two decisions to make. First, they want to replace the foundational technologies of the DICOM Compute itself. It's currently written in one library, and we need to re-implement it using a different foundational technology to support the rendering of PET CT fusion. This would be a technological change that could be implemented without enabling PET support, essentially replacing a software component without any user-facing impact. The second decision is about activating support for PET CT and supporting the measurement of standard uptake values as an input to response criteria.
So, these two decisions are becoming key decision points in figuring out when to stage and implement these features.
Mary Vater: Now, I guess I'll open the floor to everyone else. Does anybody have any reactions or thoughts? Sure.
George Hattub: Based on my experience, I usually tell clients that they are allowed to make "under-the-hood" adjustments using the guidance documents, as Mary explained. However, often the thresho ld is when you add a feature, which is something that doesn't currently exist, and perhaps becomes apparent in the GUI. I speak from two experiences: one where a client added a feature, filed a letter to the file, and several years later, during a 510(K) submission, a reviewer questioned a feature we thought was covered. It led to a tense two weeks as we supplied information, culminating in a catch-up 510(K) submission, which could have ended unfavorably.
The notion that you'll never have to submit a 510(K) again is unrealistic. In a second instance, competitors or others submitted new 510(K)s, making their own comparisons and saying, "Our predicate has this feature." If the FDA reviews it and doesn't recall clearing that feature, it could trigger an issue.
There's also a case (not naming any names) where a company was forced to recall their product, a software as a medical device, because they added a feature that caught the FDA's attention.
Furthermore, some of the more advanced companies have procedures detailing the thresholds for letters of file. They might specify that changes from version two to version three are special 510(K)s, whereas changes from version 3.1 to 3.2, if they align with the guidance documents Mary mentioned, then those prevail.
That's all I have to say about that. Did my explanation help you?
Navigating Regulatory Risk: Weighing New Features, Operating Principles, and the 510(K) Submission in Software for Medical Devices 🔗
Reece Steven: Absolutely. Yeah. That's very helpful to know. I hadn't considered the possibility of another company using your device as a predicate and the FDA not recognizing it. But yes, that makes a lot of sense.
Marry Vater: So, George, you touched on a lot of important points, one of which is when you're implementing a new feature. It sounds like this involves new underlying technology and a new function that the software will perform, which is akin to an example of a template for a letter to file where you can document the evaluation of these changes. Just to include background information and description, the reason for the change, risk management, and then proceeding to the flowchart evaluation.
Looking at the first of these, it somewhat depends on how the indications for use are written. If you're adding new imaging modalities to specific indications that already include other modalities, then that might trigger this flowchart. If the indications aren't written specifically, then the answers to these questions might be no, and the labeling flowchart might not lead to a new 510(K). However, you'd then need to consider the technology, engineering, and performance changes. I would suggest that possibly this involves a new operating principle if it's taking a new imaging modality and applying a new analysis method to determine a new output. I would have to think about how to justify this if I believe it's not a novel operating principle relative to what's already been done.
So, any thoughts on how you would consider this?
Reece Stevens: I mean, in this particular context, thinking about whether the intended use of this device was specific about the kinds of measurements that were being performed, I think that it was left somewhat nebulous. I think it might have mentioned something other than quantitative measurements of some kind. In that sense, adding the standard uptake value: would that qualify as a new operating principle, or is it more an extension of what was already listed? I feel like if you're considering that, you're getting a bit into the weeds, though, and you could probably argue it either way.
Yeah, and it makes sense that yes,
Marry Vater: this is where it gets tricky because sometimes it does come down to how you can justify it. Often, companies are able to justify why the answer is no to these, why it is a letter to file, and you just have to be confident and able to defend yourself when the FDA comes to inspect and argues the other side.
It's certainly like a risk-based decision, a regulatory risk that companies can choose to make. If they feel there is a strong argument for a letter to file, then that's a choice some companies can make. And, of course, the risk, if you're wrong, is that the FDA, when they come to inspect you or become aware through other means of these changes, if they end up disagreeing with you, then the best-case scenario is they would tell you to submit a 510(K) but would not require you to stop marketing your product. But the worst-case scenario would be they would say you need to remove that functionality or you need to stop marketing your product until you receive clearance for those functions they were arguing about. Luckily, in the case of software as a medical device, it's a lot easier most times for companies to recall their software and revert it to an offering that doesn't include the problematic function. So for software companies, maybe that is a pretty low regulatory risk to take that chance.
So yeah, it definitely gets tricky when you could argue something both ways, but that's where the risk-based decision and the business risks that companies are willing to take might drive some of that.
Balancing Client Pressure and Regulatory Compliance: The Challenges of Letters to File in FDA Oversight 🔗
George Hattub: George, I think also when you're faced with these types of situations, sometimes you get cornered and taken by surprise, and the client might want you to make the decision. Some of the arguments I see are, "the ends justify the means." "We can't afford another 510(K); we have to get this out right away." So I always look at that. You have to help the client reach the right decision. First of all, what the FDA enforces does not come before safety. So even though something may be safe, the FDA oftentimes is the arbitrator outside of the risk analysis.
The other thing, too, is that to help the client make the decision, I always tell them the next person that's going to read your letter to the file will be either an FDA inspector, which is different from the FDA that reviews 510(K)s. The people at the FDA who review 510(K)s are scientific-type people with PhDs, whereas the investigators are compliance persons. And so that person is going to look at it differently and they're going to challenge you. And usually, if you make a modification because of a complaint, then they're going to look at it as part of your CAPA system, and you know, did you capture this as a complaint? So sometimes when a letter to the file is being proposed, you have to get all the facts. Sometimes it might be that we can't afford to submit to the FDA. And if they're going to live with that decision, you might have to explain the circumstances. In other words, the next person to read this will be an FDA inspector. Or it could also be the person buying your company. A lot of times regulatory professionals have a lot of influence on those types of decisions, and it's not that they will buy your company, but they could use that as a negotiating tool saying, "Oh, they took some risks here, so we're going to have to do that catch-up 510(K) that Mary mentioned." And then the other person that could read your file is a product liability lawyer. Or in the case where you thought it wasn't a problem and it turns out to be a problem, or something unrelated to your product, they're going to use it against you that you guys didn't let the FDA know about it.
Well, I'm not discouraging letters to file because oftentimes you'll find a situation where the regulatory people in a company will be the most conservative ones because they have to defend it. And so will some regulatory professionals. I'll say it's always a filing to the FDA. When you look at the facts, you say, no, this is a letter to file. You know, it's under the hood. It's not a feature. So those are just some of the things I've run into.
Navigating Software Changes and Risk Assessment: Key Considerations for FDA Submissions 🔗
Marry Vatter: Yeah, that's an interesting point, that it might not just be the FDA who ends up needing to review these files; it might be other stakeholders as well.
So keep that in mind. Also, I just wanted to jump down to the software changes, flowchart, and decision tree to see if there's anything else that would be triggered by the change that we're discussing. I think the topic of new risks might arise if you're providing a new piece of clinical information. The FDA is going to be interested in what that is used for. Sometimes, for devices that have general indications or general measurement indications, you don't have to get into the clinical specifics of how that information is used. However, you might need to consider that from a risk-based perspective in your letter to file if you're adding a new functionality that could be used for possibly a higher risk intended use than what was originally a function of the device.
That’s something I would want to be very confident about, or that I could anticipate some two sides to that conversation. The last question on the flowchart is: does it affect the clinical functionality or performance specification?
So, those are probably the questions I would focus on and need to dig deeper into, conducting a thorough risk assessment to ensure that I can confidently defend those points if I'm deciding whether a 510(k) is required. In this case, I think things may be adding up to where adding that new function would likely require a new submission. But of course, it depends on all the details—how you're marketing the product, what the intended use is—so there is flexibility in that.
Thanks for that example. And then lastly, of course, there are other things to consider that we talked about, such as an algorithm change if it's doing something new. But it may or may not.
Just all the things you need to think about when making those decisions. I have a little quiz if we want to test your knowledge. I have examples from the FDA guidance, but I don't want to jump to that if we have other questions or examples to go through.
Handling Multiple Changes in 510(k) Submissions: Challenges and Documentation Considerations 🔗
Joshua Tzucker: I have a quick question. I might be misreading the guidance here, but one of the items talks about if you end up having to make a change, or it seems like you should submit a 510(k). It sounds like they're saying if you have changes that trigger the 510(k) but you also have changes independent of that which would just follow the normal documentation path, you combine both in the new 510(k). But then it said something interesting—that it sounds like you could continue making those changes immediately and not the triggering changes.
I was just curious if that sometimes gets really confusing and messy. Does that happen in practice, or what does that look like?
Marry Vatter: Yeah, all the time, actually. You can go years with letters of file, and then one thing will trigger the 510(k). But your documentation needs to reflect all the changes that have been made up to that point in time. It doesn't mean that you were illegally marketing it during that time, but the FDA is interested in all the changes that have added up to where it is now that they're reviewing.
There may be other things, like George mentioned—maybe some other changes that had happened along the way in his example that probably should have triggered a new 510(k) but managed to slip under the radar for a long time. Even if all those changes are documentation-only and wouldn't normally require a letter to file, everything has to be described in detail in the new submission.
That's a good question because that does happen a lot, and a lot of times clients are surprised at how much effort it is, because it is a lot sometimes.
Leveraging Special 510(k) for Faster FDA Review: Timelines, Strategies, and Considerations 🔗
George Hattub: I think also about the special 510(k). I'm not sure how much everyone is aware of it, but most of the time we're preparing traditional 510(k)s, and those are the ones that take over six to nine months. The FDA has special 510(k)s that were made specifically for situations like this. When you submit a special 510(k), they have the highest priority with the FDA.
A special 510(k) means the FDA has to drop what they are doing and focus on your submission because they have only 30 days to make a decision. The FDA works very efficiently, according to internal clocks that they have to report to Congress. In 30 days, they either have to allow the change or give you a hold.
Recently, I had a situation with a client where we submitted a special 510(k), and it got put on hold. We automatically assumed it was now a traditional submission, and we took a little time because we had to meet with the FDA. Once we provided that additional information, the clock—which you could see on the customer collaboration portal—started for another 30 days. So if you add it up, that's 60 days, not counting the time that it was on hold while we were gathering information.
We were able to get the 510(k) cleared as special, but they still had issues, and we still beat the traditional timeline. So sometimes that helps; the course of a 510(k) can get enormous. Sometimes they don't have the budget for it; whether it's special or traditional, it's still the same price.
Mary Vatter: That's a good point to bring up to George because even as you're doing this analysis and evaluating your changes, even if it does require a 510(k), if you're modifying your own device, it likely may be a special 510(k). You're not looking at the traditional timeline of 90 days, nor at all of the documentation that is normally required for a traditional 510(k)—it's a smaller scope of work.
So, I would definitely point you to the special 510(k) guidance document for further reading so that you can understand in what circumstances it is not applicable, as that might impact your strategy as well. If you think, "Well, I'm going to submit this, and then during the 90 days that they're reviewing it, I'm going to be working on developing the next version. As soon as it's cleared, I'm going to submit a special," then you're really only delaying things by about 30 days or however long the special review takes. That might be something worth considering. I would recommend you read that guidance as well.
Navigating Regulatory Challenges: Balancing Conservatism and Business Needs in Medical Device Companies
J. David Giese: I just wanted to add a couple of comments about what George mentioned regarding the regulatory team often being the most conservative group in many companies. That's a pretty common complaint I hear on sales calls. Companies often come to us saying, "We were working with this regulatory consultant, and they're telling us we have to do new 510(k)s for every change," which feels really burdensome.
In general, sometimes companies are just fishing around for a "yes" person to agree with whatever they want to do. However, I also think there's some validity to the concern that regulatory personnel—especially those who have worked at very large companies—may be accustomed to an environment where the company's business goals are very risk-averse. They then translate that mindset over to smaller companies that might be more willing to operate closer to the line or the blurriness in the regulations.
When you read the regulations, particularly in the very first few pages of the guidance, it really all hinges on the word "significant"—what does "significant" mean? The letter of the law is one thing, while the guidance provides additional clarity from the FDA. Ultimately, it comes down to determining what we think is significant in a variety of specific situations. But you could always argue, "Oh, I don't think this is actually significant."
George Hattub: There's a whole psychology to letters of file; we could probably write a book on it—discussing the stakeholders involved. In larger companies, their thought processes often trickle down. A lot of times in larger companies, they actually have FDA personnel who have made the switch to industry, so smaller companies often take their lead from that as well.
But you are allowed to make changes. The biggest thing is whether or not you can defend them, as Mary mentioned. The pointed defense may happen two years from when that decision was made, and sometimes people move on. This is another phenomenon where if you're sitting across from the FDA defending someone else's decision, you may not necessarily agree with it.
Once again, I always emphasize the need to be rational and ask the right questions. Another example is when I was involved in a situation where we asked whether something was a customer complaint. Some people said yes, and some said no. It's essential to clarify—were we talking about a complaint? If it's a complaint, it has to be in your CAPA system, and you know the FDA is likely to scrutinize that file, especially with letters of file. If it's an unmet expectation or an afterthought, that's a bit different.
There's a whole psychology here; we could probably make a lot of money right now with an ebook on this topic.
Mary Vatter: I think it's beneficial to get different eyes on your letters of file and different perspectives. It's something I often suggest companies do during their internal audits—have someone unfamiliar with the letters of file review them. They might identify different risks or concerns that an FDA inspector might see as well. Just a thought.
Yujan Shrestha: When there's more uncertainty about something, what tends to happen is you become more conservative about that issue, right? For example, if we have a statement of work for a software engineering project and there's a large uncertainty, that estimate will probably end up being higher than if we had more information. If we can narrow that gap, we can be more confident in our estimates.
I think it's similar with this conversation. What sets us apart as a team is that we can reduce that uncertainty. With our engineering background, regulatory expertise, and some clinical insight, whenever we encounter a problem, we can clarify whether something is notifiable or not. If there's a lot of uncertainty, that often breeds fear, leading to a conservative stance.
If you're well-informed about the device and understand why the FDA is asking for certain things, you can anticipate their concerns. The FDA doesn't want to see changes that are insignificant; they want to focus their efforts on changes that actually matter. However, if you're uncertain and view it as a big unknown, you'll likely be much more conservative than necessary.
The Importance of Collaboration: Bridging Engineering and Regulatory Teams for Effective Decision-Making
J. David Giese: I think it's a great point, and it highlights the value of having engineering and regulatory teams work together. If the regulatory team doesn't fully understand the engineering processes—how software is developed, how algorithms are trained, and all those different aspects—they will naturally be more cautious because there are many unknowns for them.
I'm sorry to jump in; I thought you were done, but …
Yujan Shrestha: That point has come up several times. Clients have come to us questioning whether simply retraining the algorithm would require a special or full 510(k). If you read the guidance by the letter, you could arrive at that conclusion.
But if you read the examples and then put an engineer's eye on those examples, you can understand what the FDA really meant. Just to retrain the algorithm is not necessarily grounds for resubmitting a 510(k). Even if you read the letter, there is a more conservative path to take in the face of uncertainty that leads to the conclusion that this is a 510(k) requirement when, in practice, it’s not. The only way to navigate this effectively is to bring both sides together, look at the problem collaboratively, and say, "Now, knowing this, we have more confidence. We can decrease the error bar and confidently choose the least burdensome approach."
Mary Vatter: There is also a parallel safety path where you may decide that a letter to file is what’s necessary, not a new submission. You can document that in your file and start marketing it. If you want to pursue a catch-up 510(k) due to variability or uncertainty, you can submit that in parallel with your marketing decision. Essentially, a catch-up 510(k) is initiated because it didn't necessarily trigger a 510(k), but you want to ensure that the FDA is still okay with the changes you've made, even if you don’t believe it triggered a new submission.
I've seen companies decide, "Oh, it's probably not needed; I'm just going to start marketing it." But just to be safe, they still submit a 510(k).
George Hattub: Now, think about this: if a client comes to us saying they’re not sure, the financial incentive for us is to say, "Hey, we’ll do your 510(k) for you." This creates a kind of reverse bias. To maintain our reputation in the marketplace, we strive to be objective. If the decision is that a letter to file is sufficient, that shows we are objective and not financially driven. Many other regulatory consultants might easily say, "Hey, it's a special; I’ll do it."
When advising clients, I always emphasize that it’s a risk. They have to sign off on it. We can recommend one course of action or another, but at the end of the day, if the FDA approaches them, they own the problem. They can’t say, "Well, analytics said it," or "George said it."
The point I’m trying to make is that, as David noted, people will have these types of disputes and seek expert opinions. If we say we can provide guidance on letters of file, we’re almost like a lawyer. They can come to us with their most confidential information, and we’ll help them make the right decision.
J. David Giese: One parallel that jumps out at me when you’re talking, George, is the doctor ordering an MRI. Doctors may get paid more and face less risk, creating a known problem. Many doctors are trying to balance this, but the incentives often push them in that direction—
George Hattub: this is a moral hazard phenomenon.
Mary Vatter: Interesting point. Yeah
All right, well, I think that brings us to the end. Are there any final thoughts or questions anyone has? You all passed the quiz—congratulations!
Reece Stevens: Thanks for the great presentation, Mary; this was awesome.
Mary Vatter: I appreciate the participation.
George Hattub: Good job on SlideShare.
J. Davide Giese: Thanks, everyone, for joining. Especially Pablo, I know it’s late, so thank you. Bye, everybody!
Pablo H. Cerdan: It was great. See you all!
Key Takeaways 🔗
Transcript 🔗
Okay. So, the purpose of today's talk is to go over device changes, planned changes, and the regulatory implications associated with them, as well as how to use FDA guidance documents to help make those decisions.
The two main guidance documents we're going to discuss are: first, deciding when to submit a 510(k) for a change to an existing device, which applies to both hardware and software devices. Second, for devices that include software or are Software as a Medical Device (SaMD), there's another guidance document that applies—deciding when to submit a 510(k) for a software change to an existing device.
If your device involves software, both guidance documents apply in all cases. If it does not involve software, only the general guidance applies. Today, we’re focusing on the two primary uses of these guidance documents, starting with what most people typically think of: a post-market evaluation, or "letter to file," as it's commonly called.
This refers to your change control documentation, which demonstrates that you followed the FDA guidance evaluation process to determine whether a new 510(k) submission is necessary based on the changes you’re making after your product has already received clearance and is on the market.
That’s essentially the original intended scope of the guidance documents, and it’s what is expected to be documented when changes are made. Some people may be unsure about what a "letter to file" actually is—whether it’s something you send to the FDA or not—but it’s simply a letter that goes into the design history file, which is the file we're referencing here.
This is internal documentation of the process you've gone through for the change evaluation. It's not something you send to the FDA; rather, it typically stays with your change record within your internal quality system.
Another aspect we’ll discuss is how to use these guidance documents for pre-market strategy. This allows you to proactively evaluate anticipated design changes. For example, if a company is developing a device with multiple possible functionalities to be rolled out over several releases, you can map out a timeline and assess which of these changes would require a new 510(k) submission. This helps you plan your broader regulatory strategy for the device.
Another strategic use is to evaluate which features to implement before the original pre-market submission. You can assess which changes would definitely trigger a new submission and which ones could be added later through a "letter to file." This helps prioritize changes that may require a new review, allowing you to postpone others that wouldn't trigger a submission.
Often, we see clients wanting to include certain features in their software, but the development required may delay the submission. By using this strategy, you might decide to delay the development of certain features in order to submit your 510(k) sooner.
We’ll explore both of these approaches in more detail. The key principle behind both guidance documents is a risk-based evaluation, focusing on the impact of the changes on the device's functionality and safety.
The first key principle is the intent to significantly affect safety or effectiveness. When evaluating and documenting your changes, consider the purpose of each change. Are you altering the functionality? Are you significantly improving it? If so, these changes may trigger the need for a new 510(k) submission.
With that in mind, you should always conduct a risk-based assessment for any changes. This is crucial because even changes not intended to significantly impact safety or effectiveness could still significantly affect the safety, performance, or other aspects of the software or device, potentially triggering a new 510(k).
Manufacturers should conduct a thorough risk-based assessment using FDA guidelines to evaluate each change. Both guidance documents provide extensive advice on what is expected for such risk assessments. A good practice is to take your risk analysis and identify which risks identified in the analysis apply to the changes you are making, or which could be impacted by these changes. Reference these risk IDs in your evaluation and assessment to base your decision.
And then also, If there are new risks or significant changes to the risk profile or functionality of the device, you must conduct the necessary Verification and Validation (V&V) activities associated with evaluating that change. This applies regardless of whether it results in a 510(K) submission or a letter to file. A crucial aspect of the letters to file is ensuring that the change has been adequately tested to meet your requirements without introducing unforeseen risks.
Lastly, another principle the guidance focuses on is comparative analysis. This involves comparing the change, or the cumulative changes over time, to the cleared version of the device. The guidance provides specifics on evaluating these cumulative changes. You may have heard of the term "catch-up 510(k)," which refers to situations where individually, the changes might not trigger a new regulatory submission. However, cumulatively, if enough changes are made, you need to consider if the device has deviated significantly from the originally cleared device to warrant a new submission to update the FDA's file on the device.
Oftentimes, companies can proactively handle this, but it might also arise during an FDA inspection. If the FDA reviews your design history file, letters to file, and change notes, they might suggest a catch-up submission if the cumulative changes are substantial. While not necessarily the core focus of these guidance, it's an important consideration if you plan to make many small changes to your device.
We've already touched on this, but essentially, how to use the guidance documents and what the FDA expects from a compliance perspective for your post-market change evaluation includes identifying the purpose and impact of the change, conducting a risk-based assessment, and utilizing the different flowcharts provided in the guidance. These flowcharts offer a step-by-step evaluation process for assessing changes. At every decision point in the flowchart, you should document your rationale behind the decisions that are guiding you toward a letter to file or a new regulatory submission.
The documentation of these activities forms a letter to file from a premarket strategy perspective. Of course, this is not about active changes to a marketed device, so the FDA is not as concerned with your proactive documentation, but it's still beneficial to go through the same processes that you would post-market. This includes identifying the purpose of the change, conducting the same risk assessment, applying the flowcharts, doing the step-by-step evaluation, and making a proactive determination as to whether a change would in the future require a new 510(k).
Once you've determined the necessary changes based on your anticipated or desired modifications, you may consider triaging the development activity to prioritize the implementation of changes that might trigger a new 510(k) over those that could be added as a letter to file.
Regarding post-market change control records, they are required once you start marketing your device. However, for premarket strategy, it's also beneficial as part of your regulatory strategy documentation to document the same types of evaluation.
You might have heard of a PCCP or be wondering how this relates to a Predictive Change Control Plan for medical devices. A PCCP is a plan that you can submit as part of your regulatory submission, which essentially pre-clears you to make changes after you receive clearance. The main difference between having a PCCP and just making regular changes documented as a letter to file comes down to the flowcharts and the decision as to whether a new filing case is going to be required. If you're looking at this proactively, evaluating a feature, and going through the flowcharts leads you to documentation only, that would not be subject to a PCCP.
The FDA wouldn't allow you to submit a PCCP for something that would otherwise just be documented as a letter to file. If your proactive evaluation and decision tree lead you to determine that a new 510(k) is required, those are the features or functions you could consider including in a PCCP.
Similar to how we discussed evaluating whether development activities should be prioritized based on what will require a new 510(k), if you have any changes that would trigger a 510(k) and you know you won't be able to implement them in time, then that might be a good opportunity for a PCCP.
There are essentially three categories that your planned changes or features could fall into. Following the FDA guidance for evaluating these changes and referencing the PCCP guidance will help you strategize the best route for planning your development activities, aligning with your timeline and marketing goals.
That’s an overview of the change control process and guidance at a high level. I also wanted to delve a bit deeper into some of the flowcharts and show you what those decision trees look like. This way, you can be aware of the types of questions you should be asking when faced with decisions about whether to implement changes now or later, or how significant the change is from a regulatory perspective.
As I mentioned, the FDA has useful flowcharts that you'll use when documenting your letter to file. However, don't just focus on the flowcharts. For each decision point, there is a more detailed description that includes important considerations for answering the question. If you're unsure how to answer a decision point in the flowcharts, I recommend referring back to the content in the accompanying paragraphs in the guidance for better insight.
Additionally, at the bottom of all these guidances, there are numerous examples. You can skim through these examples to see if one is similar to the change you're considering. The examples detail the change and the corresponding decision, which can be very helpful. Sometimes, you'll find a perfect example that directly represents the change you're contemplating.
I wanted to frame the guidance for you so that you understand the importance of going beyond the flowcharts, even though they are the basis for your decision documentation. The first flowchart comes from the general guidance and serves as a main flowchart pointing you to other relevant flowcharts for label changes, technology or performance changes, and material changes. These are the three main categories in the original guidance. Software, on the other hand, is addressed in an entirely separate guidance document that does not necessarily flow from these charts but is referenced as applicable.
We don’t need to get into the specifics of all these, but I wanted to show you an example.
So, I apologize for the small text, but the format on the left is typically how I document in a letter to file. I write out the decision tree in text and then answer it, providing justification or rationale for each decision point within the letter to file. Specifically for labeling, this doesn't just relate to the software label or the physical label on your product. It also pertains to changes in your indications for use and how you describe your product in marketing claims. If any changes you make would alter your intended use or add a function to it, then you would certainly need to consult this flowchart.
If you are working on a software device and think, "Oh, I'll just follow the software guidance," you may be overlooking crucial change evaluations. Ensure that your documentation process captures the necessary details from both guidance documents.
For labeling, it's important to note changes like going from prescription use to over-the-counter. For example, if a device normally used in a doctor's office is now intended for home use, that would trigger a need for a new 510(k). Also, if the device is going from single-use to reusable, that introduces a slew of new risks related to reprocessing, cleanliness, and restabilization, necessitating a new 510(k). If you’re merely clarifying how it's used to enhance understanding while keeping the same intent, there's some flexibility. However, adding new functions or making your indications more specific, such as for a particular disease, would likely trigger a new 510(k).
The next flowchart is for technology and performance. This also pertains to software and may not always be covered by the software guidance because it relates to the operating principles of the system and the core technological characteristics of how your device achieves its intended use. Some questions might not apply and can be skipped, but others, like B2, often trigger a new 510(k). The methods and protocols used to validate changes are also reviewed in this flowchart.
I'm going to move quickly through this because just a high-level overview isn't very helpful. What you need to do is work through the flowcharts for your specific change, delve into the paragraphs, and detail the guidance to help make and document these decisions. But I just wanted to outline that for you.
Materials changes are pretty self-explanatory and won't apply to software changes. This flowchart is from the software change guidance specifically, separate from the other flowcharts. It starts with evaluating whether the change is solely for cybersecurity. If that is the only reason for the change and the only impact, then it does not require a new 510(k). If the change merely returns the system to the specifications of a more recently cleared device, that also doesn't require a new 510(k). Then, you delve deeper into whether the change introduces or modifies a risk that could result in significant harm not effectively mitigated in the most recently cleared device.
It's important to note the term "significant harm" because sometimes you will encounter changes that, although modifying your risk assessment, are not significant enough to lead to significant harm. In such cases, you can justify why mere documentation is sufficient. This is also why it's crucial to trace back to your actual risk management documentation where the severity of risks is evaluated. If you can link to these risks and show they are of lower severity, then you have a complete paper trail to justify your decisions at this point.
Next, consider whether the change could significantly affect the clinical functionality or performance specifications directly associated with the intended use of the device. This consideration is crucial and relates to PCCPs. For example, algorithm changes that significantly affect clinical functionality require a clear definition within the context of your device and its intended use. Often, if a change necessitates new clinical data or a new clinical study, it will likely require a new 510(K)—a good rule of thumb when evaluating major changes within your intended use.
Beyond this, the FDA is not overly prescriptive but outlines additional factors that can influence the decision to file. These considerations are somewhat subjective, including the company's assessment of the impact of changes related to infrastructure, architecture, core algorithm adjustments that do or do not directly contribute to the intended use, clarification of requirements, any cosmetic changes or user interface alterations, and any re-engineering or refactoring. You must document whether any of these factors apply and evaluate their impact as part of your letter and file for software changes.
This was a high-level overview to ensure everyone is aware of the guidance documents, how to use them, and how to base your decisions on them. With that, the presentation slides conclude, and we can discuss specific examples if desired.
Reece, did you want to discuss the topic you had in mind?
Sure. Thanks, Mary. This has been really helpful to walk through the flowcharts. I worked with them a long time ago and had forgotten most of the details, so this has been a great refresher. The example I recently encountered involves a client developing a tool that includes a DICOM viewer. They want to perform measurements on findings from CT and MR, and they're considering expanding their use case to include measurements on PET CT Fusion. The reason for this is it enables certain clinical assessments that are currently done on the device but require manual input of information that would typically be automatically measured from PET CT. The client has two decisions to make. First, they want to replace the foundational technologies of the DICOM Compute itself. It's currently written in one library, and we need to re-implement it using a different foundational technology to support the rendering of PET CT fusion. This would be a technological change that could be implemented without enabling PET support, essentially replacing a software component without any user-facing impact. The second decision is about activating support for PET CT and supporting the measurement of standard uptake values as an input to response criteria.
So, these two decisions are becoming key decision points in figuring out when to stage and implement these features. Now, I guess I'll open the floor to everyone else. Does anybody have any reactions or thoughts? Sure. Based on my experience, I usually tell clients that they are allowed to make "under-the-hood" adjustments using the guidance documents, as Mary explained. However, often the threshold is when you add a feature, which is something that doesn't currently exist, and perhaps becomes apparent in the GUI. I speak from two experiences: one where a client added a feature, filed a letter to the file, and several years later, during a 510(K) submission, a reviewer questioned a feature we thought was covered. It led to a tense two weeks as we supplied information, culminating in a catch-up 510(K) submission, which could have ended unfavorably.
The notion that you'll never have to submit a 510(K) again is unrealistic. In a second instance, competitors or others submitted new 510(K)s, making their own comparisons and saying, "Our predicate has this feature." If the FDA reviews it and doesn't recall clearing that feature, it could trigger an issue.
There's also a case (not naming any names) where a company was forced to recall their product, a software as a medical device, because they added a feature that caught the FDA's attention.
Furthermore, some of the more advanced companies have procedures detailing the thresholds for letters of file. They might specify that changes from version two to version three are special 510(K)s, whereas changes from version 3.1 to 3.2, if they align with the guidance documents Mary mentioned, then those prevail.
That's all I have to say about that. Did my explanation help you?
Absolutely. Yeah. That's very helpful to know. I hadn't considered the possibility of another company using your device as a predicate and the FDA not recognizing it. But yes, that makes a lot of sense.
So, George, you touched on a lot of important points, one of which is when you're implementing a new feature. It sounds like this involves new underlying technology and a new function that the software will perform, which is akin to an example of a template for a letter to file where you can document the evaluation of these changes. Just to include background information and description, the reason for the change, risk management, and then proceeding to the flowchart evaluation.
Looking at the first of these, it somewhat depends on how the indications for use are written. If you're adding new imaging modalities to specific indications that already include other modalities, then that might trigger this flowchart. If the indications aren't written specifically, then the answers to these questions might be no, and the labeling flowchart might not lead to a new 510(K). However, you'd then need to consider the technology, engineering, and performance changes. I would suggest that possibly this involves a new operating principle if it's taking a new imaging modality and applying a new analysis method to determine a new output. I would have to think about how to justify this if I believe it's not a novel operating principle relative to what's already been done.
So, any thoughts on how you would consider this?
I mean, in this particular context, thinking about whether the intended use of this device was specific about the kinds of measurements that were being performed, I think that it was left somewhat nebulous. I think it might have mentioned something other than quantitative measurements of some kind. In that sense, adding the standard uptake value: would that qualify as a new operating principle, or is it more an extension of what was already listed? I feel like if you're considering that, you're getting a bit into the weeds, though, and you could probably argue it either way.
Yeah, and it makes sense that yes, this is where it gets tricky because sometimes it does come down to how you can justify it. Often, companies are able to justify why the answer is no to these, why it is a letter to file, and you just have to be confident and able to defend yourself when the FDA comes to inspect and argues the other side.
It's certainly like a risk-based decision, a regulatory risk that companies can choose to make. If they feel there is a strong argument for a letter to file, then that's a choice some companies can make. And, of course, the risk, if you're wrong, is that the FDA, when they come to inspect you or become aware through other means of these changes, if they end up disagreeing with you, then the best-case scenario is they would tell you to submit a 510(K) but would not require you to stop marketing your product. But the worst-case scenario would be they would say you need to remove that functionality or you need to stop marketing your product until you receive clearance for those functions they were arguing about. Luckily, in the case of software as a medical device, it's a lot easier most times for companies to recall their software and revert it to an offering that doesn't include the problematic function. So for software companies, maybe that is a pretty low regulatory risk to take that chance.
So yeah, it definitely gets tricky when you could argue something both ways, but that's where the risk-based decision and the business risks that companies are willing to take might drive some of that.
George, I think also when you're faced with these types of situations, sometimes you get cornered and taken by surprise, and the client might want you to make the decision. Some of the arguments I see are, "the ends justify the means." "We can't afford another 510(K); we have to get this out right away." So I always look at that. You have to help the client reach the right decision. First of all, what the FDA enforces does not come before safety. So even though something may be safe, the FDA oftentimes is the arbitrator outside of the risk analysis.
The other thing, too, is that to help the client make the decision, I always tell them the next person that's going to read your letter to the file will be either an FDA inspector, which is different from the FDA that reviews 510(K)s. The people at the FDA who review 510(K)s are scientific-type people with PhDs, whereas the investigators are compliance persons. And so that person is going to look at it differently and they're going to challenge you. And usually, if you make a modification because of a complaint, then they're going to look at it as part of your CAPA system, and you know, did you capture this as a complaint? So sometimes when a letter to the file is being proposed, you have to get all the facts. Sometimes it might be that we can't afford to submit to the FDA. And if they're going to live with that decision, you might have to explain the circumstances. In other words, the next person to read this will be an FDA inspector. Or it could also be the person buying your company. A lot of times regulatory professionals have a lot of influence on those types of decisions, and it's not that they will buy your company, but they could use that as a negotiating tool saying, "Oh, they took some risks here, so we're going to have to do that catch-up 510(K) that Mary mentioned." And then the other person that could read your file is a product liability lawyer. Or in the case where you thought it wasn't a problem and it turns out to be a problem, or something unrelated to your product, they're going to use it against you that you guys didn't let the FDA know about it.
Well, I'm not discouraging letters to file because oftentimes you'll find a situation where the regulatory people in a company will be the most conservative ones because they have to defend it. And so will some regulatory professionals. I'll say it's always a filing to the FDA. When you look at the facts, you say, no, this is a letter to file. You know, it's under the hood. It's not a feature. So those are just some of the things I've run into.
Yeah, that's an interesting point, that it might not just be the FDA who ends up needing to review these files; it might be other stakeholders as well.
So keep that in mind. Also, I just wanted to jump down to the software changes, flowchart, and decision tree to see if there's anything else that would be triggered by the change that we're discussing. I think the topic of new risks might arise if you're providing a new piece of clinical information. The FDA is going to be interested in what that is used for. Sometimes, for devices that have general indications or general measurement indications, you don't have to get into the clinical specifics of how that information is used. However, you might need to consider that from a risk-based perspective in your letter to file if you're adding a new functionality that could be used for possibly a higher risk intended use than what was originally a function of the device.
That’s something I would want to be very confident about, or that I could anticipate some two sides to that conversation. The last question on the flowchart is: does it affect the clinical functionality or performance specification?
So, those are probably the questions I would focus on and need to dig deeper into, conducting a thorough risk assessment to ensure that I can confidently defend those points if I'm deciding whether a 510(k) is required. In this case, I think things may be adding up to where adding that new function would likely require a new submission. But of course, it depends on all the details—how you're marketing the product, what the intended use is—so there is flexibility in that.
Thanks for that example. And then lastly, of course, there are other things to consider that we talked about, such as an algorithm change if it's doing something new. But it may or may not.
Just all the things you need to think about when making those decisions. I have a little quiz if we want to test your knowledge. I have examples from the FDA guidance, but I don't want to jump to that if we have other questions or examples to go through.
I have a quick question. I might be misreading the guidance here, but one of the items talks about if you end up having to make a change, or it seems like you should submit a 510(k). It sounds like they're saying if you have changes that trigger the 510(k) but you also have changes independent of that which would just follow the normal documentation path, you combine both in the new 510(k). But then it said something interesting—that it sounds like you could continue making those changes immediately and not the triggering changes.
I was just curious if that sometimes gets really confusing and messy. Does that happen in practice, or what does that look like?
Yeah, all the time, actually. You can go years with letters of file, and then one thing will trigger the 510(k). But your documentation needs to reflect all the changes that have been made up to that point in time. It doesn't mean that you were illegally marketing it during that time, but the FDA is interested in all the changes that have added up to where it is now that they're reviewing.
There may be other things, like George mentioned—maybe some other changes that had happened along the way in his example that probably should have triggered a new 510(k) but managed to slip under the radar for a long time. Even if all those changes are documentation-only and wouldn't normally require a letter to file, everything has to be described in detail in the new submission.
That's a good question because that does happen a lot, and a lot of times clients are surprised at how much effort it is, because it is a lot. Sometimes I think also about the special 510(k). I'm not sure how much everyone is aware of it, but most of the time we're preparing traditional 510(k)s, and those are the ones that take over six to nine months. The FDA has special 510(k)s that were made specifically for situations like this. When you submit a special 510(k), they have the highest priority with the FDA.
A special 510(k) means the FDA has to drop what they are doing and focus on your submission because they have only 30 days to make a decision. The FDA works very efficiently, according to internal clocks that they have to report to Congress. In 30 days, they either have to allow the change or give you a hold.
Recently, I had a situation with a client where we submitted a special 510(k), and it got put on hold. We automatically assumed it was now a traditional submission, and we took a little time because we had to meet with the FDA. Once we provided that additional information, the clock—which you could see on the customer collaboration portal—started for another 30 days. So if you add it up, that's 60 days, not counting the time that it was on hold while we were gathering information.
We were able to get the 510(k) cleared as special, but they still had issues, and we still beat the traditional timeline. So sometimes that helps; the course of a 510(k) can get enormous. Sometimes they don't have the budget for it; whether it's special or traditional, it's still the same price.
That's a good point to bring up to George because even as you're doing this analysis and evaluating your changes, even if it does require a 510(k), if you're modifying your own device, it likely may be a special 510(k). You're not looking at the traditional timeline of 90 days, nor at all of the documentation that is normally required for a traditional 510(k)—it's a smaller scope of work.
So, I would definitely point you to the special 510(k) guidance document for further reading so that you can understand in what circumstances it is not applicable, as that might impact your strategy as well. If you think, "Well, I'm going to submit this, and then during the 90 days that they're reviewing it, I'm going to be working on developing the next version. As soon as it's cleared, I'm going to submit a special," then you're really only delaying things by about 30 days or however long the special review takes. That might be something worth considering.
I would recommend you read that guidance as well. I just wanted to add a couple of comments about what George mentioned regarding the regulatory team often being the most conservative group in many companies. That's a pretty common complaint I hear on sales calls. Companies often come to us saying, "We were working with this regulatory consultant, and they're telling us we have to do new 510(k)s for every change," which feels really burdensome.
In general, sometimes companies are just fishing around for a "yes" person to agree with whatever they want to do. However, I also think there's some validity to the concern that regulatory personnel—especially those who have worked at very large companies—may be accustomed to an environment where the company's business goals are very risk-averse. They then translate that mindset over to smaller companies that might be more willing to operate closer to the line or the blurriness in the regulations.
When you read the regulations, particularly in the very first few pages of the guidance, it really all hinges on the word "significant"—what does "significant" mean? The letter of the law is one thing, while the guidance provides additional clarity from the FDA. Ultimately, it comes down to determining what we think is significant in a variety of specific situations. But you could always argue, "Oh, I don't think this is actually significant."
There's a whole psychology to letters of file; we could probably write a book on it—discussing the stakeholders involved. In larger companies, their thought processes often trickle down. A lot of times in larger companies, they actually have FDA personnel who have made the switch to industry, so smaller companies often take their lead from that as well.
But you are allowed to make changes. The biggest thing is whether or not you can defend them, as Mary mentioned. The pointed defense may happen two years from when that decision was made, and sometimes people move on. This is another phenomenon where if you're sitting across from the FDA defending someone else's decision, you may not necessarily agree with it.
Once again, I always emphasize the need to be rational and ask the right questions. Another example is when I was involved in a situation where we asked whether something was a customer complaint. Some people said yes, and some said no. It's essential to clarify—were we talking about a complaint? If it's a complaint, it has to be in your CAPA system, and you know the FDA is likely to scrutinize that file, especially with letters of file. If it's an unmet expectation or an afterthought, that's a bit different.
There's a whole psychology here; we could probably make a lot of money right now with an ebook on this topic.
I think it's beneficial to get different eyes on your letters of file and different perspectives. It's something I often suggest companies do during their internal audits—have someone unfamiliar with the letters of file review them. They might identify different risks or concerns that an FDA inspector might see as well. Just a thought.
When there's more uncertainty about something, what tends to happen is you become more conservative about that issue, right? For example, if we have a statement of work for a software engineering project and there's a large uncertainty, that estimate will probably end up being higher than if we had more information. If we can narrow that gap, we can be more confident in our estimates.
I think it's similar with this conversation. What sets us apart as a team is that we can reduce that uncertainty. With our engineering background, regulatory expertise, and some clinical insight, whenever we encounter a problem, we can clarify whether something is notifiable or not. If there's a lot of uncertainty, that often breeds fear, leading to a conservative stance.
If you're well-informed about the device and understand why the FDA is asking for certain things, you can anticipate their concerns. The FDA doesn't want to see changes that are insignificant; they want to focus their efforts on changes that actually matter. However, if you're uncertain and view it as a big unknown, you'll likely be much more conservative than necessary.
I think it's a great point, and it highlights the value of having engineering and regulatory teams work together. If the regulatory team doesn't fully understand the engineering processes—how software is developed, how algorithms are trained, and all those different aspects—they will naturally be more cautious because there are many unknowns for them.
I'm sorry to jump in; I thought you were done, but that point has come up several times. Clients have come to us questioning whether simply retraining the algorithm would require a special or full 510(k). If you read the guidance by the letter, you could arrive at that conclusion.
But if you read the examples and then put an engineer's eye on those examples, you can understand what the FDA really meant. Just to retrain the algorithm is not necessarily grounds for resubmitting a 510(k). Even if you read the letter, there is a more conservative path to take in the face of uncertainty that leads to the conclusion that this is a 510(k) requirement when, in practice, it’s not. The only way to navigate this effectively is to bring both sides together, look at the problem collaboratively, and say, "Now, knowing this, we have more confidence. We can decrease the error bar and confidently choose the least burdensome approach."
There is also a parallel safety path where you may decide that a letter to file is what’s necessary, not a new submission. You can document that in your file and start marketing it. If you want to pursue a catch-up 510(k) due to variability or uncertainty, you can submit that in parallel with your marketing decision. Essentially, a catch-up 510(k) is initiated because it didn't necessarily trigger a 510(k), but you want to ensure that the FDA is still okay with the changes you've made, even if you don’t believe it triggered a new submission.
I've seen companies decide, "Oh, it's probably not needed; I'm just going to start marketing it." But just to be safe, they still submit a 510(k).
Now, think about this: if a client comes to us saying they’re not sure, the financial incentive for us is to say, "Hey, we’ll do your 510(k) for you." This creates a kind of reverse bias. To maintain our reputation in the marketplace, we strive to be objective. If the decision is that a letter to file is sufficient, that shows we are objective and not financially driven. Many other regulatory consultants might easily say, "Hey, it's a special; I’ll do it."
When advising clients, I always emphasize that it’s a risk. They have to sign off on it. We can recommend one course of action or another, but at the end of the day, if the FDA approaches them, they own the problem. They can’t say, "Well, analytics said it," or "George said it."
The point I’m trying to make is that, as David noted, people will have these types of disputes and seek expert opinions. If we say we can provide guidance on letters of file, we’re almost like a lawyer. They can come to us with their most confidential information, and we’ll help them make the right decision.
One parallel that jumps out at me when you’re talking, George, is the doctor ordering an MRI. Doctors may get paid more and face less risk, creating a known problem. Many doctors are trying to balance this, but the incentives often push them in that direction—this is a moral hazard phenomenon.
Interesting point.
All right, well, I think that brings us to the end. Are there any final thoughts or questions anyone has? You all passed the quiz—congratulations! Thanks for the great presentation, Mary; this was awesome. I appreciate the participation. Good job on SlideShare.
Thanks, everyone, for joining. Especially Pablo, I know it’s late, so thank you. Bye, everybody! It was great. See you all!
