EU AI Act and Medical Devices: What SaMD Developers Need to Know (2026)

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and is being phased in progressively through 2026 and beyond. For companies developing AI-powered Software as a Medical Device (SaMD), it introduces a second, overlapping regulatory obligation that runs alongside, and interacts with, the existing requirements of EU MDR and IVDR.

This is not a distant compliance horizon. The provisions most relevant to medical device AI became applicable from August 2026. Companies that have not yet assessed their AI systems against the AI Act risk gaps in their technical documentation and conformity processes at exactly the moment Notified Bodies are beginning to incorporate AI Act considerations into their assessments.

This guide explains what the AI Act requires from SaMD developers, how it interacts with MDR and IVDR, and what practical steps manufacturers should be taking now.

For the underlying MDR compliance requirements for SaMD, see: Software as a Medical Device (SaMD): EU MDR Compliance Guide

1. Does the AI Act Apply to Your Software?

The AI Act applies to AI systems placed on the market or put into service in the EU. An AI system is defined as a machine-based system that, given explicit or implicit objectives, infers from inputs how to generate outputs such as predictions, content, recommendations, or decisions that can influence real or virtual environments.

This definition is intentionally broad. It covers:

  • Machine learning models (supervised, unsupervised, reinforcement learning)
  • Deep learning systems including convolutional neural networks used in medical imaging
  • Natural language processing tools used in clinical documentation or decision support
  • Bayesian classifiers and other probabilistic inference systems

It does not cover:

  • Traditional rule-based software with no learning or inference component
  • Software that executes fixed logic without adaptive behaviour

If your SaMD uses any form of machine learning or statistical inference to generate clinical outputs, the AI Act almost certainly applies.

2. High-Risk AI Classification for Medical Devices

The AI Act categorises AI systems by risk level. For medical device manufacturers, the critical category is high-risk AI.

Under Annex III of the AI Act, AI systems intended to be used as safety components of medical devices, or which are themselves medical devices regulated under MDR or IVDR, are automatically classified as high-risk AI.

This means: if your SaMD is a CE-marked medical device or IVD, or is a software component that performs a safety function within one, it is high-risk AI under the AI Act. There is no further classification analysis required, the medical device status determines it.

High-risk AI systems are subject to the full obligations of the AI Act, including:

  • Risk management system: an AI-specific risk management process, documented and integrated with the ISO 14971 risk management already required under MDR
  • Data and data governance: training, validation, and testing datasets must be relevant, representative, free of errors, and sufficiently complete; demographic and geographic representativeness must be documented
  • Technical documentation: a detailed record of the AI system’s design, development process, training methodology, validation approach, and performance characteristics
  • Transparency and instructions for use: users must be provided with clear information about the AI system’s capabilities, limitations, accuracy metrics, and circumstances under which human oversight is required
  • Human oversight: the system must be designed to allow human oversight and intervention; it must not undermine the ability of the operator or user to override, disregard, or reverse outputs
  • Accuracy, robustness, and cybersecurity: performance must be declared and validated; the system must be resilient to errors, faults, and adversarial manipulation
  • Conformity assessment: high-risk AI systems must undergo a conformity assessment before being placed on the market

3. How the AI Act Interacts with MDR and IVDR

This is where the compliance picture becomes complex, and where early planning pays off.

The AI Act does not replace MDR or IVDR. Both regulatory frameworks apply simultaneously to AI-powered SaMD. However, the EU has designed a streamlined pathway for medical devices that are already subject to Notified Body review under MDR or IVDR.

Under Article 11 and Annex II of the AI Act, AI systems that are regulated as medical devices benefit from a single technical documentation approach meaning the AI Act technical documentation requirements can be integrated into the existing MDR/IVDR technical file rather than creating a separate document set.

Similarly, for Class IIb and III medical devices (MDR) and Class C and D IVDs (IVDR) which are the most likely to contain high-risk AI the Notified Body involvement already required under MDR/IVDR can cover the AI Act conformity assessment. The Notified Body acts as the relevant conformity assessment body for both frameworks.

In practice this means:

What changes for AI-powered SaMD under the AI Act:

  • Technical documentation must now explicitly address AI-specific elements: training data governance, model validation across subgroups, bias assessment, explainability approach, and human oversight mechanisms
  • Post-market monitoring must include AI performance monitoring tracking model drift, accuracy degradation over time, and distribution shift in real-world data
  • Transparency obligations require new IFU content describing AI limitations and human oversight requirements
  • A fundamental rights impact assessment may be required for certain high-risk AI applications in healthcare

What does not change:

  • The MDR/IVDR conformity assessment route remains the primary pathway
  • The Notified Body relationship established for MDR/IVDR CE marking remains the relevant body
  • ISO 14971 risk management, IEC 62304 lifecycle management, and clinical evaluation requirements are unchanged AI Act risk management is additive, not a replacement

4. General Purpose AI (GPAI) Models in Medical Devices

A separate and increasingly relevant category is General Purpose AI (GPAI) large foundation models or multimodal AI systems that can be adapted or fine-tuned for specific applications.

If a SaMD developer is building on top of a GPAI model: for example, fine-tuning a large language model for clinical documentation, or adapting a vision foundation model for medical image analysis both the GPAI model provider and the SaMD developer have obligations under the AI Act.

GPAI model providers must publish technical documentation and comply with copyright and transparency requirements. SaMD developers who deploy or fine-tune GPAI models are responsible for ensuring the resulting system meets all high-risk AI obligations, including data governance, validation, and clinical performance claims. The validation methodology for fine-tuned GPAI models in medical contexts is an area where regulatory guidance is still developing, early engagement with your Notified Body is strongly recommended.

5. Key Timelines

August 2024: AI Act enters into force.

February 2025: Prohibitions on unacceptable-risk AI systems apply. Not directly relevant for medical SaMD, but important for any AI used in patient-facing administrative processes.

August 2025: GPAI model obligations apply. SaMD developers building on foundation models must assess their exposure now.

August 2026: High-risk AI obligations fully apply. This is the key deadline for medical device AI. From this date, new AI-powered SaMD placed on the EU market must comply with all high-risk AI requirements.

Post-2026: Notified Bodies designated under the AI Act will begin conducting AI Act-specific conformity assessments. The intersection with MDR/IVDR NB assessments will become a standard part of the conformity process.

6. What to Do Now: A Practical Checklist

Classify your AI systems. Identify every AI component in your SaMD portfolio and confirm whether it meets the EU’s definition of an AI system. For each, document the risk classification and the rationale.

Assess your technical documentation gaps. Review your existing MDR/IVDR technical files against the AI Act Annex IV requirements. Identify where AI-specific content, training data documentation, bias assessment, explainability approach, is missing or insufficient.

Review your data governance. The AI Act’s requirements for training data representativeness and bias documentation are more explicit than anything in MDR. If your training data governance is not documented at the level the AI Act requires, this is a gap that needs addressing before your next Notified Body audit.

Update your IFU and labelling. Transparency obligations mean users must be explicitly informed about AI limitations, performance metrics across relevant subgroups, and circumstances requiring human override. Most current SaMD IFUs are not written to this standard.

Engage your Notified Body. Ask your NB directly how they are approaching AI Act integration into MDR/IVDR assessments. Different NBs are at different stages of readiness, and early clarity on what they will expect prevents last-minute documentation gaps.

Build AI performance monitoring into your PMS. Post-market surveillance for AI-powered SaMD must now track model performance over time. If your PMS plan does not include AI-specific monitoring metrics, update it before August 2026.

Further Reading

Written by:
Diego Rodrigues, PhD

Diego Rodrigues, PhD

RA Specialist

Regulatory affairs specialist & CRA with expertise in EU MDR/IVDR, CE marking, Biological Evaluations (dental), and clinical investigations & technical documentation for MDs & IVDs.
Industry Insights & Regulatory Updates

IVDR CE marking NGS: MDx Case Study with Fulgent

IVDR CE marking NGS at a glance

  • Outcome: CE mark granted by TÜV SÜD for an end-to-end Class C germline NGS solution (wet lab + bioinformatics).
  • Scope: Furthermore, panel covering 4,600+ clinically relevant genes with a validated PLM (Pipeline Manager) software component; later expanded to >7,000 genes using a new probe set.
  • What we did: Specifically, we built an ISO 13485 QMS from the ground up, prepared full Annex II + III technical documentation, validated bioinformatics under IEC 62304/82304, split documentation into two Basic UDI-DIs (wet lab vs. software), and guided Stage I/II audits.
  • Why it matters: Ultimately, this demonstrates a repeatable pathway to IVDR certification for large NGS services and software—something that had no clear precedent.

Read the announcements: For details, read the Fulgent press release and Citeline case study.

The challenge: certifying a service-based, large-scale NGS system under IVDR

To begin with, FulgentExome is a service-based NGS solution that integrates wet-lab workflows with the Fulgent PLM bioinformatics pipeline. As a result, pursuing IVDR certification meant converting a mature CLIA/CAP testing service into a CE-marked IVD system with robust evidence across scientific validity, analytical performance, and clinical performance—for thousands of genes. In particular, key hurdles included: defining intended use at scale; validating third-party components; proving scientific validity across 4,600+ genes; above all fully validating the bioinformatics pipeline under medical device software standards.

MDx approach: a playbook for complex NGS + software

1) Build the right QMS, fast

First, we performed an IVDR GAP assessment. Next, we designed and implemented an ISO 13485-compliant QMS with risk management, supplier control, document control, internal audits, and management review—migrating from a CLIA/CAP model to IVDR-ready operations.

2) Engineer a defensible intended use

Meanwhile, the intended-use statement evolved iteratively—from an initial ~300-gene scope to whole-exome, finally landing on 4,600+ genes aligned to available clinical and analytical evidence. In the end, the final language was future-proofed to support rapid updates as evidence expands.

3) Split wet lab and software into two regulated products

Afterward, following round 1 review feedback, we separated the documentation into two Basic UDI-DIs—FulgentExome (wet lab) and Fulgent PLM (software)—to align with IVDR expectations for traceability and lifecycle control. Consequently, this restructuring sharpened conformity assessment and accelerated subsequent approvals.

4) Validate the informatics stack like a medical device

In parallel, we validated PLM under IEC 62304/82304, including architecture, version control, cybersecurity, verification/validation, and integration with external databases. Therefore, the result was a fully evidence-backed bioinformatics pipeline capable of reproducible, high-confidence variant calling and reporting.

5) Make “evidence at scale” practical

  • First, Scientific validity: Three-tier strategy combining validation of exome sequencing as an approach, reliance on curated public databases, and deep exemplars for a large subset of genes.
  • Second, Clinical performance: Leveraged routine testing experience (thousands of positives) to focus clinical evidence on high-prevalence genes, and instituted a robust PMPF strategy to continuously strengthen low-prevalence areas.

6) Orchestrate TÜV SÜD audits to success

  • Initially, Stage I confirmed documentation readiness, scope, Basic UDI-DIs and integration of IVDR processes into daily practice.
  • Subsequently, Stage II verified on-the-floor implementation of SOPs, training, competence, CAPA and change control—closing findings on short cycles to hit NB timelines.

Results that move the market

  • CE mark granted for FulgentExome & Fulgent PLM—among the first end-to-end Class C germline NGS solutions under IVDR.
  • Certified scope covers 4,600+ genes, positioning Fulgent as a reference lab for comprehensive hereditary disease testing serving European patients.
  • Post-certification, the platform scaled to >7,000 genes using a new probe set—demonstrating the inherent scalability built into the certified system (process, documentation, and change control).
  • Strengthened competitive standing in the EU diagnostics market; public communications highlight the magnitude of this achievement for large NGS panels.

Read more in the Fulgent press release and Citeline’s in-depth article.

What this means for labs and IVD developers planning large NGS submissions

If you operate an LDT today: you’ll need to translate CLIA/15189 practices into an ISO 13485 framework, document design controls, and produce a full PER (PEP/PER), APR, SVR, PMS/PMPF, SSP, and labeling/IFU aligned to GSPR. Expect to validate any bioinformatics pipeline as SaMD with IEC 62304/82304 and cybersecurity controls.

If your panel is “large”: you likely won’t have uniform clinical data across every gene. A structured tiered evidence model + PMPF can satisfy Notified Bodies while keeping your roadmap scalable.

If you combine wet lab + software: plan for separate Basic UDI-DIs and documentation sets. Treat the pipeline as a product with its own requirements, verification, and risk controls.

Why MDx

  • End-to-end IVDR expertise: From regulatory strategy & classification to Annex II/III technical files, PER/SVR/APR, training, and mock NB reviews.
  • Clinical performance studies: We design, run, and report ISO 20916 studies (protocols, eTMF, monitoring, biostats, PER alignment), and we can act as delegated sponsor for multi-country submissions—100% submission success rate to date.
  • Operational scale: ISO 9001 clinical QMS, EU/US partner network, multilingual CRAs, and a repeatable process honed on 60+ performance study submissions for top IVD and pharma clients.

Project timeline

Our joint project with Fulgent spanned July 2023–July 2025, with overlapping tracks for QMS creation, technical documentation, NB review, and Stage I/II audits—a coordinated plan that allowed rapid closure of findings and post-certification scaling.

Client perspective

The program demanded evening/weekend execution across regulatory, documentation, and project management to meet Notified Body timelines—effort that, in the client’s words, made all the difference in achieving what initially “seemed almost impossible.

Planning IVDR for your NGS panel? Here’s a quick readiness checklist

  • Intended use aligned to evidence (and future updates)
  • ISO 13485 QMS with software lifecycle integration
  • PER (PEP/PER), SVR, APR mapped to gene-level strategy
  • PLM/DR pipeline validated per IEC 62304/82304 (+cybersecurity)
  • Separate documentation/UDI for wet lab vs. software (if applicable)
  • PMS/PMPF plan to mature low-prevalence evidence post-market
  • Mock NB review + Stage I/II audit readiness

(Our team can lead or co-author each artifact above.)

Talk to us

Whether you’re certifying a focused oncology panel or pushing the limits with exome-scale content, MDx brings the cross-functional regulatory, clinical, quality, and software depth to make it possible—on a timeline that keeps your business competitive.

Written by:
Carlos Galamba

Carlos Galamba

CEO

Senior regulatory leader and former BSI IVDR reviewer with deep experience in CE marking high-risk IVDs, companion diagnostics, and IVDR implementation.
Industry Insights & Regulatory Updates

IVD Software Development: How to Bring IVD Software to Market in 8 Steps

The healthcare industry is undergoing a rapid transformation spurred by the advent of advanced medical diagnostic technology. IVD software development is a critical component of this revolution as it allows for testing, analysis, reporting, and communication without needing a physical laboratory or a visit to a doctor’s office.

Bringing IVD software development to the market can benefit patients and healthcare providers who can deliver quality care faster with fewer resources.

Projected size of the IVD market worldwide from 2018 to 2027 (in million U.S. dollars)

Source: Statista

The above graph shows the In-Vitro Diagnostics (IVD) market globally was estimated at 72.4 billion U.S. dollars in 2020, with a projected growth of 108 billion U.S. Dollars by 2027, showing its increased relevance in the healthcare industry today.

1. Conduct Market Research

Before starting the development process,  organizations must conduct market research and understand their target market, user needs, and potential competitors.

Market research should also help determine regulatory requirements that organizations must comply with and any current trends within the industry or technology space.

Below are some key points to consider when conducting market research for IVD software development:

  • Identify regulatory requirements: Identifying the regulatory requirements for your software is essential for bringing your product to market. They may vary depending on your target market, such as the FDA in the US or the European Union’s CE marking requirements (IVDR 746/2017).
  • Determine your target market: Identify the segments of the healthcare industry that your IVD software will serve. Consider factors such as geography, type of healthcare organization, and specialty areas.
  • Identify your competitors: Research the IVD software market to identify your competitors and their products. Analyze their strengths, weaknesses, pricing, and marketing strategies.
  • Understand your customers: Conduct surveys, interviews, and focus groups with healthcare professionals to understand their needs, preferences, and pain points. Use this information to tailor your IVD software to meet their specific needs.
  • Analyze market trends: Stay up-to-date on the latest trends and developments in the IVD software market. Monitor industry publications, attend conferences, and follow industry experts and thought leaders on social media.
  • Determine pricing strategy: Consider costs, target market & competition when determining pricing strategy, e.g., one-time fee. Subscription fee? Per-test fee?

2. IVD Software Classification

Understanding the classification of your IVD software is crucial before starting the planning and design process. Determine whether the IVD software is a standalone IVD medical device or a component of a larger system.  To be qualified as an IVD medical device software in the EU, the product must fulfil the definition of IVD according to Article 2(2) of Regulation IVDR 746/2017, as described in the Figure 1. The correct classification of IVD software should be done based on the rules described in Annex VIII of the IVDR. Relevant guidance documents, such as MDCG 2019-11 are also essentials for the qualification and classification of IVD software.

Fig. 1 – MDCG 2019-11 flowchart on qualification of Medical Device Software (MDSW)

Familiarize yourself with relevant regulatory frameworks, guidances and standards such as ISO 13485, IEC 62304, but also specific guidance documents published by regulators, which provide specifications and guidelines for developing, validating, and maintaining IVD software.

3. Plan and Design the Software

The next crucial step of a successful IVD software development is design and planning.

  • A well-documented and robust planning process can help provide a more detailed roadmap for development.
  • During this phase, design reviews, testing, and verification will ensure that the final version meets user requirements.
  • It is essential to incorporate user feedback at every stage of the design process to develop an intuitive interface that works effectively according to their needs.
  • Obtaining feedback from customers and stakeholders offers the development team opportunities to recognize potential concerns and areas for enhancement.
  • Developers can devise software solutions that fulfill customer needs and address their grievances by integrating feedback.
  • The importance of accurate documentation should not be underestimated as it helps trace back issues later on in the lifecycle of the software.
  • The development team must consider scalability and flexibility during the initial planning and design stages when creating the software.

4. Develop and Test the Software

Developing and testing the software is crucial in creating a working prototype.

  • The development phase is necessary to ensure the accuracy of the design, coding, and algorithms used in creating the software solutions.
  • Testing and quality assurance also play an essential role in ensuring the products meet all requirements before launch.
  • It is essential for companies to thoroughly assess each component of their software as part of this process. This includes ensuring they meet performance objectives concerning speed, responsiveness, scalability, security, reliability, and ease of use for their users.
  • Quality assurance checks help identify bugs or errors to release a defect-free product that meets all standards from regulatory bodies such as FDA or CE Marking.
  • When deploying IVD systems, manufacturers need to consider if their applications can be flexible enough to support new technological advances; future-proofing their products becomes increasingly necessary where customers demand longevity across upgrades or iterations over time.

5. Prepare a Regulatory Submission

Preparing a regulatory submission package is critical in bringing IVD software development to market. This step involves compiling documents to demonstrate that the software meets regulatory requirements and is safe and effective.

Here are some critical considerations for preparing a regulatory submission:

  • Gather relevant documents for the package

Understand regulations, standards, and risk classification of IVD software and the manufacturing role. Key documents to include are the device description, technical documentation, risk management file (ISO 14971), software lifecycle documentation (IEC 62304), and quality management system documentation (ISO 13485). Risk management must be applied and monitored during the IVD software development life cycle.

  • Prepare a performance evaluation report (PER)

This will require a comprehensive analysis of scientific evidence showing that the product meets user needs safely and effectively. IVD software performance evaluation should be prepared in accordance with relevant guidance documents, such as MDCG 2020-1 for the EU. Other guidance such as MedTech Europe Clinical Evidence Requirements for IVD can also be a good source of  additional information.

Clinical performance studies are aimed at providing evidence of the safety and effectiveness of a product’s intended purpose to ensure that it’s able to diagnose, monitor and predict diseases and conditions accurately.

As described in MDCG 2020-1 “Validation of the clinical performance should be considered at each change of the software to a new release. If no validation is performed, a justification should be stated in the technical documentation. With a validation of clinical performance, it is demonstrated that users can achieve clinically relevant outputs through predictable and reliable use of the MDSW”.

Adherence to relevant standards and guidelines, such as ISO 20916 (Clinical Performance Studies for In vitro diagnostics) and Good Clinical Practice (CGP), are crucial for the successful execution of clinical studies.

  • Ensure data accuracy

Ensure that that any data collected from testing is presented accurately to prove safety and efficacy before submitting your application. This includes validation and verification data, performance evaluations, and, if applicable, results from clinical studies. Carefully review all information for accuracy and completeness before submitting it.

6. Obtain Regulatory Approval

You need to obtain regulatory approval to bring IVD software development to market. Successful approval enables you to market and sell your software in compliance with local laws and regulations.

  • Familiarize yourself with the applicable regulatory frameworks and guidelines for your software. These may include ISO 13485 (quality management systems), IEC 62304 (medical device software lifecycle processes), ISO 14971 (risk management), and MDCG guidance documents such as MDCG 2019-11 (qualification and classification of software in the medical device regulations) and MDCG 2020-1 (guidance on performance evaluation for IVD software under the IVDR. You should also consider guidelines from other jurisdictions depending on your market strategy. The FDA for example has issued guidance for software as a medical device (SAMD).
  • Develop a comprehensive application package that should include all the necessary documents, data, and tests required for review. Ensure your package addresses regulatory requirements, such as conformity assessment procedures, clinical evidence, and post-market surveillance.
  • Submit the application package to the relevant regulatory authorities for review, such as the FDA in the US or notified bodies in the EU under the In Vitro Diagnostic Regulation (IVDR) 2017/746.
  • Be prepared to respond quickly and accurately to any feedback or additional information requests from regulatory agencies during the review process.
  • Make recommended changes swiftly as part of your submission to obtain approval from agencies successfully.
  • Once you receive approval from regulatory agencies, you can move forward with marketing and selling your software according to local laws & regulations, ensuring ongoing compliance with any post-market requirements.

7. Developing Marketing and Sales Strategies

Creating a successful marketing and sales strategy is essential for bringing IVD software to the market, it allows for faster positioning and gaining a competitive advantage. Make sure to develop a strong brand identity with messaging that resonates with your audience.

In addition, researching customer needs and understanding key industry trends can create a more targeted approach when it comes to the marketing of IVD software solutions, increasing your likelihood for success.

Make sure to use multiple channels such as paid advertising, email campaigns, social media and webinars to reach out to potential customers from diverse segments.

And last but not least, creating effective communication strategies to engage with customers throughout the sales cycle will also be key to promoting IVD products successfully.

8. Launch and Support the Software

Launching and supporting software is a crucial element to its success. The product can be improved over time by providing regular updates and customer service, and users can get the best experience.

Here are some points to consider when launching your IVD software development:

  • Create a comprehensive support plan that puts customer needs first. Ensure you have an efficient process for handling inquiries and technical issues as they arise.
  • Ensure that all necessary software updates are completed on schedule, so users don’t experience any delay in accessing the product’s full features or bug fixes.
  • Assess the regulatory impact of changes and bug fixes, changes to your IVD software may or may not be significant. Consider whether changes impact your regulatory approvals. MDCG 2022-6 provides additional guidance on changes to design and intended purpose in the context of the new transition timelines for IVDs in Europe.
  • Set up user feedback forms or surveys so customers can share their thoughts on the product’s performance and what improvements they want to see. This will help drive further development of the software over time.
  • Offer ongoing training opportunities for new features, so users feel confident using them once released. This will also ensure that customers know how to use their investment in your IVD software development solution fully.

Revolutionizing Healthcare With IVD Software Development

In vitro diagnostic (IVD) software development has transformed the healthcare industry by providing cost-effective testing, analysis, reporting, and communication solutions without physical laboratory equipment.

Studies indicate that healthcare providers highly prioritize in vitro diagnostic (IVD) procedures, and their optimization has the potential to enhance patient outcomes. Therefore, the development of IVD software is crucial in facilitating quicker and more accurate diagnostic results, ultimately leading to the optimization of healthcare practices.

If you need a partner in IVD software development for your business, MDx CRO is an IVD consultancy that provides end-to-end solutions to accompany you at each step of the process. Our team of highly experienced CRO strategists has extensive expertise in bringing innovative medical devices and IVD technologies to market. Request your expert consultation today.

FAQs

What are the key considerations when designing IVD software?

There are several key considerations that companies should keep in mind when designing IVD software: user requirements, regulatory requirements depending on the target geographic location, data accuracy and effective data management, the software’s ability to integrate with other systems, as well as performance and usability.

What are the regulatory requirements for IVD software development in Europe?

The regulatory requirements for IVD software development in Europe are determined by the In Vitro Diagnostic Regulation (IVDR), which became applicable on May 26, 2022. They include, but are not limited to design and development, risk management, validation and verification, as well as compliance with GDPR.

What are the most common challenges in IVD software development?

The most common challenges in IVD software development include regulatory compliance (which can be complex and challenging to navigate through), ensuring integration compatibility with other systems, effective data management, and great user experience, among others.

How do you ensure the quality and reliability of IVD software?

To ensure the quality and reliability of IVD software, it’s important that companies follow all regulatory guidelines applicable to their geographical location, and use a quality management system to ensure that the development process is well-documented. Conducting testing, validation and verification processes is another essential element of software development for in vitro diagnostics.

Industry Insights & Regulatory Updates