Rethinking IVDR Technical Documentation – Part 3 of 4

Introduction

IVDR technical documentation is more than a collection of files. In this four-part series, we examine how digitalization can make regulatory information more actionable, maintainable, and suitable for responsible automation. Part 3 addresses a challenge that begins before any document is written: determining what information the IVDR actually requires for a specific device. 

Let’s look at this from a practical example of two IVD manufacturers checking the requirements of Annex II of the IVDR. 

One is developing an automated quantitative assay for use in a laboratory. The other is developing a qualitative test for use near the patient. Both see the same headings: device description, information supplied by the manufacturer, risk management, performance evaluation and post-market surveillance. 

But the correct information these headings request is very different for the two products.  The IVDR defines a common regulatory framework. Applying that framework requires manufacturers to translate legal provisions into device-specific questions, information requirements, applicability decisions and justifications. 

The IVDR tells manufacturers what their technical documentation must demonstrate. It does not provide a completed questionnaire for every possible IVD. 

Annex II is a Framework, not a Form 

The IVDR requires manufacturers to maintain procedures that keep series production in conformity. Changes in product design or characteristics must be adequately taken into account in a timely manner. The manufacturer’s quality management system must also address the management of device modifications and the selection and control of suppliers and subcontractors. (Regulation (EU) 2017/746, Article 10(8)) 

Article 10(4) requires manufacturers to draw up and keep technical documentation up to date. That documentation must allow the conformity of the device with the IVDR to be assessed and must include the elements set out in Annexes II and III. 

Annex II specifies the principal elements that must be addressed in the technical documentation. These include a detailed description of the device and its specifications, as well as the information supplied by the manufacturer. The documentation must further provide information on the device’s design and manufacturing processes and demonstrate conformity with the applicable General Safety and Performance Requirements.

The manufacturer must document the benefit-risk analysis and risk management activities undertaken for the device, together with the results of product verification and validation. While Annex II focuses primarily on the technical documentation supporting the device, Annex III sets out the documentation requirements relating to post-market surveillance.

These annexes provide a structured regulatory framework, but they do not prescribe a universal set of data fields, questions or evidence requirements that apply identically to every device.  Certain information is required for virtually all IVDs, regardless of their specific characteristics. These requirements form the common basis of the technical documentation and apply across different types of devices.

Additional requirements may depend on the characteristics and intended use of the individual IVD. The intended purpose, intended user, and use environment are relevant factors in determining the information that needs to be provided. The type of specimen used by the device must also be considered.

The nature of the device’s output may further influence the applicable requirements. In particular, a distinction may be made between devices providing qualitative and quantitative results. The measuring principle and the specific configuration of the device can also affect the scope of the required documentation.

Certain requirements are influenced by the device’s risk class, the functionality of any associated software, and the performance claims made by the manufacturer. These characteristics therefore need to be considered when determining the information and evidence required for the individual IVD. The practical task is therefore not merely to reproduce the headings of Annex II. It is to determine what each heading means for the device concerned. 

(Regulation (EU) 2017/746, Article 10(4), Annex II and Annex III.) 

The Intended Purpose Is the First Decision Point 

The intended purpose is sometimes treated as one technical documentation section among many. In practice, it is one of the main drivers of the entire regulatory assessment. 

Annex II requires the intended purpose of the IVD to be described in sufficient detail to clearly define the scope and intended use of the device. This includes specifying what the device is intended to detect or measure and identifying the particular disorder, condition, or risk factor that it is intended to detect, define, or differentiate.

The intended purpose should also describe the function of the device. Depending on its intended application, this may include screening, monitoring, diagnosis or aid to diagnosis, prognosis, or prediction. Where the device is intended to be used as a companion diagnostic, the documentation should also identify the relevant target population and the medicinal product with which the device is associated.

The intended purpose should specify whether the device is automated and whether it provides qualitative, semi-quantitative, or quantitative results. The required specimen type should also be clearly identified, as this forms an important part of defining how the device is intended to be used.

Where applicable, the intended testing population should be specified, together with the intended user of the device. These elements help to establish the boundaries of the intended use and provide the basis for assessing the device’s performance and applicable regulatory requirements.

These variables influence classification, performance requirements, risk analysis, labeling, usability considerations and the type of evidence that must be addressed. 

The analyte or technology alone does not determine the regulatory pathway. 

For example, MDCG 2020-16 rev.4 explains that a device used to screen blood and tissue donations for syphilis falls under a different classification rule in comparison to a device used to diagnose syphilis in an individual. The underlying infectious agent is the same. The intended purpose is not. 

This illustrates why regulatory requirements cannot be determined reliably from a product name or analyte alone. 

Applicability Is a Regulatory Decision 

The IVDR does not expect manufacturers to address every requirement in exactly the same way. 

Annex II, Section 4 requires the technical documentation to identify which General Safety and Performance Requirements (GSPR) apply to the device and to provide a justification for any requirements that are considered not applicable. For each applicable requirement, the manufacturer must explain how conformity is demonstrated and identify the standards, common specifications, or other solutions used to demonstrate compliance.

The documentation should also indicate where the supporting evidence can be found. This means that determining the applicability of the GSPRs is not simply a matter of checking or excluding individual requirements. Rather, each determination should be justified and linked to the relevant conformity assessment approach and supporting evidence.

A generic GSPR checklist can display all possible requirements. It cannot, by itself, determine which requirements apply to a particular device or whether a justification for non-applicability is adequate. 

The specific characteristics of an IVD can give rise to additional considerations when determining the applicable requirements. For example, a self-test requires consideration of lay users, including user comprehension and the conditions of the home environment, whereas a near-patient test must account for professional use outside the traditional laboratory setting. Similarly, a quantitative measuring device raises specific considerations relating to metrological traceability and analytical measuring performance.

Other device characteristics may introduce further requirements. Software can require additional consideration of lifecycle management, validation, interoperability, and information security. A companion diagnostic, in turn, requires information on the associated medicinal product and the relevant target population. These examples illustrate how the characteristics and intended use of a device influence the requirements that need to be addressed in its technical documentation.

“Not applicable” is not an empty field. It is a regulatory conclusion. 

(Regulation (EU) 2017/746, Annex II Section 4 and Annex I.) 

The Same Heading Can Require Very Different Depth 

A template may contain a field titled “performance evaluation”, but that does not define how extensive the underlying information must be. 

Article 56 requires the manufacturer to specify and justify the level of clinical evidence necessary to demonstrate conformity. That level must be appropriate to the characteristics and intended purpose of the device. 

The risk class is relevant, but it is not the only consideration. 

The level of detail required in the technical documentation may also depend on the specific characteristics and context of the device. This includes the claims made by the manufacturer, the clinical function of the result, and the potential consequences of an incorrect result. The intended population and user, as well as the environment in which the device is used, may further influence the depth of the required documentation.

Other relevant factors include the novelty of the analyte or technology and the current state of the art. The availability, relevance, and quality of existing data should also be taken into account when determining the extent of evidence needed to support the device and its claims.

MDCG 2022-2 therefore describes the intended purpose as a key driver of performance evaluation and explicitly notes that risk classification is not the only factor influencing the necessary level of clinical evidence. 

This does not mean that a typical regulatory software can determine automatically whether the available evidence is sufficient. It means that a meaningful digital process must ask more than whether a report has been uploaded. 

(Regulation (EU) 2017/746, Article 56 and Annex XIII Part A; MDCG 2022-2, Sections 3, 5 and 6.) 

Templates Standardize Documents, Not Interpretation 

Templates remain valuable. They can provide common headings, improve consistency and reduce the risk that major sections are forgotten. 

Their limitation is that they generally present a static structure. 

A static template may create difficulties when used as the primary basis for preparing technical documentation. It may include questions that are irrelevant to the particular device or fail to capture requirements that apply only under specific conditions. Where the template does not explain why particular information is requested, it can also make it difficult to understand the regulatory rationale behind the documentation requirements.

Another limitation is that static templates may treat missing information and information that is genuinely not applicable in the same way. They can also encourage the use of generic statements rather than device-specific reasoning and create an appearance of completeness even when the underlying applicability logic has not been adequately addressed. As a result, reliance on a static template can lead both to gaps in the documentation and to unnecessary work where information is collected or assessed without being relevant to the device.

A manufacturer may omit information because a conditional requirement was not recognized. Alternatively, teams may generate extensive content for requirements that are not relevant, simply because the template contains a section for them. 

The challenge is not making the template longer. It is making the information request more context-sensitive. 

Regulatory Requirements Must Become Operational Questions 

Before a regulatory requirement can be answered, it must be translated into questions that the organisation can act upon. 

A broad requirement such as “describe the intended purpose” can be translated into a structured set of operational questions that are specific to the device. These questions may address what the device detects or measures, what information the result provides, and whether its function is intended for screening, diagnosis, monitoring, prediction, or another purpose.

They may also cover the supported specimen types, whether the result is qualitative or quantitative, who operates the device, where it is used, and which population is tested. In addition, the manufacturer’s claims and the device variants that share the same intended purpose need to be considered.

The answers to these questions can then determine which further requirements need to be addressed. For example, they may affect the device classification and the applicable GSPRs, as well as the analytical and clinical performance requirements and the risk controls that need to be implemented.

This might also have implications for labelling, usability, and post-market surveillance. The intended purpose serves not only as a description of the device, but also as an entry point for determining the broader set of regulatory requirements that apply.

This translation work is usually performed by regulatory professionals, either when creating internal templates or while reviewing each individual device. 

A significant part of regulatory expertise therefore exists not only in the final documents, but also in the logic used to decide which questions must be asked. 

Where Digitalization Can Help 

Digitalization can support this translation by making information requests responsive to the characteristics of the device. 

Rule-based support can help make the documentation process more structured and responsive to the characteristics of the individual device. Rather than presenting the same set of questions for every IVD, a rule-based approach can present questions only when they are relevant and identify conditional requirements under the IVDR. It can also provide the regulatory basis for each question and request a specific justification where a requirement is considered not applicable. In addition, questions can be directed to the appropriate subject-matter experts based on the information required.

Such an approach can also support the management and consistency of the information collected. It can distinguish between information that is genuinely missing and information that is still under review, while checking whether dependent answers remain consistent with one another.

Approved information can also be reused across related regulatory activities, reducing duplication while helping to maintain consistency between different parts of the regulatory documentation.

For example, identifying a device as intended for self-testing can trigger additional questions about intended users, usability, labeling and technical documentation assessment. Identifying an output as quantitative can trigger questions about measuring range, metrological traceability and relevant analytical-performance characteristics. 

These are suitable areas for deterministic automation because the regulatory conditions can be defined explicitly. 

However, automation should not be confused with interpretation. 

Rules Can Ask the Question.
Experts Must Judge the Answer. 

A regulatory software solution can identify that a requirement may apply. It can guide the user toward relevant information and flag an incomplete or contradictory response. 

It cannot automatically determine that: 

• the intended purpose has been framed appropriately 

• a claim is adequately supported 

• a non-applicability justification is defensible 

• the selected evidence is sufficient 

• the benefit-risk conclusion is acceptable 

• or an ambiguous regulatory provision has been interpreted correctly 

Those decisions require regulatory, technical and scientific judgement. 

The realistic objective is not to convert the IVDR into an automatic compliance machine. It is to reduce the time experts spend reconstructing recurring applicability logic and searching for the information needed to make a decision. 

From Regulatory Requirements to Regulatory Intelligence 

The IVDR does not provide manufacturers with a universal questionnaire. Each manufacturer must translate the regulation into device-specific information requirements, conditional questions and regulatory decisions. 

Digitalization can make that process more systematic. Explicit rules can help determine which questions should be asked, which information is missing and which related areas may require attention. 

A lot of the information manufacturers need for IVDR compliance already exists as text in specifications, reports, legacy technical files, instructions for use and supplier documentation. Understanding that content requires more than predefined fields and decision trees. 

It requires the ability to analyze language, recognize meaning, compare statements and assess whether different pieces of information are plausible when considered together. That is where semantic analysis and artificial intelligence begin to offer additional potential. 

The opportunities, limits and necessary controls for AI-supported IVDR technical documentation are the subject of the final article in this series. 

See how IVDR documentation can work from one source of truth

Join the founding partner program and help shape PlatoX® for IVD manufacturers. We’ll show you how it could fit your current documentation workflow—with no obligation.

*We have compiled the above information to the best of our knowledge, yet our blog entries do not constitute expert advice and cannot substitute your own examination of the legal situation applicable to you and your institution.