Proper classification determines the amount of work involved
Whether it's SaMD or software embedded in a product: Qualification, classification, and safety class determine how much evidence is actually required.
MDSW · IEC 62304 SaMD & Embedded Software Life cycle & Traceability
Medical Device Software (MDSW): The Robust Regulatory Documentation Framework
Manufacturers should not view software development as a series of isolated, stand-alone documentation artifacts that need only be traceable within the development process. The software documentation must provide third parties with insight into the software’s impact on the product’s safety and performance, the elements of the software and their interactions, as well as the planned and implemented activities of the software life cycle.
10+
Years of MDSW Regulation
35+
Software
Files
Files
35+
IEC 62304 / 82304-1 Projects
25+
FDA Software Submissions
What It's All About
A documentation framework instead of individual documents
Medical Device Software (MDSW) is the term defined in MDCG 2019-11 for software that is itself a medical device (SaMD) and software that is part of a medical device.
Metecon assists with the classification of software, establishes development, change management, and problem-solving processes in accordance with IEC 62304 as needed, creates and links requirements, identifies risks within the product context, develops or assists with verification planning and execution, and creates or assists with software release documentation. This results in comprehensive traceability documentation that links development, regulatory requirements, and product maintenance throughout the entire life cycle. The added value begins in the planning phase, extends through the requirements phase to release—and continues to have an impact as changes are made in response to market feedback and innovation.
Intended for: Heads of regulatory affairs, regulatory managers with MDSW responsibilities, and software and development managers with shared regulatory responsibilities. Executive management of SaMD manufacturers. QM managers and PRRCs.
Typical Challenges
Three Problems That Arise Without a Consistent Documentation Structure
Fragmented Software Life Cycle
Requirements, architecture, testing, and approvals do not interlock consistently. Documentation is not created completely or in a consistent manner.
Lack of Traceability
Requirements and risks are not consistently linked to tests, approvals, and evidence. Gaps only become apparent during an audit. Full coverage of the requirements cannot be demonstrated. This makes it difficult or even impossible to perform regression tests.
Changes Are Uncontrollable
New versions and updates create additional documentation and reconciliation work because the data available for evaluating the changes is not traceable or sufficient. This can affect the implementation of the change and the acceptance of the change (regression testing).
Three Scenarios
SaMD, Embedded Software, and Supporting Software
MDSW encompasses various configurations, each with its own regulatory requirements. Correctly classifying the software from a regulatory perspective is the first step toward robust supporting documentation. The same process model also applies to IVD software (under the IVDR): software for, in, and as an IVD—including, among other things, a performance evaluation instead of a clinical evaluation in the supporting documentation.
Software as a Medical Device (SaMD)
Software in Medical Devices (Embedded)
Software in the Context of Medical Devices
Software as a Medical Device (SaMD)
Standalone software that is itself a medical device and is not part of another product. Its classification as a medical device distinguishes the software in question from non-medical devices.
Classification into risk classes according to the MDR determines the applicable regulatory requirements and the resulting level of evidence required.
Qualification & Classification
decision on whether or not the product is a medical device and its risk class according to MDR Annex VIII (specifically Rule 11) or IVDR, taking into account MDCG 2019-11, clearly justified and documented.
Product vs. Application Environment
Clear identification of the software interfaces to other software systems. Clear delineation of the software from other software systems. Identification of the intended runtime environment for the software (Execution Environment).
Supporting Documentation & Approval
Software documentation that complies with requirements, serving as a robust component of the technical documentation (Link: Technical Documentation →), and evidence of compliance with regulatory requirements, including for international submissions.
Distributed Systems
In distributed systems (e.g., server-client architecture), we clearly define the medical device and document it accordingly in accordance with IEC 82304-1 or IEC 62304.
Relevant Fundamentals
- MDR/IVDR Annex VIII (MDR: Rule 11)
- MDR Annex I, Article 17
- MDCG 2019-11 (qualification & classification)
- IEC 62304 (Life Cycle)
- IEC 82304-1 (product safety of health software)
- IEC 62366-1 (usability)
Software in Medical Devices (Embedded)
Software as an integral part of a medical device, embedded within the device (e.g., firmware). Architecture, SOUP handling, and system interfaces are key elements of the verification process. Here, Metecon provides support for a comprehensive mapping of the software within the 60601-1 context (PEMS/PESS), both in the architectural description and in the requirements domain, as well as in documenting the integration of the software.
Software vs. SOUP as a Software Component
Clear identification of the interface between SOUP and software, including identifying and acknowledging the role of SOUP in architecture, configuration management, and PMS.
Interfaces & Cybersecurity
External interfaces for data transmission (such as USB or Ethernet interfaces) must be evaluated from a cybersecurity perspective in the context of the product. This documentation is also used to demonstrate compliance with regulatory requirements. (Link: Cybersecurity →)
Verification in the System Context
Software verification in the context of the overall product, consistent with planning, metrics, completeness, and clear documentation, and seamlessly integrated into the product's overall documentation.
Relevant Fundamentals
- IEC 62304 (life cycle, safety classes, SOUP)
- IEC 60601-1 (active devices)
- IEC 82304-1 (health software)
- MDR/IVDR
- MDR/IVDR Annex I GSPR
- Interface to cybersecurity (IEC 81001-5-1), risk management (ISO 14971), and usability engineering (IEC 62366-1)
Software in the Context of Medical Devices
Software that supports or complements medical devices in a medical context. Only after qualification and classification can it be determined whether and to which extent the software is subject to regulation.
Qualification Check
Medical device: yes/no—clearly determined and justified based on the intended purpose and the classification rules.
Intended Purpose Clearly Defined
A precise definition of the intended purpose delineates functions and responsibilities and prevents costly misclassifications.
Relevant Fundamentals
- MDCG 2019-11
- Intended Purpose
- Distinction from Non-Medical Devices
- IEC 82304-1 (health software) – in case of classification as health software
Focus on the Process
IEC 62304 governs the software life cycle process. Integrating software aspects into the process landscape is a key element for the successful implementation of IEC 62304. Metecon can assist in designing the process interfaces, thereby ensuring optimal communication between departments.
The Path to the Verification Structure
Making the Software Life Cycle Verifiable in 7 Steps
1
Classification & Scope of Application
Determine the qualification and classification of the software as a product and its safety class in accordance with regulatory requirements (e.g., EN 62304 or other country-specific / international regulations)—the basis for determining the appropriate level of effort.
2
Software Development Planning
EN 62304 specifies requirements for the content expected in the development plan. The software development plan maps out the processes and activities involved in software development, as well as downstream activities.
3
Risks & Measures
Assess software risks, derive risk control measures, and link them to risk management in accordance with ISO 14971.
4
Requirements & Architecture: Detailed Design
Specify software requirements and architecture to ensure regulatory compliance, including SOUP and interfaces.
5
Implementation Requirements
Traceability, establishment of coding guidelines, and integration of unit test criteria. Support in identifying and validating the software tools used.
6
Verification & Traceability
The backbone of the traceability structure: Consistently linking requirements, risks, tests, and development results so that it can be verified at any time that every requirement and every risk has been tested and addressed in the release. Support for test planning, test specification, and test execution. Support for the evaluation of test results within the regulatory context.
7
Release, Changes & Updates
Keep releases, changes, and updates under control with a transparent assessment of the impact of changes, without increasing coordination efforts. Support for the release of external software development.
Traceability is the backbone
Requirements ↔ risks ↔ tests ↔ releases are consistently linked. This turns documents into a robust, audit-ready documentation structure.
Why Metecon
In-depth Reporting Instead of a Patchwork of Documentary Pieces
From the “What” to the Verifiable “How”
We translate regulatory requirements into practical, comprehensive supporting documentation—no patchwork of individual documents.
Supporting Documentation and International Filings
35+ software files and 25+ FDA submissions: robust evidence for the EU and the U.S. from a single source.
A Focus on Interfaces
Risk management, usability engineering, V&V, cybersecurity, AI, and technical documentation are consistently interwoven within the verification structure.
15+ software system verifications 5+ experts in MDSW & QMS 25+ FDA submissions (international)
The selection criteria are based on the strengths of leading providers: up-to-date knowledge of standards, scalable support, and practical, domain-specific consulting.
Metecon meets these benchmarks and combines them with evidence-based documentation tailored to the needs of the EU and international markets.
Separate Pages for Related Topics
We cover cybersecurity, AI regulation (AI Act), and software validation on dedicated pages—linked here as components of the MDSW evidence structure.
What We Do, Specifically
Services Throughout the Software Life Cycle
-
Regulatory Classification & Strategy
Qualification, classification, and a robust regulatory strategy for the EU (MDR/IVDR) and internationally (including the FDA).
-
Development Documentation in Accordance with IEC 62304 & IEC 82304-1 / IEC 60601-1
Design of software life cycle processes: from planning, through requirements, architecture, verification, and validation, to maintenance and PMS.
Analysis of interfaces within the existing process landscape with regard to the software life cycle, risk management, information security, and usability.
Tool validation: Validation of the tools used in the software life cycle (compilers, bug tracking, CI infrastructure).
DiGA: Digital health applications approved by the BfArM that can be prescribed by a physician. DiPA: Digital care applications to support daily care activities, subject to BfArM review procedures.
-
GAP Analysis of Existing Technical Documentation
Review of existing documentation for gaps in compliance with the MDR/IVDR and relevant standards—with specific recommendations for action.
-
Communication with Notified Bodies & Regulatory Authorities
We support your interactions with Notified Bodies and regulatory authorities in Europe and with international agencies (e.g., the FDA)—from preparation and coaching to comprehensive 360° support for approvals and audits.
-
Workshops & In-House Training
Training sessions and workshops for your development, quality management, and regulatory teams.
-
Adapting Processes & QMS
We establish robust development, software, and QM processes (ISO 13485) for MDSW and help to maintain them continuously.
Our Holistic Approach
We support you with all regulatory tasks throughout your development process—from a single source, across the entire life cycle.
Interfaces
What the MDSW detection structure is integrated with
Cybersecurity
Integration of security requirements and evidence into the release logic (IEC 81001-5-1).
Learn more →
Usability Engineering
Proper integration and validation of UI- and use-related risks (IEC 62366-1).
Learn more →
Risk Management
Consistent documentation of software risks, measures, and residual risks (ISO 14971).
Learn more →
Verification & Validation
Alignment of test strategy consistently with requirements and risks.
Learn more →
AI Regulation
AI-based software requires robust documentation to support its development, changes, and monitoring (EU AI Act).
Learn more →
Thorsten Stumpf
Principal Expert Software & AI · RAC Devices · Metecon GmbHThorsten Stumpf is one of the software specialists on the Regulatory Affairs & Technical Documentation team and has an extensive network within the industry on this topic. Thorsten has many years of experience in the regulatory classification of medical device software, including the review of software life cycle documentation in accordance with IEC 62304. He assists manufacturers with classification, regulatory strategy, and technical documentation for MDSW.
IEC 62304 / 82304-1 • 35+ software files• 25+ FDA submissions“It is not the volume of documents that determines medical device software, but rather their end-to-end traceability: requirements, risk management, verification, validation, releases, and PMS—all robustly linked. We build this structure from the very beginning in accordance with IEC 62304, IEC 82304-1, and IEC 60601-1. For a system that supports the entire life cycle."
– Thorsten Stumpf, Principal Expert Software & AI · RAC Devices, Metecon
Frequently Asked Questions About Medical Device Software
What distinguishes medical device software from other software in the medical device context from a regulatory perspective?
MDSW is the EU umbrella term and encompasses software that is a standalone medical device (SaMD) as well as software that is part of a medical device. The intended use is the decisive factor: it is the medical intended use that makes software a medical device.
At which stage of development should the verification structure be established?
Ideally, the planned documentation structure—as required by regulations—should already be outlined in the development plan. Activities carried out later can be extremely costly and time-consuming.
How can I tell if my processes are robust or merely documented for form's sake?
A documentation structure is considered robust if it comprehensively and fully addresses regulatory requirements—not if documents merely exist side by side.
How is the software safety class determined according to IEC 62304?
The class (A/B/C) is based on the potential harm resulting from software failure—assessed in light of the risk context, risks, and risk control measures. Appropriate measures can lower the software security class. A lower class requires less information to be included in the submission.
How is transparent traceability achieved?
By consistently linking requirements, risks, tests, and development results, and by ensuring and maintaining traceability across all development stages, it can be demonstrated that every requirement and every risk has been verified and addressed in the release.
How can we keep releases, updates, and changes under control?
Through a defined change and approval process with a traceable procedure model, taking into account the risk context and the feasibility of the change.
How are the interfaces with risk management, usability engineering, cybersecurity, and clinical evaluation/performance evaluation taken into account?
The process structure integrates these disciplines as interconnected inputs and outputs: software risks into risk management; hazard-related use scenarios from usability engineering into risk analysis; identified attack scenarios from cybersecurity into risk analysis; and preclinical findings as the basis for the clinical evaluation/performance evaluation.
How much does MDSW's regulatory support cost at Metecon?
The effort required depends on the specific circumstances, safety class, level of evidence, regulatory capabilities, and target markets (e.g., EU/FDA). During a free initial consultation, we’ll assess your case and provide a reliable framework.
Ensuring Regulatory Compliance for Medical Device Software
Start with a free initial consultation—we’ll classify your software (SaMD or software-as-a-device), determine the safety class, and outline the documentation structure for the EU and FDA.
Your contact:
Milan Weiß
Sales Manager
T: +49 621 123469-040
milan.weiss@metecon.de
