IVD Software Development: 8 Steps from Intended Purpose to CE Marking

IVD medical device software can process or analyse data obtained from specimens derived from the human body and provide information for diagnosis, monitoring, prediction, prognosis or treatment decisions. In the European Union, software falls under the IVDR only when its intended purpose meets the definition of an in vitro diagnostic medical device in Article 2(2) of Regulation (EU) 2017/746.

Not every laboratory or healthcare software application is an IVD. Software used only to store, transfer, archive or display information may fall outside the definition, while software that interprets results or generates clinically relevant information may qualify as IVD medical device software. Qualification must be based on the intended purpose, input data, output and clinical context.

Bringing IVD software to the EU market requires regulatory, quality, software lifecycle and performance evidence activities to be planned together. The following eight steps provide a practical roadmap from intended purpose and classification to CE marking, launch and post-market change control.

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. Define the Intended Purpose, Users and Target Markets

Define the intended purpose before software architecture and clinical claims become difficult to change. Document:

• the specimens and input data used by the software;
• the calculation, analysis or interpretation performed;
• the output and the clinical decision it supports;
• the intended users, patient population and use environment;
• indications, limitations and contraindications;
• each target jurisdiction and applicable regulatory framework.

Regulatory expertise should be involved during this stage, not added only when the product is ready for submission. Intended purpose decisions affect qualification, classification, software requirements, performance evidence, labelling and the conformity assessment route.

2. IVD Software Classification

Determine whether the software has an IVD medical purpose in its own right, drives or influences another device, acts as an accessory, or falls outside the medical device regulations. Under MDCG 2019-11 Rev.1, qualification is based on intended purpose and functionality, regardless of whether the software operates in the cloud, on a mobile device, on a desktop platform or as part of hardware.

Software that qualifies as IVD medical device software must be classified under Annex VIII of the IVDR, including the applicable implementing rules. The manufacturer should document the qualification and classification rationale and assess separately any software modules with different intended purposes.

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. Complete Conformity Assessment and CE Marking

The EU pathway is a conformity assessment process rather than an application for regulatory approval. The manufacturer must confirm the applicable IVDR class, select the conformity assessment route and, where required, engage an IVDR-designated notified body.

The submission package should align the intended purpose, classification rationale, quality management system, risk management, software lifecycle documentation, usability, cybersecurity, performance evaluation and post-market plans. Class A non-sterile devices may generally be self-declared, while other classes normally require notified body involvement.

Once conformity has been demonstrated, the manufacturer issues the EU Declaration of Conformity and affixes the CE marking. Registration, UDI, labelling and economic-operator obligations must also be completed before placing the software on the EU market.

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.
• Apply documented change control to every software release, including bug fixes, cybersecurity patches, algorithm changes and modifications to input data, intended purpose or performance claims. Assess whether verification, validation, performance evaluation, technical documentation, labelling or notified body notification must be updated before release. MDCG 2022-6 should only be used when assessing significant changes to eligible legacy IVDs placed on the market under the IVDR transitional provisions.
• 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.

Plan the Regulatory Pathway Before Development Decisions Become Difficult to Reverse

Qualification, classification and performance evidence decisions made early in development can prevent major changes to software architecture, claims and technical documentation later.

If you need support with IVDR qualification, performance evaluation, technical documentation or change control, explore MDx CRO’s Software, Digital Health & AI regulatory services or request a regulatory assessment.

FAQs