When a Software Update Needs a New 510(k): Notes from a Coffee and Q&A on FDA's Warning Letter to O.N. Diagnostics

 October 25, 2026
SHARE ON

AI/MLRegulatorySoftware

Summary 🔗

On October 22, 2026, James Swink hosted a Coffee and Q&A session on LinkedIn Live with J. David Giese, Mary Vater, and me. The topic was FDA's warning letter to O.N. Diagnostics, LLC (MARCS-CMS 730301), issued on September 1, 2026, and posted on October 6, 2026. FDA says that version 3.0.0 of the VirtuOst Vertebral Fracture Assessment (VFA) software carried three changes and that each one required a new 510(k).

Key points

  • One regulatory test. FDA charges a new machine learning algorithm, a desktop-to-web move, and a platform migration under 21 CFR 807.81(a)(3)(i). The letter does not allege a change in intended use.
  • Quality system context. The letter also cites corrective and preventive action (CAPA), supplier control, and medical device reporting (MDR) findings. Mary called the warning letter a symptom and the quality management system (QMS) the disease. David and I also tied the warning letter to the CAPA history.
  • Retraining. Mary said FDA's expectations for retraining have become "a lot heavier" since 2017 and 2018.
  • Returning to FDA. I said companies need to stop fearing a new submission. Mary described the catch-up 510(k).
  • PCCPs. David said a predetermined change control plan (PCCP) could not have helped a company that added AI to a device that had none.

Replay of the October 22, 2026 Coffee and Q&A (61 minutes).

Background 🔗

James Swink is Principal Regulatory Specialist at Innolitics and spent 22 years at FDA's Center for Devices and Radiological Health. J. David Giese and I are partners and co-founders of Innolitics. Mary Vater, Director of Regulatory Affairs at Innolitics, joined as a guest.

O.N. Diagnostics makes CT-based bone analysis software. FDA cleared VirtuOst VFA under K171435 on August 3, 2018. The device uses sagittal sections from a spine-containing CT scan to measure vertebral deformities, classify and grade existing vertebral fractures, and identify patients at high risk of a future osteoporosis-related fracture. The 510(k) summary describes "semi-automated, interactive tools," including "an active contour segmentation routine seeded by a user mouse click on the vertebral body." The cleared device used no machine learning. The firm also holds K113725 (VirtuOst, 2012) and K220402 (VirtuOst, 2023). None of the three clearances lists an authorized PCCP in FDA's 510(k) database.

Date Event Source
May 15, 2017 K171435 received by FDA FDA 510(k) database
August 3, 2018 K171435 cleared FDA 510(k) database
June 11, 2024 Date of the "3.0.0 Release Notes" Warning letter
March 12 to 17, 2026 FDA inspection Warning letter
April 1, 2026 Firm's response to the Form FDA 483 Warning letter
September 1, 2026 Warning letter issued Warning letter
October 6, 2026 Warning letter posted FDA warning letter listing

James opened with the case. In his summary, every software company swaps in new models, moves to the web, and upgrades its platform, and most treat these steps as maintenance.

"FDA just made it clear, for a cleared medical device, each of those can be a brand new device." (James Swink, quoted from the session)

The three changes in VirtuOst VFA 3.0.0 🔗

FDA found the changes in the "Software Version Control Log" and the "3.0.0 Release Notes".

  1. New machine learning algorithm for vertebral landmarking. FDA writes that "a new model trained on different data, with different architecture, or optimized for a different objective may perform differently across patient populations, imaging equipment types, or clinical settings," and that the feature "fundamentally changes how the device performs, fails, and affects patients." FDA lists missed or inadequate diagnosis, absence or delay of results, and overreliance on device output as possible harms.
  2. Desktop to web. FDA says the move to "a web-based architecture" introduces network-exposed attack surfaces and authentication vulnerabilities. The firm acknowledged an expanded "cyberattack surface area." The letter does not use the word "cloud."
  3. Platform migration. The platform changed between two redacted platforms. FDA says this "necessitates comprehensive re-verification and re-validation of the entire software codebase" and notes that FDA has not reviewed the device's Software Bill of Materials (SBOM).

FDA states that each change "could significantly affect the safety or effectiveness of the device." The letter calls VirtuOst VFA 3.0.0 adulterated under section 501(f)(1)(B) and misbranded under section 502(o) of the FD&C Act, and it asks the firm to stop commercial distribution of that version. The letter cites neither the 2017 software-change guidance nor PCCPs.

Under 21 CFR 807.81(a)(3), a marketed device needs a new 510(k) for (i) a change that could significantly affect safety or effectiveness or (ii) a major change or modification in intended use. FDA charged all three changes under trigger (i).

Figure 1. The two triggers in 21 CFR 807.81(a)(3) and the trigger FDA applied to each change in VirtuOst VFA 3.0.0.

Quality system and MDR findings 🔗

The same letter reports violations of the Quality Management System Regulation.

  • CAPA (ISO 13485:2016, clause 8.5.2). FDA writes that the firm "was made aware of the underlying issue related to the need to update your (b)(4) software three times over three years," and that CAPA-0088 "was opened the day before our inspection began." A revision of the CAPA procedure narrowed the triggers for a CAPA, and "the impact of these changes was not evaluated prior to implementation."
  • Supplier controls (clause 7.4.1). FDA calls the procedures for supplier re-evaluation and monitoring vague.
  • MDR procedures (21 CFR 803.17). The firm's written MDR procedures lacked required definitions and reporting instructions.
Figure 2. Premarket, quality system, and reporting findings in the warning letter.

First reactions of the panel 🔗

"I wish they had called us. It was a little painful." (Mary Vater, quoted from the session)

David said he was surprised that FDA treated the desktop-to-web move as needing another 510(k) for software that is not time-sensitive, and that FDA first seemed "pretty conservative." Reading further changed his view. "Maybe that's really the underlying story," he said, "is they had several CAPAs, and they had a chance to address this, and they just didn't."

Mary said that "the warning letter was a symptom, and that the QMS was the disease in this case." In her view, a single change made "with proper risk assessment, justifications, evaluation, validation, cybersecurity updates" might not have caused FDA as much concern. The changes may have been "a little bit scarier, because they were released within what seemed to be an uncontrolled system."

I said I thought the biggest trigger was the new AI algorithm added to a device whose cleared version used standard, non-AI image processing. Agreeing with David, I said the other changes may not have been FDA's focus and may have been pulled into the dragnet. I would not over-index on every change in the letter. A warning letter usually says more than the change that started it, so I read these letters with the context in mind.

"If I were to rank order the changes that triggered it, probably would be the change that added a new machine learning algorithm, where one didn't really exist before." (Yujan Shrestha, quoted from the session)

I added that this change alone might have drawn a slap on the wrist, and that the warning letter may have come from the CAPA history downstream of it. Later, David called the replacement of a traditional algorithm with machine learning "probably the key thing," along with "the loose quality management system."

A new AI model as a significant change 🔗

James asked why a better AI model would worry FDA. David said FDA expects testing on data that represents the intended use population and evidence that performance generalizes across relevant subgroups, such as imaging manufacturers. Statistical significance alone is not sufficient.

"You can't just do that without following the process." (J. David Giese, quoted from the session, on adding an AI model where a device had a traditional algorithm)

James asked whether the harms the letter lists, such as misdiagnosis and overreliance on the output, are real for a fracture tool. I described a failure path. A more automated process misses a vertebral fracture, which may have indicated a future fall risk and a later hip fracture. If the new process is worse than the old manual one, users may not know it and may assume the quality they are used to. That can bias diagnosis downstream. FDA's letter does not allege that such an event occurred.

Mary noted that FDA's listed harms are existing device hazards. In her reading, the new landmarking model can change how often and where misdiagnosis happens, and the move to the web brings outages, logins, and network failures that can delay results.

"One of the biggest areas that the FDA pushes back on the letter to file is your risk assessment and if you changed existing risks." (Mary Vater, quoted from the session)

Figure 3. Hazards named in the letter and the change linked to each, in Mary Vater's reading.

Retraining under the 2017 software-change guidance 🔗

FDA's 2017 guidance on software changes sets out a flowchart. Question 2 asks whether a change is "made solely to return the system into specification of the most recently cleared device." Question 4 asks whether it "could significantly affect clinical functionality or performance specifications." The guidance does not mention machine learning or retraining.

David said that under the 2017 guidance, "even if you're improving the model, it does require a change." He added, "I've always found that very strange, personally." I suggested FDA may write guidance more conservatively than where it wants industry to land. In my view, a retrain for data drift can be argued to return the product to its cleared specification under Question 2. A retrain that adds a new scanner manufacturer probably calls for a Special 510(k) at the least. David agreed that a drift retrain can lead back to a letter to file, while a retrain to improve performance may land on "yes" at the performance question, Question 4.

Mary said that in 2017 and 2018, when she worked on early AI/ML submissions, FDA advised her to follow the software change guidance and justify the risk. Retraining was acceptable if the device still met the original acceptance criteria. FDA finalized its PCCP guidance for AI-enabled device software functions on December 4, 2024, and revised it on August 18, 2025. Mary suggested the company may have formed its understanding at clearance and not kept up with later expectations.

"The retraining is one that's gone a lot heavier." (Mary Vater, quoted from the session)

Figure 4. FDA expectations for retraining as Mary Vater described them, with the clearance, PCCP guidance, and warning letter dates.

James asked David what he asks a CEO who says "we just retrained our model." First, whether the device has a PCCP, since a PCCP for basic retraining has been "pretty straightforward to get through." Second, why the company retrained. Without a PCCP, a retrain that expands the accepted inputs probably calls for a Special 510(k). A retrain that restores prior performance may not require a new submission.

Calibration of the 2017 flowchart 🔗

James asked me whether retraining, a new architecture, and a swapped model are the same to FDA. I said it depends on many factors and walked through the flowchart on screen. I place the change on a ladder, from a same-architecture retrain on more data from the same population at the bottom to a retrain that adds a new scanner vendor higher up. I highlight loose terms such as "solely to strengthen cybersecurity" and "does not have any other impact." Then I ask where the client sits on risk. A conservative reading can come from a conservative culture or a high-risk device. I see nothing wrong with a conservative culture, and for a high-risk device, playing it safe is sometimes required.

Figure 5. Flowchart questions in FDA's 2017 software-change guidance, with the loose terms highlighted.

To calibrate these terms, I show a client an FDA example that went to "yes" and one that went to "no," and ask where their change falls. On screen I showed the calibration tool embedded below, here in its current version. It traces a change through the 2017 flowchart under conservative, balanced, and lean readings, shows FDA examples on each side of the loose terms, and has a tab that walks through the O.N. Diagnostics letter. The readings in the tool were drafted with Claude, and I said on air that they are not that scientific.

Deciding When to Submit a 510(k) for a Software Change to an Existing Device · FDA, Oct 25, 2017
Note to file or new 510(k)?

FDA's 2017 software-change flowchart. Pick an AI change, move the slider from conservative to lean, and follow the path. Each box explains its answer and how that reading interprets FDA's boundary words.

Conservativefavors a new 510(k)BalancedLeanfavors documenting
START Document New 510(k) 1. Is the change made solely to strengthencybersecurity and does not have any otherimpact on the software or device? 2. Is the change made solely to return thesystem into specification of the mostrecently cleared device? 3a.Does the change introduce a new risk ormodify an existing risk that could result insignificant harm and that is not effectivelymitigated in the most recently cleareddevice?or3b. Does the change create or necessitate anew risk control measure or a modificationof an existing risk control measure for ahazardous situation that could result insignificant harm? 4. Could the change significantly affectclinical functionality or performancespecifications that are directly associatedwith the intended use of the device? Evaluate additional software factors thatmay affect the decision to file. See sectionVI for examples. YES YES NO NO YES NO YES NO This flowchart is not intended to be used as a 'stand-alone' document and should only be considered in conjunction with the accompanying text in this guidance.
Figure 1. When to Submit a New 510(k) For a Software Change to an Existing Device. Redrawn from FDA's 2017 guidance; the colored line is the traced path. Select a box to jump to its explanation. Select a boundary term to see FDA's examples in the Calibrating examples panel.

Interactive figure. The software-change calibration tool I showed on air, in its current version. Move the stance slider to compare the conservative, balanced, and lean readings of one change.

"I think all of these are valid strategies, just as long as nobody gets hurt." (Yujan Shrestha, quoted from the session)

If patients do not get hurt, I consider it a risk the company should be allowed to take.

I named "could significantly affect" as perhaps the most contested term. David noted that the phrase comes from the regulation itself.

"Significantly, there's a lot to unpack there." (J. David Giese, quoted from the session)

David said that, as he understood it, a more conservative 2011 FDA interpretation of the phrase was withdrawn after Congress intervened. FDA withdrew its July 2011 draft guidance on device modifications after section 604 of the Food and Drug Administration Safety and Innovation Act of 2012 directed it to.

The 2017 guidance states that "each change should be assessed separately, as well as in aggregate." Mary said she thought FDA looks at the cumulative changes, and that she did not think anyone would consider these changes maintenance updates "even at any different point in time, let alone if they had happened all at once."

The fear of returning to FDA 🔗

I described a pattern I have seen. A company gets its first clearance and adds a feature that is probably a note to file. It adds another, and another. When someone asks about going to FDA, the answer is no, because the company would have to disclose all those features. So it never goes.

In this case, I said, the company definitely should have gone back to FDA, although the crossover point is not clear. I do not think it would have received a warning letter with an active premarket submission at FDA. The premarket reviewer asks whether the changes affect safety and effectiveness and whether the device is still substantially equivalent. The reviewer is not the enforcement arm, and I said the fear needs to be broken.

"Doesn't matter what you've done, you know, your sins are forgiven, kind of thing." (Yujan Shrestha, quoted from the session)

Mary has reviewed borderline letters to file in internal audits and asked companies whether they were comfortable leaving them for an inspector. She described a catch-up 510(k). The company does not admit that any individual change needed a 510(k). It submits in good faith to bring the file up to date and can still argue that no change required a submission. For a borderline case with a good letter-to-file argument, she said, the company can keep marketing the device meanwhile and is unlikely to be stopped.

Company size, budget, and conservative procedures 🔗

David raised company size. He said he believed, from the company's website, that professors from UC Berkeley founded it to turn their research into a product for patients. For a smaller company, the cost of submissions and quality activities can push it one way or another.

I described a counterintuitive effect. A regulatory team without software experience may impose very strict lifecycle requirements, such as tools validation for a C compiler, which I would reserve for something like a real-time pacemaker. The overly conservative procedure can lead to noncompliance and a policy that is too lean in practice. I said this could have happened here, or at least I have seen it happen in some cases. David described a related effect. A conservative quality function spends a limited budget validating C compilers instead of the core algorithm, until management or engineers decide they are "just doing it."

Predetermined change control plans 🔗

James described a PCCP as a plan that tells FDA in advance which changes the company will make, how it will test them, and which results it must meet. He asked what one would have looked like for O.N. Diagnostics. James cited a PCCP share from FDA Device Explorer on air. In FDA's own records, of the 511 AI-enabled 510(k) clearances and De Novo grants on FDA's AI-enabled device list decided from January 1, 2025, to June 30, 2026, 46 (9.0%) show "Predetermined Change Control Plan Authorized: Yes" in FDA's 510(k) and De Novo databases. Across all 4,904 510(k) clearances and De Novo grants in the same window, at least 113 (2.3%) do.

"If they did not have any AI, there's no way a PCCP could have helped them." (J. David Giese, quoted from the session)

David said Innolitics has tried several times to add a major new feature through a PCCP without success. Retraining an existing model on more data is an easy fit, and so is a new scanner type clearly inside the intended use. The statute behind PCCPs is broad, he said, and he mentioned that the first device with continuous learning under a PCCP had been cleared about a month earlier. The public record includes ProNova's VIRTUE QA (K260597), cleared on September 23, 2026, whose PCCP updates its models once daily. David said a new FDA PCCP web page lists continuous learning for ECG arrhythmias, an example he did not believe is in the guidance. FDA's page of hypothetical PCCP case examples, current as of October 20, 2026, includes "Continuously Learning Cardiac Arrhythmia Detection Software." None of the examples in the AI PCCP guidance is an arrhythmia detector. About 25 seconds of David's next comment were lost from the recording. When it resumes, he describes reviewers asking applicants to remove PCCP content and submit it separately.

Figure 6. PCCP fit by type of change, from J. David Giese's experience.

I said the company's position on risk sets the bar. Innolitics would not put a change in a PCCP that the company would treat as a note to file. I also said FDA has become more open to PCCPs that look further ahead and are less specified up front. For many generative AI devices, I see no workable path without one. Large language model providers such as Google, Anthropic, and OpenAI give two weeks to six months of deprecation notice, and a 510(k) probably takes about six months. I have advocated for this direction. PCCPs should be seen as a way to do test-driven development, and with generative AI, eval-driven development.

James said FDA is hiring digital health staff and that reviewers are overwhelmed. He described filing the 510(k) first and the PCCP a few months later. David said this does not usually slow a company down much. Mary added that a PCCP front-loads work and does not reduce documentation. She recommended a very focused first 510(k) and a PCCP as an immediate follow-up.

Audience questions 🔗

PCCP examples for software in a medical device (SiMD). I named antimicrobial susceptibility testing as a canonical example, and David noted FDA has a separate guidance for it. I filtered FDA Device Explorer for PCCPs on screen, which returned about 238 records. David recalled PCCPs for replacing hardware components near end of life. Mary said a hardware company can plan to gather data in an underrepresented subgroup and then expand the labeled population, which she called rarer but allowed.

A PCCP in a Special 510(k). My understanding on air was that a PCCP cannot be established in a Special 510(k). Mary thought it might be possible if the change itself qualified as a Special, though FDA would probably push it to a Traditional. I recalled Special 510(k)s with PCCPs that might modify an existing plan. The AI PCCP guidance lists the Traditional and Abbreviated 510(k) as the 510(k) types appropriate to establish a PCCP, and states that "a special 510(k) submission may be appropriate to modify a PCCP" under conditions.

Takeaways for founders, regulatory leads, and boards 🔗

  • Founders. I said in the session that knowledge silos between engineering and regulatory can produce changes like these.
  • Regulatory leads. Mary said FDA pushes back on letters to file whose risk assessment misses changes to existing risks.
  • Boards. FDA found these changes during an inspection about 21 months after the release notes date. Mary recommended asking in the first regulatory strategy where the product will be in 5 to 10 years and whether those changes need a PCCP.

Closing remarks 🔗

I said I do not think anyone at the company had bad intentions.

"Several good intentions strung together could still get you a warning letter." (Yujan Shrestha, quoted from the session)

Resources should go where they have the highest impact on safety and effectiveness for the least burden. That takes a cross-functional team in which each side understands the other. Mary closed with her view that problems multiply in FDA's eyes. Changes too large for a letter to file, unchecked by regulatory, and built outside a QMS with a culture of quality multiply FDA's concern.

Limitations 🔗

This article reports a 63-minute conversation and is not a study. I removed filler words from quotations and kept their meaning. On air, James gave the clearance year as 2017 and described the second regulatory trigger as a "minor" change in intended use, and Mary referred to the cloud. The article gives the record for each.

Further reading 🔗

About the author 🔗

Yujan Shrestha, Partner

Yujan Shrestha, MD

Partner

I have led or supported FDA strategy and submissions for 51+ medical devices, most AI-enabled, since co-founding Innolitics in 2012, across 510(k), De Novo, Breakthrough, Q-Sub, and deficiency responses. My work spans radiology AI (CADe, CADx, CADt, quantitative imaging), cardiac and neuro imaging software, dental AI, LLM and foundation model devices, and I have managed or contributed to 65 Innolitics projects. FDA's public clearance letters for AI Metrics (K202229, 2020) and Medweb's Lightning Viewer (K242362, 2024) name me as the sponsor's correspondent. I presented at FDA's first Digital Health Advisory Committee meeting on generative AI in November 2024, I have published 78 articles on innolitics.com, and I built fda.innolitics.com, our public FDA device search tool.

Connect on LinkedIn
SHARE ON

From concept to FDA clearance. One partner.

Innolitics builds the software, trains the AI, runs the QMS and change control, and prepares every submission under one roof, including the call on when a software change needs a new 510(k) or a PCCP. 50+ FDA-cleared SaMD, software documentation in four months, and 510(k) clearances in as little as nine months, backed by our timeline and clearance guarantee.

We Architected Neosoma's Fast Lane to FDA: A Modular Strategy Built for Rapid Repeat Clearances

We isolated Neosoma's new CNN for FDA review, won clearance in 3 months, and built a framework for every product after.

Neosoma logo

We Ran a Gap Analysis — They Passed Their FDA Audit

Gap analysis for an SaMD company that got audited that same year and passed with minimal findings

Trusted by

  • nvidia
  • University of Alabama
  • Mary Bird Perkins
  • PhotoniCare
  • Butterfly Network
  • Enlitic
  • OXOS
  • NSI
  • Prenuvo
  • Transonic
  • AI Metrics
  • RadUnity
  • Varian-Mobius
  • Echo IQ
  • Envisionit
  • Smile Dx
  • Indica Labs
  • Magnetic Insight
  • Neosoma
  • BodyCheck

Learn more about our Regulatory Strategy and Pre-Sub service.

Our FDA Clearances

Related Articles

Let's Talk

Every great partnership starts with a conversation. Fill out the form below for a discovery call, and an Innolitics team member will contact you soon.

Book a 30-minute call →