IVDR software validation requirements

What does the IVDR require from software?

Two sentences carry the whole obligation. Article 5(2) requires a device to meet the general safety and performance requirements in Annex I that apply to it, taking its intended purpose into account. Article 5(3) adds that demonstrating conformity with those requirements has to include a performance evaluation in accordance with Article 56. Everything else on this page is evidence for one of those two sentences.

Software is a form a device can take rather than a special category. Article 2(2) lists "software" alongside reagents, instruments and systems in the definition of an in vitro diagnostic medical device, and none of the 74 definitions in Article 2 defines software separately. Whether your product is inside the IVDR at all turns on the same intended purpose test, which decides whether an app is a medical device in the first place.

The design requirement is Annex I, Chapter II, Section 16, "Electronic programmable systems". It runs to four subsections, and that is the whole of what the IVDR says about how software is built.

IVDR Annex I requirements 16.1 to 16.4 for electronic programmable systems, with what each subsection requires of software.

Annex I	What it requires
16.1	Repeatability, reliability and performance in line with the intended use, and means to eliminate or reduce risks in a single fault condition
16.2	Development in accordance with the state of the art, taking account of development life cycle, risk management, information security, verification and validation
16.3	Design for mobile computing platforms that accounts for screen size and contrast ratio, and for varying light and noise
16.4	Minimum requirements for hardware, IT network characteristics and IT security measures, including protection against unauthorised access

section 16.2 names five principles and no standard. "State of the art" is the only benchmark the text gives, which is what makes the harmonised standards question below a short one to answer.

section 16.4 obliges the manufacturer to set out minimum requirements, so the specification itself is the auditable object rather than the controls behind it. The same content has to reach the user: Annex I section 20.4.1, point (ah), puts those minimum requirements in the instructions for use.

Three requirements outside Section 16 land on software as well. Section 13.2(d) covers the risks of negative interaction between software and the IT environment it operates in. Section 13.2(f) covers incorrect identification of specimens and erroneous results. Section 13.5 requires interoperability and compatibility to be reliable and safe for devices intended to operate together, and Article 2 defines both of those words, at points (18) and (19).

Risk management is Annex I Section 3, restated as a duty in Article 10(2), and it is described there as a continuous iterative process across the entire lifecycle. Article 2(16) defines risk as the combination of the probability of occurrence of harm and the severity of that harm, which is the wording of definition 3.18 in ISO 14971. Article 2(67) then extends "incident" to any harm following a medical decision taken or not taken on the basis of information or results provided by the device. A wrong number on a screen is inside the vigilance system.

Which rule classifies your software?

The same seven rules that classify a reagent. Annex VIII holds ten implementing rules and seven classification rules, and not one of the seven mentions software. Article 47(1) sets four classes, A to D, decided by intended purpose and inherent risk.

Implementing rule 1.4 is the entire software mechanism, in two sentences: "Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right."

There is no IVDR counterpart to Rule 11 of Annex VIII to the MDR. A reader arriving from the EU MDR software requirements goes looking for the software-specific classification rule and finds nothing, because the absence runs across the whole of Annex VIII. Under the IVDR the class comes from what the result is used for, through the ordinary rules.

The rules themselves, in the order Annex VIII sets them out:

IVDR classification rules 1 to 7, with what each rule covers and the risk class from A to D it assigns.

Rule	What it covers	Class
1 (2.1)	Transmissible agents in blood, components, cells, tissues or organs for transfusion or transplantation; agents causing a life-threatening disease with high risk of propagation; infectious load where monitoring is critical	D
2 (2.2)	Blood grouping, foeto-maternal incompatibility and tissue typing	C, and D for the ABO, Rhesus, Kell, Kidd and Duffy markers
3 (2.3)	Thirteen listed purposes, including companion diagnostics, cancer screening and staging, human genetic testing, and management of a life-threatening condition	C
4 (2.4)	Self-testing; near-patient testing classified in its own right	C, with pregnancy, fertility, cholesterol and the listed urine analytes at B
5 (2.5)	General laboratory use products, instruments intended for in vitro diagnostic procedures, specimen receptacles	A
6 (2.6)	Everything the rules above do not reach	B
7 (2.7)	Controls without a quantitative or qualitative assigned value	B

Two consequences follow for a budget. Rule 3(f) makes every companion diagnostic at least class C, software included. Rule 6 means independent IVD software that escapes Rules 1 to 5 lands at class B rather than nowhere, so there is no self-declaration route by default. Article 48(10) lets a manufacturer of a class A device issue the EU declaration of conformity on its own technical documentation, unless the device is placed on the market in sterile condition; class B, C and D go through a notified body under Annex IX. A class C device gets the technical documentation assessment for at least one representative device per generic device group, while Annex IX section 5.2 applies it to every companion diagnostic.

MDCG 2019-11 rev.1 and MDCG 2020-16 rev.4 work the same mechanism through examples. Both are endorsed by the Medical Device Coordination Group, both state on their own front matter that they are not European Commission documents and are not legally binding, and both say only the Court of Justice of the European Union can give binding interpretations of Union law. Read as illustration, MDCG 2019-11 rev.1 section 5.2 places software that classifies a cervical cytology smear as normal or suspicious at class C per Rule 3(h), and software interpreting a line immunoassay confirming antibodies to HIV-1, HIV-1 group O and HIV-2 at class D per Rule 1. The guidance adds its own caveat that these are for guidance purposes and are not a confirmation of the final classification of any device.

What has to be proven about performance?

Article 56(3) requires a performance evaluation to demonstrate three things: scientific validity, analytical performance and clinical performance. The data and conclusions drawn from assessing those three elements constitute the clinical evidence for the device. Each one has its own section of Annex XIII and its own report.

The three IVDR performance evaluation components in Annex XIII Part A, with the evidence each may rest on and the report it produces.

Component	Where it lives	What it may rest on	Report
Scientific validity	Annex XIII, Part A, 1.2.1	Five named sources, from information on devices measuring the same analyte through to clinical performance study results	Scientific validity report
Analytical performance	Annex XIII, Part A, 1.2.2	Analytical performance studies as a general rule, against the parameters in Annex I 9.1(a)	Analytical performance report
Clinical performance	Annex XIII, Part A, 1.2.3	Clinical performance studies, peer-reviewed literature, or published experience from routine diagnostic testing	Clinical performance report

The parameters are listed rather than left to judgement. Annex I section 9.1(a) names analytical sensitivity and specificity, trueness, precision, accuracy, limits of detection and quantitation, measuring range, linearity, cut-off, interference and cross-reactions. Section 9.1(b) names diagnostic sensitivity and specificity, positive and negative predictive value, likelihood ratio, and expected values in normal and affected populations. section 1.2.2 of Annex XIII, Part A, requires demonstration against every parameter in 9.1(a) unless an omission is justified as not applicable, so a gap in that list is a documented decision or a finding.

Two further points bind a release plan. Article 56(4) makes clinical performance studies the default and requires a documented justification for relying on other sources. Article 56(6) requires the performance evaluation report for class C and class D devices to be updated at least annually with post-market data.

Annex XIII, Part A, section 1.1 carries one item written for software alone: the performance evaluation plan has to include an identification and specification of the reference databases and other sources of data used as the basis for the device's decision making. For a model whose behaviour depends on its training and reference data, that item is where the validation of the model itself gets tied to the regulatory file. Section 9.4 adds that characteristics and performances are specifically checked for self-testing, with performances obtained by lay persons, and for near-patient testing in the relevant environments.

Which of that is checked by testing?

Annex II section 6.4 is the one place the technical documentation asks for software testing by name. It requires evidence of validation of the software as it is used in the finished device, summary results of verification, validation and testing performed in-house and applicable in an actual user environment before final release, and coverage of all the different hardware configurations and, where applicable, operating systems identified in the labelling.

A labelled operating system with no test evidence behind it is a gap an assessor finds by reading the label.

IVDR Annex I and Annex II software requirements set against what a test run has to demonstrate for each.

Requirement	What a test run has to demonstrate
Annex I 16.1	The same input produces the same result across runs, and a single fault condition drives the software to a defined state rather than to a plausible wrong result
Annex I 16.4	The published minimum hardware, network and security requirements are the ones the software actually needs, and access control holds when they are met
Annex I 13.2(f)	Specimen identity survives every path from order to reported result, including the error and retry paths
Annex I 13.5	Two connected devices exchange information without changing the content of the data, which is the Article 2(19) test for interoperability
Annex II 6.4	Every hardware configuration and operating system in the labelling was exercised, rather than the reference build alone
Annex II 6.5(d)	The combination with the equipment the device connects to conforms to Annex I, with the characteristics the manufacturer specified

Annex XIII, Part A, section 2.3.3 sets the standard a clinical performance study report is held to, and it is a useful bar for any test report going into this file: it has to contain enough information to be understood by an independent party without reference to other documents, to include negative findings, and to record protocol deviations and data exclusions with their rationale.

Which artefacts will the assessor ask for?

The GSPR conformity matrix comes first. Annex II section 4 requires the applicable general safety and performance requirements with an explanation of why the others do not apply, the method used to demonstrate conformity with each one, the harmonised standards, common specifications or other solutions applied, and the precise identity of the controlled documents offering evidence, cross-referenced to their location in the full technical documentation. An assessor reads that table before anything else, and everything in the deliverables list above hangs off a row of it.

After it come the performance documents. Annex II section 6.2 requires the performance evaluation report including the three subordinate reports and an assessment of them, with the clinical performance study documents included or fully referenced. Section 6.1.3 requires the analytical performance report separately. Annex XIII, Part A, section 1.3.2 defines what the performance evaluation report itself contains, including the literature search protocol and report, the technology the device is based on, and the claims made about its performance.

Three smaller items are asked for often and prepared late. Annex II section 1.1(k) requires a description of any software used with the device. Section 3.1(d) requires, for software, a description of the data interpretation methodology, namely the algorithm. Section 1.1(f) requires the risk class with the justification of the classification rules applied. Article 10(7) then keeps the whole file available to competent authorities for at least ten years after the last device covered by the declaration of conformity was placed on the market.

Building those documents alongside the test runs rather than after them is what validation documentation work consists of.

Does IEC 62304 give you presumption of conformity?

No. Article 8(1) grants presumption of conformity to devices in conformity with harmonised standards, and its second subparagraph extends the same mechanism to process requirements, naming quality management systems, risk management, post-market surveillance, performance studies, clinical evidence and PMPF. The IVDR harmonised standards list is the Annex to Commission Implementing Decision (EU) 2021/1195.

No software standard appears on that list. There is no IEC 62304 for software life cycle, no IEC 62366 for usability, and no IEC 81001-5-1 for health software security. The software-adjacent entries are EN ISO 13485:2016 with AC:2018 and A11:2021, EN ISO 14971:2019 with A11:2021, EN ISO 20916:2024 for clinical performance studies using specimens from human subjects, EN ISO 17511:2021 for metrological traceability, and the EN ISO 18113 labelling series.

The practical effect sits on GSPR 16.2. With no harmonised software standard to claim, conformity has to be argued as state of the art, and IEC 62304 then serves as evidence of what the state of the art is rather than as a shortcut past the argument. Write the argument down. Where the Commission has adopted common specifications, Article 9(3) requires compliance with them unless you can duly justify solutions that reach an at least equivalent level of safety and performance.

Which dates still apply to a device already on the market?

The Regulation has applied since 26 May 2022 under Article 113(2), and the transitional provisions in Article 110 are what most software teams are actually living under. Those provisions have been rewritten since they were first drafted, so a date taken from a 2022 source is likely to be stale.

Four acts have amended the IVDR: Regulation (EU) 2022/112, Commission Delegated Regulation (EU) 2023/503, Regulation (EU) 2023/607 and Regulation (EU) 2024/1860. Two of them move dates a software team plans around. Regulation (EU) 2023/607 rewrote Article 110(4), so devices lawfully placed on the market before 26 May 2022 may continue to be made available or put into service without the former one-year sell-off limit. Regulation (EU) 2024/1860 wrote the deadlines in the table below. Delegated Regulation (EU) 2023/503 reaches only Article 44(10), which sets a full re-assessment of a notified body every five years.

IVDR transition deadlines under Article 110 for devices already on the market, from 31 December 2027 to 31 December 2029.

Situation	Deadline	Where
Device holding a Directive 98/79/EC certificate valid under Article 110(2)	31 December 2027	Article 110(3a)
Class D device that needed no notified body under the Directive	31 December 2027	Article 110(3b)(a)
Class C device in the same position	31 December 2028	Article 110(3b)(b)
Class B device, and class A placed on the market in sterile condition	31 December 2029	Article 110(3b)(c)

Article 110(3c) attaches six cumulative conditions to those extensions. Two of them decide whether a software team keeps the extension at all: point (b) requires that there are no significant changes in the design and intended purpose, and point (d) required a quality management system under Article 10(8) to be in place no later than 26 May 2025. Points (e) and (f) set the notified body application deadlines of 26 May 2025, 26 May 2026 and 26 May 2027 by class, with signed agreements four months later in each case. Article 110(3d) then applies the IVDR's own post-market surveillance, market surveillance, vigilance and registration requirements to those devices already, in place of the Directive's, so a legacy device is running under two regimes at once.

The in-house exemption has its own timetable. Article 5(5) lifts the rest of the Regulation for devices manufactured and used only within one health institution, while keeping the Annex I requirements, and Article 48(2) confirms that such devices skip conformity assessment. Its nine conditions arrived in stages. Article 113(3)(i) applies points (b) and (c) and (e) to (i) from 26 May 2024. Article 113(3)(j) applies point (d), the justification that no equivalent device is available on the market, from 31 December 2030. That date read 26 May 2028 when Regulation (EU) 2022/112 wrote it, and Regulation (EU) 2024/1860 replaced it. The exemption also stops at two edges: it does not apply to devices manufactured on an industrial scale, and point (a) fails the moment a device is transferred to another legal entity.

Eudamed is the one date not to write down. Article 113(3)(f) keys the electronic system obligations to six months from a Commission notice published under Article 34(3) of Regulation (EU) 2017/745, with registration of devices a further six months after that and notified body certificate entry a further twelve. Any calendar year attached to Eudamed has to be traced back to that notice.

Sequencing all of this against a launch date is the substance of entering the EU market with a diagnostic product.

Where does a notified body review go wrong?

• The classification rationale names a class and no rule, so nobody can check whether implementing rule 1.9 would have pushed the device to a higher class.
• Software that drives an analyser is filed at the analyser's class without the analyser's own class or rule being recorded, which leaves rule 1.4 asserted rather than applied.
• The performance evaluation report exists as one document with the three subordinate reports folded into it, and scientific validity is claimed in a paragraph rather than demonstrated against the sources Annex XIII, Part A, section 1.2.1 allows.
• Parameters from Annex I section 9.1(a) are absent from the analytical performance report with no justification of non-applicability beside them.
• The performance evaluation plan does not identify the reference databases the software uses for decision making, although Annex XIII, Part A, section 1.1 lists that item for software specifically.
• Software verification evidence covers the reference build while the labelling names several operating systems, which Annex II section 6.4 asks about directly.
• IT security controls are implemented and never written out as the minimum requirements GSPR 16.4 asks for, so nothing reaches the instructions for use at section 20.4.1(ah).
• A class C performance evaluation report carries no update inside the last twelve months, against the annual cadence in Article 56(6).
• A change ships during the Article 110 transition without any assessment of whether it is a significant change in design or intended purpose under point (b) of Article 110(3c).

What do we run against the IVDR?

The work starts at the classification, because the class decides the conformity assessment route, the update cadence for the performance evaluation report, and whether a notified body reads the technical documentation at all. From the class we derive the Annex I requirements that apply, then build the test suite and the record structure that feed the GSPR matrix rows and the three performance reports.

The testing itself is described under medical device software testing. What it produces here is evidence in the shape Annex II expects: verification and validation results tied to labelled configurations, security specifications an assessor can compare against the instructions for use, and traceability from every Annex I requirement to the document that answers it. The conformity decision stays with the manufacturer, and Article 10 keeps it there.

Article, annex and rule numbers on this page were read on 2 September 2026 in the consolidated text 02017R0746 of 10 January 2025, served by the EU Publications Office. The authentic act is Regulation (EU) 2017/746 as published in the Official Journal; the consolidated version has no legal effect of its own.