The bottom line: without a freeze, the report only answers for the version you submitted
For medical electrical equipment containing software, one sentence cannot be avoided: the test conclusion is valid only for the software version submitted. That is not the laboratory shifting responsibility; it is the basic logic of IEC 62304 and IEC 60601-1. Software is part of the product, so when the software changes, the product changes.
Which leaves two core actions in preparing for submission: freeze the version, and make changes traceable. Do those two solidly and every later conversation has something to stand on. Do them badly and the project circles endlessly around the question of which version was actually tested, and that circling produces no technical value whatsoever.
Write down what "one version" means before anything else
Plenty of teams come apart right here, because everyone understands the word version differently. Development means a particular commit in the repository. Test means the packaged firmware. Marketing means the product version stated externally. The three do not map onto each other, so when a single identifier is declared at submission, the laboratory has no way of knowing which artefact it points at.
The workable practice is to write the version identifier rules onto one page before submission, covering the following points:
- Which segments make up the externally released version identifier, and what causes each segment to change.
- Which segment is meant for the user, and which one is the internal build number.
- Where in the device interface the user can see the version, and whether what appears there is the full identifier or a truncated one.
- Whether the string on the test application form, the string shown in the device interface and the string printed in the accompanying documents are one and the same.
Confirm those four points and the communication overhead drops sharply. A version shown on the device interface that does not match the version printed in the documents is a common reason for a return, and it is entirely avoidable before anything leaves the building.
Change types: what has to be reported, and what forces a re-run
Software will get edited during the testing period. Before editing, look at this table and work out what the change brings with it.
| Change | Effect on completed conclusions | What you have to supply | Common misjudgement |
|---|---|---|---|
| Interface wording, language packs | Generally no effect on electrical safety conclusions | An updated mapping between the accompanying documents and the interface display | Treated as "only text", after which every interface screenshot in the documents is void |
| Alarm logic, limit decisions | Directly affects tests of alarm and safety-related functions | Re-running the related items | Treated as a parameter tweak and not reported |
| Driver layer, communication protocol | May affect electromagnetic compatibility and functional behaviour | Re-assessment against the relevant part, confirmed against the current valid edition of the standard text | Assumed not to need mention because the application layer is untouched |
| Defect fix with no functional change | Depends on whether the defect itself is safety-related | The defect record and an impact analysis | Covered by the phrase "fixed an issue", leaving nothing traceable |
| External component upgrade | Depends on what that component is responsible for | An updated SOUP list and the matching risk assessment | Forgetting that external components are also part of the software |
| Toolchain or compiler option change | The build output differs and the build is no longer reproducible | A reissued build record explaining the difference | Assuming that untouched source code means unchanged software |
The toolchain row deserves a sentence of its own. Identical source built with a different toolchain can produce binaries that differ substantively. If the laboratory or a reviewer asks for evidence that the build is reproducible and all you can produce is the source code, that question stays open, and it will still be open when submission comes around.
Settle the software safety classification before submission
IEC 62304 requires a safety classification to be determined for the software, and that determination drives which process documents have to be submitted and how granular the verification has to be. Two practical points here.
First, the basis for the classification comes from risk analysis, not from a show of hands. The hazards and risk control measures cited in the classification have to be findable in the risk management file maintained under an ISO 14971 framework. If the two do not agree, it will be questioned directly at review, and it cannot be manufactured on the spot.
Second, once the classification is fixed, the submission document list is fixed with it. Discovering at intake that the classification was set high and the material is thin leaves only a scramble; setting it low invites the challenge that the basis is insufficient. Do this step during the planning stage and file the record. The point of filing it is to freeze the reasoning as it stood, so that nobody is left guessing half a year later why it was decided that way.
How the risk management file maps item by item onto test conclusions is a separate topic in its own right, and the approach is set out under testing knowledge rather than here.
What belongs in the submission package
Beyond the sample itself, a submission package for a product containing software should include at least the following. Anything missing buys one more round trip.
- The version identifier rules, together with the full version identifier for this submission.
- The build record: which source state, which toolchain and which configuration produced the artefact being submitted.
- A software function list, marking which functions are safety-related and which are not.
- The SOUP list, with the purpose and origin of each external component and how known issues are handled.
- A list of software-related risk control measures, and the conditions under which each one takes effect.
- Operating instructions for verification: how an engineer reaches each function screen, how to trigger an alarm, and where to read the version.
- Any dedicated host application or debugging tool, supplied along with instructions for its use.
That last item in particular. Many projects stall because the laboratory simply cannot get into some function on the device, while the development side assumes that everyone goes in through the debug tool the way they do. Information like that, left unwritten, is pure lost time, and it is lost on both sides.
There is a simple test for whether traceability is real
Take any test report and see whether you can walk from the version identifier printed on it back to the source state and the build configuration as they stood at the time. If any link in that chain is broken, traceability is not in place. The check needs no tooling; walk it yourself once and you will know.
Breaks tend to occur at three points. The version shown on the device does not match the version declared. The version identifier does not resolve to a definite source state, because the build was taken from the tip of a branch rather than from a tagged point. And the build environment was never recorded, so a different machine cannot produce the same thing. Plug those three in advance and both change assessment and audit response get much easier.
Three failure scenarios and what they cost
Scenario one. The sample arrives at the laboratory, part of the testing is done, and in parallel the development team fixes a few defects and flashes the new firmware onto a spare sample. The two samples then get used interchangeably. The result: the software version behind every completed item is in doubt, everything has to be run again, and the whole schedule is void.
Scenario two. The version identifier printed in the accompanying documents was typed in during layout and does not match the actual firmware. The document verification step returns a non-conformity outright, layout and printing are redone, and the printed packaging artwork is scrapped along with them. That loss usually lands on purchasing while the problem originated in development, which makes the post-mortem a place where fingers get pointed.
Scenario three. An external communication component was bumped by a minor version during the testing period and the team thought nothing of it. When asked later how known issues in that component were handled, they found the issue lists for the two versions differed, the risk assessment had to be redone, and the basis for the software safety classification was affected along with it.
What these three share is that the cost falls nowhere near the testing itself; it falls on rework and scheduling. Writing the version freeze into the project milestones is a far better deal than repairing the damage afterwards. Intake and scheduling are described under testing process, and where something is unclear during preparation, it is worth raising it through technical support before acting.
A note on accreditation scope
Products containing software often end up combining several reports, so one point should be stated plainly: an accreditation mark only demonstrates that the laboratory has the corresponding technical competence within its accredited scope, and does not constitute a commitment regarding market access in the target market. Whether software process documents are accepted by the competent authority in the target market depends on the local review requirements, so it is better to state the target market during the planning stage than to ask once the report is out.
Electromagnetic compatibility items are likewise tied to the software version, and the scope that has to be re-assessed after a change is described under electromagnetic compatibility testing.
The centre of gravity is not the sample
For a product containing software, the centre of gravity in submission preparation is not the sample; it is documentation and version management. Get the version identifier rules, the build record and the SOUP list solid first, and later communication rarely runs into trouble. Leave those three vague, and no amount of sample quality rescues the situation.
To fix the submission document list during the planning stage, or to have someone look over whether your current version management is sufficient, call +86 132 4819 8029 with the product form and the target market, or request a quote directly. SUNGO Lab (Shanghai Shage Medical Technology Co., Ltd.) is a medical device testing laboratory accredited by CNAS, CMA and IAS (USA), with laboratories in Shanghai and Hefei.