If You Change It, FDA Will Come: What the O.N. Diagnostics Warning Letter Means for SaMD Modifications

Yes, we know — the O.N. Diagnostics Warning Letter has already been thoroughly covered since FDA posted it on October 6. We waited for the dust to settle, since we think software companies will be living with the implications of this letter for quite some time.

Though posted on October 6, FDA issued the letter to O.N. Diagnostics on September 1, 2026, following a March 12–17, 2026, inspection of its VirtuOst and VirtuOst Vertebral Fracture Assessment (VFA) software products. VirtuOst VFA was originally cleared under K171435 to use sagittal sections of a spine CT to visualize vertebral deformities, classify fracture type and grade, and support physician management of osteoporosis. The letter provides perhaps the clearest perspective on where FDA will draw the line between the kind of software iteration that lives comfortably inside an existing clearance and the kind that requires a new submission — and it is one that will likely not sit well with SaMD manufacturers who have been treating model retraining and architecture changes as internal engineering decisions.

The Warning Letter states that the software is adulterated and misbranded due to the (1) introduction of a new machine learning algorithm, (2) migration from a desktop to web-based architecture, and (3) migration of the underlying technology platform for the reasons provided, in turn, below:

1. “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. This new feature fundamentally changes how the device performs, fails, and affects patients in ways that go beyond what was originally cleared and therefore the feature must be adequately validated.” That framing — change in training data, architecture, or optimization objective — is broad, and it captures essentially every meaningful AI/ML update a sponsor is likely to ship.
2. FDA treated the move from a desktop application to a web-based architecture as a change that introduced “network-exposed attack surfaces, authentication vulnerabilities, and other cybersecurity risks inherent to internet-accessible platforms.” The company itself acknowledged during inspection that the shift expanded its “cyberattack surface area.”
3. A second referenced but redacted technology platform migration required “comprehensive re-verification and re-validation of the entire software codebase, including changes to third-party libraries and dependencies,” and FDA noted that it had not reviewed the device’s Software Bill of Materials (SBOM) or documentation of the affected third-party components.

Perhaps even more interesting than the points above are some of the underlying takeaways of the letter and the implications for AI/ML and SaMD developers.

First, FDA is reading release notes and version-control logs. The Agency cited the “3.0.0 Release Notes dated June 11, 2024” and the “Software Version Control Log” as the evidentiary basis for its determination that a new model had been introduced. Engineering artifacts that developers generate for internal purposes are now part of CDRH’s inspectional record. The real question here is whether information contained in release notes could be used by manufacturers for other purposes, for example, as notifications under 21 C.F.R. Part 806. We suspect that while FDA may make use of release notes to determine whether a new model has been introduced, it would not agree that information provided in the same format would constitute sufficient notice for customer-facing purposes.

Second, FDA seems to be applying a standard for when a new 510(k) may be needed that is not necessarily consistent with the regulatory requirement. FDA is stating that the new feature “may perform differently across patient populations, imaging equipment types, or clinical settings” that must be “adequately validated” and therefore requires a new 510(k). FDA’s guidance, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, recognizes that software validation is required even when a company determines that no new 510(k) is required, yet in this Warning Letter FDA appears to be conflating the need for validation with the need for a new 510(k), a standard that does not otherwise exist.

Third, architecture changes are now independently regulatory. The web migration and the platform migration were each separately sufficient to require a new 510(k), on cybersecurity and verification/validation grounds respectively. As with the second point above, FDA does not seem to be applying the appropriate regulatory standard or posing the questions presented in the guidance used to help companies determine whether a new 510(k) is required. Instead, FDA appears to be applying a table-stakes position that certain changes, regardless of whether they meet the historical threshold for a new 510(k), will now require one.

Taken together, these three points describe a Warning Letter doing considerably more work than enforcing a single clearance. FDA is using an inspection of one company’s release notes and architecture diagrams to write new law on how it will read 21 C.F.R. § 807.81(a)(3)(i) against the entire SaMD industry — and it is doing so in a way that does not obviously track the text of the regulation or the Agency’s own guidance. A manufacturer that has been quietly retraining models, re-platforming to the cloud, or swapping out dependencies on the theory that none of it individually crossed the “significantly affect safety or effectiveness” threshold now has reason to revisit that theory, and reason to wonder what else in its own version history FDA would read the same way.