Understanding the MDCG 2023-4 Guidance on Medical Device Software and Hardware Combinations
October 20, 2023
The world of medical device regulation is constantly evolving, with regulatory bodies introducing new guidances to keep up with the technological advances in the sector. One such pivotal guidance is the MDCG 2023-4, focusing on Medical Device Software (MDSW) intended to work in combination with hardware or hardware components.
What is MDCG 2023-4?
The Medical Device Coordination Group (MDCG) released the guidance MDCG 2023-4. This document provides detailed insights into the considerations and regulatory requirements for MDSW that is intended to be used in combination with hardware or its components.
Key Highlights of MDCG 2023-4
1. The Prominence of Hardware in MDSW
For many MDSW, hardware components directly link their effectiveness by feeding them with necessary data. Devices such as wearables, smartwatches, or augmented reality goggles utilize sensors and cameras to collect data. This data is then processed by MDSW applications for medical outcomes.
In some cases, these hardware components are crucial to general consumer electronics, emphasizing the importance of convergence between MDSW and hardware. Especially with integrated sensors, understanding their qualification and the suitable regulatory pathways becomes essential.
2. Regulatory Scope of MDCG 2023-4
Hardware components significantly contribute to the medical functionality of specific MDSW through data and signals. Understanding the regulatory implications when combining MDSW with associated hardware is essential. This guidance sheds light on the regulatory considerations for hardware components when they either function as medical devices or their accessories. However, it’s crucial to note that areas like clinical evaluation or cybersecurity are not covered by this guidance.
3. MDSW-Hardware Synergy
The medical intent of numerous MDSW apps is closely tied to the data from the associated hardware. This hardware serves as data input sources and occasionally even controls the MDSW. For optimal functionality, the hardware must guarantee precision, reliability, and performance. There are various scenarios, such as:
A single manufacturer producing both a dermal patch with sensors and a corresponding MDSW app.
A wearable device, like a watch with sensors, requiring a user to download a corresponding MDSW app from the same manufacturer.
However, situations where the hardware and MDSW app manufacturers differ introduce complex interoperability considerations.
4. Regulatory Considerations
As per MDR’s Article 2 and MDCG 2023-4, a medical device’s purpose can either be achieved independently or in conjunction with other devices or accessories. From the scenarios provided, it’s evident that the MDSW and hardware components are interdependent for medical functionality. If a manufacturer claims a medical purpose for the software, they need to provide evidence of compliance with the MDR, ensuring that the interaction between the MDSW and hardware produces safe and effective results.
5. Market Placement
For the initial scenarios, where both the MDSW and hardware are categorized as medical devices or their accessories, MDR compliance is crucial, focusing on safety, interoperability, and performance. This involves comprehensive clinical evaluations and post-market surveillance. However, if the hardware isn’t MDR compliant, the responsibility of ensuring safety and performance lies with the MDSW manufacturer.
Frequently Asked Questions (FAQ)
Is the MDCG 2023-4 guidance binding for manufacturers? The guidance offers insights and best practices. However, always consult with specific regulatory authorities for mandatory requirements.
Does this guidance apply to software-only medical devices? The primary focus is on software working with hardware. Some sections might still be relevant for software-only devices in terms of risk management.
What penalties are in place for non-compliance? Penalties vary based on regional regulations. It’s essential to stay updated with regional medical device regulatory guidelines.
Conclusion
The MDCG 2023-4 guidance is a significant step in clarifying the regulatory framework for medical device software and hardware combinations. Adhering to the guidance ensures innovations in the field are both groundbreaking and compliant, safeguarding patient welfare. Stakeholders and manufacturers are encouraged to familiarize themselves with the MDCG 2023-4 document to stay ahead in the ever-evolving medical device industry.
Written by:
Andre Moreira
Regulatory Director, Medtech
Senior quality & regulatory expert, ISO 13485/MDR/IVDR auditor with expertise in CE marking MDs/IVDs, incl. dental, implantables, drug delivery, genomic tests, & MDR/IVDR implementation.
IVD Software Development: How to Bring IVD Software to Market in 8 Steps
April 4, 2023
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)
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.
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 IVDR746/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.
Position Paper on Cyber Security: What EU Notified Bodies Expect from Medical Device Manufacturers
October 13, 2022
Connected medical technologies—from implantables and bedside devices to SaMD mobile apps and cloud platforms—are transforming patient care. That same connectivity introduces new attack surfaces that can jeopardize safety, performance, data integrity, and privacy if not addressed systematically. The European Association of Notified Bodies (Team-NB) issued a consensus position paper on cybersecurity to clarify expectations for manufacturers and help convergence across the EU market. The paper underscores that cybersecurity is integral to compliance under the MDR/IVDR and should be engineered across the device lifecycle, not appended at the end.
Team-NB’s position aligns with the MDCG 2019-16 Rev.1 Guidance on Cybersecurity for Medical Devices, which frames security as a prerequisite for safety and as part of risk management and software lifecycle processes (e.g., secure design, verification/validation, vulnerability handling, and post-market monitoring). Manufacturers are expected to demonstrate “state-of-the-art” controls proportionate to the device’s intended purpose, clinical context, and connectivity profile.
Why this matters now is clear in the data. The ENISA Health Threat Landscape reports that healthcare has faced a sustained wave of cyber incidents, with ransomware representing 54% of observed threats during the January 2021–March 2023 period. Attackers increasingly target hospitals and providers, but connected devices and digital diagnostics sit within the same ecosystem and must be designed to operate safely under adversarial conditions. Building to recognized frameworks—and proving it in technical documentation and post-market processes—has become a market access requirement, not just good practice.
What Team-NB emphasizes for manufacturers
Team-NB calls for coherent, harmonised expectations to avoid fragmentation from diverging national rules and guidance. Practically, that means embedding security by design within the established regulatory toolset: risk management tied to clinical harm, secure software lifecycle practices, configuration management, SBOM and patching strategies, coordinated vulnerability disclosure, and field monitoring that feeds back into PMS/PMCF. Notified Bodies will evaluate whether these controls are commensurate with the device’s risk, evidence is traceable, and responsibilities across manufacturers and health-care organisations are clearly defined.
The paper also recognises resource constraints across industry and authorities and encourages approaches that streamline conformity assessment without lowering the bar—for example, leveraging existing international standards and clearly mapping them to EU requirements. In parallel, broader policy work and sector threat intelligence (e.g., ENISA’s updates) should inform manufacturers’ threat models and maintenance plans over the full device lifetime.
How MDx CRO can help
Cybersecurity is now inseparable from regulatory success. MDx CRO integrates security expectations into regulatory strategy, clinical and post-market plans, and technical documentation so your submission is consistent end-to-end. We align your files with MDCG 2019-16 Rev.1 and Team-NB’s position, operationalise secure-by-design practices in your development lifecycle, and set up vulnerability monitoring and response that fit your PMS system. Explore our support for Regulatory Affairs and Clinical Research, orcontact us to discuss a cybersecurity-ready roadmap for your device portfolio.
Draft of Principles and Practices for Software Bill of Material for Medical Device Cybersecurity
August 23, 2022
Connected medical devices increasingly share third-party and open-source components. A single vulnerability in a widely used library can ripple across vendors and product lines—making Software Bills of Materials (SBOMs) essential for transparency, risk assessment, and incident response across the total product lifecycle. The International Medical Device Regulators Forum (IMDRF) formalized this with its final guidance, “Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity (N73)”, which describes what an SBOM is, how to generate and maintain it, and how healthcare delivery organizations should consume it.
What an SBOM is—and why devices need one
The U.S. National Telecommunications and Information Administration (NTIA) defines an SBOM as a structured inventory of software components and their metadata—the “ingredients list” of a product. This transparency helps manufacturers and operators quickly identify exposure when new vulnerabilities (e.g., in a dependency) are disclosed, and it enables repeatable vulnerability and patch management processes.
IMDRF’s SBOM guidance (N73) dovetails with earlier IMDRF N60 lifecycle cybersecurity practices, positioning SBOMs as part of customer security documentation and post-market risk management. For device makers, that means SBOMs aren’t a one-time deliverable but a maintained asset that evolves with software updates, configurations, and component end-of-support.
Where regulators are today (and what they expect)
In the U.S., the FDA’s final cybersecurity guidance (2025 update) integrates SBOM expectations into quality system and premarket documentation, alongside processes for vulnerability handling, threat modeling, and update mechanisms. The FDA’s public Cybersecurity FAQs also explain how statutory changes (section 524B) affect submissions and postmarket obligations. Manufacturers should expect reviewers to look for SBOM content that’s actionable (e.g., component versions, known vulnerabilities, support status) and kept current throughout the device lifecycle.
Beyond healthcare, CISA’s 2024 framing for software component transparency shows how SBOM data is converging toward interoperable formats and exchange models—useful for scaling supplier management and incident response across complex portfolios and hospital networks.
Practical SBOM essentials for medical-device teams
Per IMDRF N73, an effective medical-device SBOM should clearly identify each component (and transitive dependency), the supplier, version, and unique identifiers, along with relationships and license data. It must also be consumable by customers: documentation should explain how the SBOM is accessed, how frequently it is updated, and how customers can map vulnerabilities to affected configurations. Manufacturers should align SBOM scope and format with their post-market cybersecurity processes so that vulnerability intake (e.g., from CISA/NVD) triggers internal triage, risk evaluation, and—when needed—field actions.
SBOMs for AI/ML and ML-enabled devices (MLMD)
AI-driven devices and machine learning-enabled medical devices (MLMD) depend on extensive software stacks plus data pipelines. While model artifacts aren’t “software components” in the classic sense, the IMDRF MLMD terminology (N67) and broader cybersecurity guidance support the same principle: maintain transparent, version-controlled inventories of the components your safety depends on—frameworks, libraries, runtimes, and security-relevant configs—so you can evaluate and communicate risk when dependencies change. Pair your SBOM with rigorous change control for models and data to preserve safety and performance.
How SBOMs reduce time to action
When a widely used component is found vulnerable, organizations that maintain current, machine-parsable SBOMs can immediately answer: Where do we run this? Which devices are impacted? What versions are affected? That shortens the path from disclosure to containment, patching, or compensating controls—reducing patient and business risk. FDA reviewers, hospital security teams, and incident-response coordinators increasingly expect this level of traceability.
Treat the SBOM as a first-class safety artifact: build it as you build your software, keep it up to date, make it accessible to customers, and wire it into vulnerability management and field-action playbooks. Align content and exchange formats with IMDRF N73 and be prepared to show how SBOMs underpin your premarket claims and postmarket responsiveness.
If you’re planning or executing a submission, MDx CRO can map your current secure-development and post-market processes to the latest expectations, align SBOM tooling and content to IMDRF/FDA, and integrate SBOM handling into your PMS and incident-response procedures.
AI & SaMD: Driving a New Era in Medical Innovation
November 27, 2021
In the rapidly evolving world of MedTech, the convergence of Artificial Intelligence (AI) and Software as a Medical Device (SaMD) is revolutionizing how healthcare solutions are designed, delivered, and regulated. At MDx CRO, we help developers of AI-powered SaMD navigate complex clinical and regulatory pathways with confidence and precision.
Why It Matters:
AI-based diagnostic tools, decision support systems, and therapeutic algorithms promise faster, more accurate patient care. But these innovative technologies bring unique regulatory, clinical, and usability challenges—especially under evolving standards like EU MDR and IVDR.
Our Expertise in Action:
At MDx, we support companies from prototype to post-market, offering:
Regulatory Roadmapping including software classification, performance evaluation, and CE/FDA submissions
Risk Management & Documentation in line with ISO 14971, IEC 62304, and GSPR
Usability Engineering & Human Factors Testing compliant with IEC 62366 and FDA expectations
Post-Market Surveillance (PMS) & PMCF/PMPF Plans for ongoing risk-benefit monitoring
Expertise that Makes a Difference:
Our team has guided software developers through the toughest regulatory transitions and supported numerous Class IIa and Class III SaMD products in gaining CE marking and UKCA certification. With MDx, you don’t just check the regulatory boxes—you build a credible, compliant path to market success.
The Future is Software-Defined
Whether you’re developing AI-based diagnostic tools, clinical decision support systems, or digital therapeutics, MDx CRO is your trusted partner in SaMD innovation. We combine deep technical insight with real-world regulatory experience to help you bring safe, effective, and compliant digital solutions to market—faster.
Gain access to MDx’s Precision Medicine Services Pack—detailing our capabilities in clinical research, regulatory strategy, and companion diagnostics. Learn how we support pharma, CDx, and advanced therapy developers across the clinical and regulatory lifecycle.
