The code is ready. Is the SaMD change ready for release?
A cardiovascular software team reaches its planned release date with a successful build, passing automated tests and a list of completed development tickets. Customers are waiting for the improvement. Engineering can deploy it.
The remaining question is whether the company can explain what the change means for the medical device: which clinical behavior may be affected, which evidence supports the changed version, and whether a regulatory submission is needed before commercial distribution. A release date can arrive before those judgments are complete.
For software as a medical device, release planning works better when those questions shape the work from the beginning. Otherwise, the final approval meeting becomes the first place anyone discovers that the team has tested the implementation but has not resolved the consequences of using it.
Start with what will change for the user
Consider a hypothetical manufacturer of FDA-cleared software that helps clinicians review cardiovascular recordings. The proposed release combines a preprocessing change intended to handle a wider range of signal conditions with a simpler display for reviewing the resulting findings. Assume that no cleared predetermined change control plan covers these modifications.
The development tickets describe two manageable tasks. The product decision is more substantial. Preprocessing changes what information reaches the analysis, while the display influences how the clinician interprets its output. A missed finding could arise from either part of that chain. Their interaction matters even if separate teams developed them.
A useful change description therefore explains the old behavior, the proposed behavior and the reason the difference matters. “Improved signal handling” leaves too much unresolved. Does the change preserve information that was previously lost, suppress a feature the algorithm uses, or cause previously excluded recordings to produce results? Each possibility points toward different evidence.
The same reasoning applies to the display. Making an incomplete analysis look cleaner could inadvertently make it look complete. A software test can confirm that the new screen renders correctly without answering whether the user understands the status of the result.
Ask what the passing tests establish
Automated regression tests are valuable because they can repeatedly examine defined behavior. Their meaning depends on the cases, conditions and expected results included in the suite.
In the hypothetical release, existing tests might confirm that known recordings produce expected outputs. That would not establish performance under a newly supported signal condition if the test data contain no representative examples. Conversely, the preprocessing change might leave the relevant clinical behavior unchanged and be supported by a focused comparison. The team needs a reasoned account of which situation applies.
This is where evidence applicability becomes a development decision. If the current evidence does not address the proposed expansion, the company can narrow the release, obtain the missing evidence or defer the affected feature. It need not automatically repeat every previous study. It does need to explain why the evidence retained for this release still answers the questions that matter.
For the display change, the corresponding question concerns the user’s interaction with the output. The evaluation should address any changed reliance or critical task, rather than treating an unchanged algorithm as proof of an unchanged clinical workflow.
These are Zaliance’s recommendations for organizing the assessment. They help the team choose work that resolves uncertainty instead of adding tests merely to make the release package look more substantial.
Keep the submission decision connected to the assessment
For a device subject to the US 510(k) pathway, the regulatory threshold includes modifications that could significantly affect safety or effectiveness and major changes in intended use. The regulation also provides an exception for changes consistent with a cleared PCCP. [1]
FDA’s software-change guidance recommends considering intended and unintended effects, individual changes and their combined effect. It also explains why successful verification and validation do not, by themselves, establish that a new submission is unnecessary. [2]
That distinction is important in the hypothetical example. A study could convincingly demonstrate a beneficial new capability while the change still crosses the submission threshold. “The results passed” would answer the performance question, not settle the regulatory one.
Equally, a conclusion that no new 510(k) is required does not establish that the release is ready. The company still needs adequate support for the changed product and a sound basis for accepting any remaining limitations. The submission assessment and the release assessment inform one another, but neither substitutes for the other.
This is why Zaliance recommends starting the regulatory analysis before the test program is complete. Its assumptions can influence the release scope, evidence plan and commercial schedule. Unexpected test results may then require the analysis to be revisited. [2]
A narrower release needs its own rationale
Suppose the team can support the display improvement but has not resolved the preprocessing change. Separating the changes may preserve some customer value while the other work continues.
The separation must exist in the product, not just in the release notes. The candidate build needs to exclude the deferred behavior, and its tests and assessment need to correspond to that configuration. If the display depends on outputs created by the new preprocessing, the two changes may not be independently releasable.
This also changes the discussion with commercial teams. The choice is no longer simply “on time” or “late.” It becomes a choice among a supported narrower release, additional development and evidence work, or a different regulatory schedule. Those alternatives can be considered earlier and communicated more accurately.
Make the decision about the version being released
The final release discussion should connect the actual candidate version to the change assessment, supporting results, unresolved issues and regulatory conclusion. It should explain why the remaining uncertainty is acceptable for the proposed use.
FDA’s device-software submission guidance recommends documenting differences between tested and released versions and assessing their potential safety and effectiveness impact. Its treatment of unresolved anomalies likewise connects acceptance to the intended use and risk rationale. These are premarket documentation recommendations, but they illustrate why “tested” and “ready” are incomplete descriptions without a version and a decision behind them. [3]
A capable software team can move quickly. The release process earns that speed when the important questions are resolved while there is still time to change scope, rather than discovered after the build is ready to deploy.
References
[1] 21 CFR 807.81(a)(3) and (b)(1)(ii). Current regulation; eCFR displayed up to date October 19, 2026.
https://www.ecfr.gov/current/title-21/section-807.81
[2] FDA. Deciding When to Submit a 510(k) for a Software Change to an Existing Device. Final guidance, October 25, 2017. Section IV, principles 2–7, printed pp. 6–8 (PDF pp. 10–12 in the current file with QMSR cover notice).
https://www.fda.gov/media/99785/download
[3] FDA. Content of Premarket Submissions for Device Software Functions. Final guidance, June 14, 2023. Section VI, Software Version History and Unresolved Software Anomalies, printed pp. 26–28 (PDF pp. 30–32 in the current file with QMSR cover notice).
https://www.fda.gov/media/153781/download