IEC 82304-1 health software testing requirements

Does IEC 82304-1 replace IEC 62304 for your product?

No. IEC 82304-1:2016 names IEC 62304 as its only normative reference and puts a layer of product clauses on top of it. clause 2, Normative references carries exactly two entries, IEC 62304:2006 and IEC 62304:2006/AMD1:2015. ISO 14971, IEC 62366-1 and ISO 13485 are all absent from that list, although each of them appears in the Bibliography.

The standard says as much in its own words. The Introduction reads: "This document relies heavily on IEC 62304:2006 and IEC 62304:2006/AMD1:2015 for the software development process which can be applied to health software products."

Clause 5 runs to a single page and is titled "Health software: software life cycle processes", which is IEC 62304's title with the subject swapped. clause 1.2 turns that swap into a reading rule for every standard the document references: "In each referenced standard, the term 'medical device' or 'medical device software' is to be substituted by the term 'health software' or 'health software product', as appropriate."

The life cycle work therefore stays where it already was. What IEC 62304 asks of software testing applies here unchanged, read with that substitution. What IEC 82304-1 adds sits above it, at the level of the product a user installs.

The eight numbered clauses of IEC 82304-1:2016, as printed on the Contents page of the publisher preview. Titles are reproduced with a colon where the standard prints a dash, and with defined terms in lower case where the standard prints them in small capitals, a convention its Foreword states.

Clauses 1 to 8 of IEC 82304-1, with the title of each clause and the subclauses it holds.

Clause	Title	Subclauses
1	Scope	1.1 to 1.3
2	Normative references	none
3	Terms and definitions	3.1 upward
4	Health software product requirements	4.1 to 4.7
5	Health software: software life cycle processes	none listed
6	Health software product validation	6.1 to 6.3
7	Health software product identification and accompanying documents	7.1, 7.2
8	Post-market activities for the health software product	8.1 to 8.5

Annex A, Rationale, is the only annex and it is informative, so nothing in it binds. It holds Table A.1, "Examples of software (SW) in or not in the scope of this document", which the Introduction points the reader at by name.

Is your product inside the scope of IEC 82304-1?

The test is whether the product ships as software alone. clause 1.1, Purpose reads: "This Part of 82304 applies to the safety and security of health software products designed to operate on general computing platforms and intended to be placed on the market without dedicated hardware, and its primary focus is on the requirements for manufacturers."

Subclause 1.2 then excludes three families outright: medical electrical equipment or systems covered by the IEC 60601 and IEC 80601 series, in vitro diagnostic equipment covered by the IEC 61010 series, and implantable devices covered by the ISO 14708 series. Anything that ships inside a box answers to those instead.

Mobile products are named in. The note to 1.2 reads: "This document also applies to health software products (e.g. medical apps, health apps) intended to be used in combination with mobile computing platforms." An app distributed through a store is the case the clause was written for, which is why testing health apps across real devices and OS versions is where clause 4.6 evidence usually comes from.

Step 5 is the one teams skip. The Introduction states: "Whether a health software product has to meet regulatory requirements is a matter of national legislation. This document makes no attempt to determine whether a health software product is or should be regulated." Conformity to IEC 82304-1 settles no classification question, and whether your app is a medical device is decided by the law of the market you sell into.

Which clauses can testing produce evidence for?

Four subclauses across clauses 4, 6 and 8 are where test evidence lands, and the standard warns against expecting more from testing than that. Its Introduction reads: "Testing of the finished product is not, by itself, adequate to address the safety of health software. Therefore, requirements for the processes by which the health software is developed are necessary."

Two subclauses of clause 4 are verification subclauses in their own right, and clause 6 is validation. IEC 82304-1 keeps the two words in separate clauses, so a file that answers one and calls it the other is visibly short. The practical difference between verification and validation on regulated software is the difference between clause 4.3 and clause 6.2 here.

IEC 82304-1 subclauses 4.3, 4.6, 6.2 and 8.3 that testing produces evidence for, with the test output each one receives.

Subclause	Title	What our runs produce against it
4.3	Verification of health software product use requirements	Per requirement results, with the requirement identifier on every case
4.6	Verification of system requirements	Results per named platform, OS version and build identifier
6.2	Performing validation	Execution records against the plan named in 6.1
8.3	Re-validation	The delta run after a post-market change, tied to the release that carried it

clause 8.3, Re-validation is what turns a single engagement into a standing one. The standard gives revalidation after change its own numbered subclause, next to 8.2 software maintenance, so each shipped change carries its own evidence rather than a reference back to the launch report. How much of that can be automated is covered in regression testing for regulated software.

Which documents will an assessor ask for?

Clause 6 and clause 7 name four documents outright, and 7.1 adds an identification record. clause 1.3, Compliance reads: "Compliance with this document is determined by inspection of all documentation required by this document." It adds: "Assessment of compliance is carried out and documented by the manufacturer. Where the health software product is subject to regulatory requirements, external assessment may take place."

Compliance is self-assessed by default, and the assessment is a reading exercise. That places the weight on the four documents IEC 82304-1 titles outright:

Documents IEC 82304-1 names in its subclause titles, from the 6.1 validation plan to the 7.2.3 technical description.

Subclause	Document it is titled after
6.1	Validation plan
6.3	Validation report
7.2.2	Instructions for use
7.2.3	Technical description

Clause 7 also carries 7.1 Identification, which is the only subclause anywhere in the document marked with the asterisk that points at Annex A rationale. Within clause 7, instructions for use is the longest item, running from page 15 to page 17 against one page each for 7.2.1 and 7.2.3.

Subclause 1.3 permits another route: "the manufacturer may use alternative methods to demonstrate compliance with the requirements of this document", where the results "including traceability, are demonstrably equivalent and the residual risk remains acceptable". An equivalence argument stands on traceability, which is the part teams build last and the part an assessor reads first. Validation protocols and traceability matrices are the form that argument takes on paper.

The body text of clauses 4 to 8 sits behind the publisher paywall. Every clause number and clause title on this page comes from the Contents page of the IEC preview. What each clause requires its document to contain is not stated here, because nobody on this side has read it.

Is there an IEC 82304-2 you also have to meet?

No document by that name exists. Part 2 of the series is ISO/TS 82304-2:2021, "Health software, Part 2: Health and wellness apps, quality and reliability", published in July 2021 as a Technical Specification. It was prepared by ISO/TC 215 with IEC/SC 62A and CEN/TC 251, where Part 1 was led by IEC/SC 62A.

The two documents do different work. ISO/TS 82304-2 defines a health app quality label and a scoring method behind it, with quality requirements grouped under five headings in its clause 5: product information, healthy and safe, easy to use, secure data, and robust build. Its clause 2 reads "There are no normative references in this document", where Part 1 invokes IEC 62304. Its scope states: "Outside the scope of this document are guidelines to comply to the medical device regulation."

A quality label is a signal to users and to app assessment organisations. It answers none of the safety clauses in Part 1, and Part 1 produces none of the scoring in it.

Where does an IEC 82304-1 file fall apart?

• Clause 6.1 and clause 6.3 are one document with two headings, written after the runs, so the plan records what was executed rather than what was intended.
• The team reads IEC 82304-1 as a lighter alternative to IEC 62304 and produces no life cycle records, although clause 2 makes IEC 62304 normative.
• Verification under 4.6 covers the developer's platform and nothing the product is actually installed on, on a standard whose scope is general computing platforms.
• The usability section cites IEC 62366-1 as though a clause demanded it, and cites nothing for what the team actually did.
• Instructions for use point at a help centre that changes weekly, with no version of it kept against the release identified under 7.1.
• Releases after the first ship with a changelog and no revalidation record, which is a clause 8.3 gap rather than a clause 6 one.

What do we run against IEC 82304-1?

We start from the platform matrix, because that is where a software-only product differs from a device. Use requirements and system requirements are separated first, so 4.3 and 4.6 evidence does not collapse into one pile. The validation plan is written and agreed before execution, and the validation report references it by section. Each post-market release then gets its own re-validation record under 8.3.

Where a test environment needs data that resembles clinical records, a de-identified or synthetic set removes the question, and where it cannot, the terms come first: that is what how we work with protected health information is for. The output of the engagement is the artefact list above, in the form an assessor reads without a walkthrough.

Clause numbers, clause titles and quotations on this page were read from the IEC publisher preview of IEC 82304-1:2016 on 2026-09-02, together with the European front matter of EN 82304-1:2017 and the FDA recognition record.