Medical device software testing services

What does medical device software testing cover?

It covers the runs that generate regulatory evidence, and the record structure that keeps each run readable after the people who ran it have moved on. The test case is the middle of a chain. Behind it sits a hazard somebody entered in the risk file. In front of it sits the build identifier and the configuration the run executed against. A result that cannot be followed in both directions is work that happened and evidence that does not exist.

Two decisions set the size of the work before a single test case is written.

The first is the safety class, and IEC 62304 assigns it at clause 4.3 per software item rather than once for the product. Each requirement then carries its own class marker in the clause text, so depth is uneven across one codebase by design. A team that tests every item to the strictest class spends effort the file never asks for. A team that tests every item to the lightest carries a gap nobody has written down. Working out where the boundaries between items fall, and recording the reasoning beside each letter, is part of the engagement rather than a preliminary to it. The clause set each class binds is set out separately.

The second decision is what governs the finished product. IEC 62304 covers the software life cycle and stops short of validating and releasing the device itself, which is a separate obligation living in a separate document. For a product placed on the market without dedicated hardware that document is usually IEC 82304-1, which normatively references IEC 62304:2006 together with Amendment 1:2015 and then adds product level clauses of its own: verification of the product use requirements and of the system requirements in its clause 4, and product validation in its clause 6. What IEC 82304-1 adds on top of the life cycle lists the rest of them.

Which products does this apply to?

Software that meets the device definition in the market you ship into. The architecture matters less than the intended purpose written on the product, so two systems built the same way can sit on different sides of the line.

The clearest case is software that is itself the device, where the whole product sits inside the regulatory file. A telemedicine platform crosses into the same obligations when it stops carrying a clinician's decision and starts producing one, through triage, scoring or a recommendation. Record systems, portals and billing products usually stay outside the definition. Where one component of such a system begins interpreting patient data, the boundary runs through the product rather than around it, and the per item scoping above is what draws it.

Which standards does the testing close, and which stay open?

The runs close the clauses that ask for evidence of verification and validation. They leave open the clauses that ask for a plan, a specification or a decision, and both sets are read in the same assessment.

For IEC 62304, ISO 14971, IEC 62366-1, IEC 82304-1, EU MDR and ISO 13485, what test runs produce and what stays with the manufacturer.

Standard	What the runs produce	What stays with you
IEC 62304	Verification records across the clause set each item's class binds, including clause 7.3, Verification of risk control measures	The classification per item, the development plan, the architecture the plan describes
ISO 14971	Evidence that each risk control was implemented, and separate evidence that it works	The risk management plan naming those activities, and the residual risk judgement
IEC 62366-1	The summative evaluation and the analysis of the use errors and use difficulties it surfaced	The use specification, the selection of hazard-related use scenarios, the usability engineering file
IEC 82304-1	Verification of use requirements at clause 4.3 and of system requirements at clause 4.6, and the validation run at clause 6.2	The validation plan and the validation report as controlled documents, alongside the instructions for use they belong with
EU MDR	Evidence identified by name and location for the Annex II Section 4 conformity table	The intended purpose statement and the classification argument that the table is built on
ISO 13485	Design verification and design validation records inside the design and development file	The quality management system that controls those records

The MDR states its entire software process obligation in one sentence. Annex I Section 17.2 requires that "the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation". It names five things and prescribes a method for none of them, which is why the standards in that table are what an assessor reads instead.

Applying IEC 62304 does not hand you a presumption of conformity with that sentence. The Annex to Commission Implementing Decision (EU) 2021/1182, as consolidated at 7 April 2026, runs to 51 numbered entries and contains no software standard: 62304, 82304 and 62366 appear nowhere in it. Each is expected as evidence a notified body reads, which is a different thing from a legal presumption, and how the MDR reaches software covers the rest of that route.

ISO 14971 clause 7.2 asks for two verifications of every risk control, one that it was implemented and one that it is effective, and the two do not live in the same place. ISO/TR 24971 subclause 4.4.7 puts verification of implementation in design review, approval of specifications or design and development verification, and says verification of effectiveness "can require the collection of clinical data, usability studies, etc., as part of design and development validation in a quality management system". A suite that produces only the first of the pair leaves the second to be discovered by whoever reads the file. The plan side is explicit as well: ISO/TS 24971-2 subclause 4.4 itemises what the risk management plan has to contain, and item (f) is "activities for verification of the implementation and effectiveness of risk control measures". Our test plan is written against that item, which is why it is read beside the risk file it answers to rather than on its own.

IEC 62366-1 divides its evaluation in two, and only one half is evidence. A formative evaluation explores the interface during design. A summative evaluation is conducted at the end of user interface development to obtain objective evidence that the interface can be used safely. Amendment 1 rewrote the analysis requirement at clause 5.9 so that the manufacturer identifies all use errors and use difficulties that occurred and determines the root cause of any that can lead to a hazardous situation. A session that logs failures and stops short of their causes leaves that subclause open. Which hazard-related use scenarios enter the session is itself a record: the amended clause 5.5 requires a summary of the selection scheme, the rationale for using it and the results of applying it to be stored in the usability engineering file.

On the US side the design controls moved recently. Since 2 February 2026, 21 CFR part 820 has been the Quality Management System Regulation and incorporates ISO 13485:2016 by reference. Section 820.10(c) reaches class II, class III and listed class I devices, and it names "devices automated with computer software" among them, so a class I product answers to Clause 7.3 on account of its software alone. Design output and verification sit at clause 7.3.4 and design validation at clause 7.3.7, so one artefact covering both is answering a question the standard asks twice.

What will you receive?

Runs that can be re-entered from either end, and the trace that lets you do it. The artefact list above is the set. What separates it from a folder of test reports is that each row in the trace names a hazard on one side and a build identifier on the other, so a question asked about either one has a single answer rather than a reconstruction.

That trace is built while the runs happen. Rebuilding it afterwards means going back to people who have to remember which build a screenshot came from, and the answer arrives as an opinion. Building it during execution costs a field on a result record. The choice is made once, at the point the suite is designed.

IEC 82304-1 gives a second reason to build the trace as the runs happen, and it applies even where your house method differs from the standard's. Its subclause 1.3 permits alternative methods where the standard references other standards, on condition that the process results of those methods, "including traceability, are demonstrably equivalent" and the residual risk stays acceptable. Traceability sits inside the condition, so the trace is what carries an alternative method through an assessment. The index that gives each of these artefacts an identity and a place in your technical documentation is covered under validation documentation.

Test data is the part most teams raise first. What we can accept from you, and the terms that would have to cover any protected health information, are not settled on this page.

How does this fit the release process you already run?

The work attaches to the change rather than to the calendar. IEC 62304 keeps running after release: clause 6 covers maintenance and clause 9 covers problem resolution, and neither of them closes while the product is still on sale. IEC 82304-1 numbers software maintenance at clause 8.2 and re-validation at clause 8.3 separately, so a maintained product and a re-validated one are two different claims about the same release.

The decision worth making once, in writing, is which classes of change reopen which evidence. We write that rule with your team and then run against it: a change inside a strictly classified item reopens more of the suite than a change inside a lightly classified one, and both reopen the trace rows that point at them. Regression testing in a regulated environment covers how the suite is kept current between releases.

IEC 82304-1 defines one of its own verbs in the Foreword: "establish" means to define, document, and implement. A convention your team follows without writing it down does not meet that word, and the gap surfaces during an assessment as a missing document rather than as a missing activity.

Automation earns its place where a run has to be repeated against a new build, which is where the forward half of the trace is generated anyway. The build identifier and the artefact version are captured by the pipeline that executed the run, rather than typed into a report afterwards by whoever writes it up.

The clause and article numbers above were checked on 2 September 2026 against the primary text of each standard and regulation.