IVDR readiness for IVD software and devices

What changed with IVDR

IVDR replaced IVDD and applies from 26 May 2022.The EU In Vitro Diagnostic Regulation replaced the older IVDD directive. It became applicable on 26 May 2022.IVDD was superseded by IVDR, which has been in effect since 26 May 2022 and carries significantly higher evidence requirements. The scope now covers instruments, reagents, kits, and software that guide clinical decisions. Unique Device Identification supports full traceability. Risk based classes A to D drive the conformity route.IVDR assigns devices to one of four risk classes, from A to D, and the class determines what conformity pathway applies.The classification system runs from Class A at the lower end to Class D for the highest public health risk devices, and each class carries different evidence obligations.

• Class A: General lab equipment and specimen containers.
• Class B: Controls and non critical self testing devices.
• Class C: Tests for cancer, genetics, infectious disease, or critical screening.
• Class D: High public health risk such as transmissible agents that are life threatening.

Evidence and technical files

• Analytical performance, clinical performance, and scientific validity kept current.
• Performance Evaluation Report and Periodic Safety Update Report maintained and reviewed.
• Post Market Performance Follow Up plan in place and executed.

Cybersecurity and risk

• Threat and vulnerability assessment tied to patient safety and data integrity.Cybersecurity work under IVDR needs to be explicitly connected to patient safety outcomes and the integrity of diagnostic data.Vulnerability assessments for IVD software are not generic IT exercises. They need to address failure modes that could affect a patient result or a clinical decision.
• Secure development, code review, and dependency hygiene.
• Penetration testing and patch plans with clear release notes.
• Post market signals integrated with incident response.

How SequoiaAT helps IVD teams

• Software design and validation aligned with ISO 13485 and IEC 62304.
• Data and algorithm pipelines with audit trails and traceability.
• Threat modeling, test harnesses, and deployable hardening guides.
• Dashboards for post market signals and performance trends.
• Technical file support and migration plans for legacy devices.

Software lifecycle requirements under IVDR

Software that qualifies as an IVD under IVDR falls within the scope of IEC 62304. That standard defines lifecycle requirements covering development planning, requirements analysis, architectural design, unit and integration testing, and maintenance. Under IVDR the software lifecycle documentation needs to stay current and traceable across the product lifetime. A change to an algorithm or a data processing step triggers a review of the associated risk assessment and, depending on significance, may require updates to the Performance Evaluation Report.

Teams that treat their software as a one-time delivery rather than a living system tend to face the most difficulty at renewal and post-market surveillance reviews. IVDR specifically requires an ongoing process rather than a point-in-time evidence package.

Key IEC 62304 outputs that support IVDR technical files

• Software development plan covering the full lifecycle
• Software requirements specification linked to device intended purpose
• Software architecture document with safety classification per unit
• Unit, integration, and system test records
• Software maintenance plan and problem resolution log

Post-market performance follow-up

Post-market performance follow-up (PMPF) is one of the areas where IVDR diverges most sharply from the older IVDD. Teams are expected to have a proactive plan in place, not just a reactive incident log. The PMPF plan needs to define data sources, collection intervals, evaluation criteria, and a clear path from signal to action.

For software-based IVDs, practical data sources include field complaint logs, literature reviews, equivalent device surveillance, and operator feedback. Automated dashboards that aggregate post-market signals and flag deviations against predefined thresholds make the ongoing review cycle more tractable. SequoiaAT designs these monitoring layers as part of the software platform from the start, not as a separate reporting task appended at the end of development.

PMPF activities that IVD software teams typically maintain

• Structured review of field performance data against acceptance criteria
• Literature and regulatory guidance monitoring for the relevant analyte or clinical area
• Vigilance reporting integration aligned with competent authority timelines
• Periodic Safety Update Report updated on the schedule defined by device class

Unique Device Identification and traceability

IVDR requires Unique Device Identification for IVDs placed on the EU market, with registration in EUDAMED. For software-based IVDs the UDI applies to each distinct version placed on the market. That makes version management and release control regulatory obligations, not just engineering best practice. Each released version needs a stable identifier, a defined scope, and traceable change records.

Teams that build version management into their release pipeline from the start have a simpler path to EUDAMED registration and to answering competent authority questions about what changed between versions and why.

Classification challenges for combination products and software

One of the more vexed questions under IVDR is how to classify software that sits alongside, or is bundled with, a physical analyzer or reagent system. Where software is integral to the device and directly influences the diagnostic output, it typically inherits or shares the class of the overall device. Where software operates independently and meets the IVDR definition of an IVD in its own right, it is classified separately based on its own intended purpose and risk profile.

Teams building laboratory information systems, middleware, or algorithmic decision-support tools for diagnostic laboratories frequently need to work through this question with their regulatory advisors before starting technical file preparation. Getting the classification wrong early in a project can lead to significant rework of the evidence package once the correct conformity route becomes clear. SequoiaAT works with teams at the classification stage to make sure that the technical architecture and the regulatory pathway are aligned before substantial development investment is made.

Questions that often arise at the classification stage

• Does the software make or influence a specific diagnostic decision, or does it only process and display data?
• Is the software placed on the market independently or only as part of an instrument system?
• Does the intended use statement scope the device to a specific analyte or clinical condition?
• What is the consequence of an incorrect result for the patient and for public health?

Quick answers

When did IVDR apply

It applies from 26 May 2022. Legacy devices may have defined transitions by class if conditions are met.

What does a team need for software evidence

Analytical and clinical performance, documented lifecycle, and post market monitoring with clear updates.

Can SequoiaAT support audits

We prepare engineering evidence and help teams answer technical questions during reviews with partners and notified bodies.SequoiaAT supports technical file preparation and can help your team work through the engineering questions that come up during notified body assessments.Our teams help produce the technical evidence that audits and notified body reviews require, and we stay available to support the questions that arise during those conversations.