Can your quality system reconstruct a SaMD release?
A cardiovascular software manufacturer is asked to explain the evidence supporting a version already in use. The team can find the code, several successful test runs and an approval in its quality system. Yet the records do not clearly establish that the approved build, the tested configuration and the deployed product are the same.
That is a difficult problem to solve after the fact. More screenshots may show that work occurred without showing which work supports the device in the field.
For software as a medical device, a useful quality system preserves the connections needed to reconstruct that decision. It should let someone who was not in the release meeting understand what was accepted, why it was accepted and what was actually put into use.
Follow a deployed version back to its evidence
Consider a hypothetical cloud-based cardiovascular analysis product. Its release record identifies version 4.2, the code repository contains a matching tag, and the test dashboard shows a passing run. However, the run used a different configuration from production, and the deployment record points to a configuration file that has since been overwritten.
The version label is consistent; the evidence is not yet complete. The reviewer cannot determine whether the configuration difference affects the clinical function, whether it was evaluated, or which configuration was active when a particular result was produced.
A release identifier is therefore a starting point. The useful record connects it to the relevant code, dependencies and configuration; the evidence evaluated for that combination; the disposition of remaining issues; and the acceptance and deployment decisions. The appropriate level of detail follows the product and its risks. A setting that changes analysis behavior has a different significance from a setting that changes an administrator’s display preference.
Zaliance recommends testing this connection with an actual historical release. Can the manufacturer retrieve the supporting evidence without relying on the recollection of the engineer who deployed it? Where the answer depends on personal memory, the quality system has identified a weakness worth addressing.
QMSR provides the framework; the company designs the evidence flow
FDA’s Quality Management System Regulation became effective on February 2, 2026. It incorporates ISO 13485:2016 alongside FDA-specific provisions. Under 21 CFR 820.10, manufacturers subject to the regulation must document a QMS meeting the applicable requirements. [1,2]
The practical challenge for a SaMD company is how its daily work supplies that system. Requirements may live in one application, code and reviews in another, tests in an automated service and deployments in a cloud environment. Outsourced developers may hold additional records.
Those arrangements can support a coherent quality system. They can also leave gaps between activities that appear complete within each tool. A completed development ticket may establish that someone performed a task while leaving the acceptance of its result unclear. A test report may contain convincing results while failing to identify the configuration that produced them.
The release-reconstruction approach described here is Zaliance’s way of examining those connections. It is not a separate QMSR-mandated document or a requirement to buy a particular platform.
Preserve the evidence where it is useful
Copying every record into a document repository can create a second problem: the exported copy becomes detached from its context, while the original continues to change. A screenshot may omit the test inputs, build identity or later disposition of a failure.
For assurance of production and QMS software, FDA’s February 2026 guidance recommends using suitable digital records rather than duplicating evidence in screenshots or paper. It emphasizes the reliability and availability of those records and the evidence needed to support the software’s intended use. [3]
That does not make an application a dependable system of record merely because it retains history. The manufacturer needs to understand what the tool preserves, what can be changed, who can change it and what happens when an account, supplier or service is retired.
For the hypothetical product, a controlled reference to retained test results may be more useful than a PDF containing only “passed.” The reference should still resolve to the relevant results later. If the service cannot preserve that evidence for the needed period, an appropriate export and retention approach becomes part of the solution.
Confidence in the tool is different from confidence in the device
A test service could accurately execute every configured test while the test set fails to address an important clinical condition. Conversely, a sound test design may provide unreliable evidence if results are associated with the wrong build.
These are different problems. The first concerns the adequacy of the product evaluation. The second concerns confidence in the process producing or retaining its evidence.
FDA’s computer software assurance guidance addresses production and QMS automation; it expressly excludes recommendations for design and development verification or validation of device software functions. [3] Applying that guidance to a quality tool does not establish that a cardiovascular algorithm is clinically valid.
For a tool that contributes to the quality record, Zaliance recommends examining the function actually relied upon. If a reporting service aggregates results from several test environments, what could cause it to omit a failed run or label the wrong version? The assurance work should address that use. A vendor’s broad statement that the platform is validated leaves the manufacturer’s particular configuration and reliance unresolved.
Connect acceptance to deployment
An approval is most useful when its subject is clear. “Release approved” needs a stable connection to the configuration and evidence that the approver considered. Otherwise, a later reader may see approval without being able to establish what it covered.
FDA’s device-software submission guidance recommends identifying differences between tested and released versions and assessing their potential effect. It also describes the rationale expected for unresolved anomalies. [4] These recommendations concern premarket documentation; they help illustrate the underlying distinction between having a test result and knowing which released product it supports.
For the hypothetical company, resolving the problem could involve preserving configuration history, tying test and acceptance records to that history, and recording deployment against the accepted baseline. If a subsequent operational change affects that baseline, its own record must make the relationship understandable. The company should not discover the change only when reconstructing a complaint months later.
A quality system that can follow those connections supports more than an inspection response. It helps the manufacturer assess the reach of a field issue, identify which versions need attention and avoid repeating work whose original evidence is still applicable. Its value lies in making the history of the deployed product usable when the next decision depends on it.
References
[1] FDA. Quality Management System Regulation (QMSR). Updated February 2, 2026.
https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr
[2] 21 CFR Part 820, particularly sections 820.7 and 820.10. Current regulation.
https://www.ecfr.gov/current/title-21/part-820
[3] FDA. Computer Software Assurance for Production and Quality Management System Software. Final guidance, February 3, 2026. Section III, printed p. 4 (PDF p. 7); Section V.A(6), printed pp. 17–20 (PDF pp. 20–23).
https://www.fda.gov/media/188844/download
[4] 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