The development of software medical devices is complex, and unfortunately, high-quality information on the subject is limited on the internet. We have been developing software medical devices for customers on a contract basis for over 10 years. During this time, we have implemented a wide range of app and software products (over 35 in total) that have been approved as medical devices. We are happy to pass on our expertise in this area to (prospective) developers of Software as a Medical Device (SaMD) in our technical articles, so that not everyone has to learn the same lessons for themselves.
In this article, we would like to give you an overview of the topics we have written about so far.
Tip: If you are new to the subject, it makes sense to simply work your way through the content chronologically from top to bottom.
Table of contents
- 1. Qualification and classification of software medical devices
- 1.1 Formulation of the intended use for (software) medical devices
- 1.2 Qualification: Is your software a medical device?
- 1.3 Classification of software medical devices: MDR guidance
- 1.4 MDR risk class I vs. IIa: Differences for software medical devices
- 1.5 Class I software according to MDR – Is this still possible? (January 2025)
- 1.6 IVDR software: Qualification and classification
- 2. Guidelines on aspects of SaMD development and approval
- 2.1 Approval and certification of software medical devices (MDR)
- 2.2 IEC 62304: Software life cycle processes for medical devices
- 2.3 ISO 13485 – Guidelines on requirements and content
- 2.4 Software as a medical device: 11 certification tips for manufacturers
- 2.5 Validation of medical device software in accordance with MDR
- 2.6 MDR guidance: Clinical evaluation of software medical devices
- 2.7 Artificial intelligence (AI) in medical devices – MDR guidance (2026)
- 2.8 Approval of software medical devices without quality management and regulation?
- 3. Reimbursement and remuneration for software medical devices
- 3.1 Digital health applications – our detailed guidelines
- 3.2 Selective contracts with health insurance companies: The alternative to DiGA
- 3.3 Certification of digital courses in accordance with ZPP – Central Office for Prevention
- 3.4 DiPA: digital applications for nursing care
- 3.5 Reimbursement for software included in the GKV list of medical aids (HMV)
- 3.6 Innovation funds and other subsidies for health software
- 3.7 Cost reimbursement for software in hospitals
- 4. Further current information on the development of medical device software and DiGA
1. Qualification and classification of software medical devices
Intended purpose and classification of medical devices
1.1 Formulating the intended purpose for (software) medical devices
At the beginning of every medical device development, the intended purpose should be formulated, which also serves as the basis for assigning the risk class according to MDR:
1.2 Qualification: Is your software a medical device?
Once you have formulated the intended purpose, the question arises: “Is your software even a medical device according to the MDR?” If this is not the case, you do not need to concern yourself further with the MDR.
Read this article to find out for your product.
1.3 Classification of software medical devices: MDR guidance
The risk class of a medical device makes a huge difference to the effort and costs you will need to invest in obtaining approval. You should therefore clarify this before starting product development.
1.4 MDR risk class I vs. IIa: Differences for software medical devices
There are enormous differences in costs and timelines for product development, especially between risk class I and risk class IIa. What are the differences for you in practice?
1.5 Class I software according to MDR – Is that still possible? (January 2025)
We discuss which software medical devices may still fall under Class I as of 2025.
1.6 IVDR software: Qualification and classification
If your software is intended for obtaining information through in vitro examinations, it may fall under the IVDR (In Vitro Diagnostics Regulation). Our guide explains how you can qualify and classify your software under the IVDR to ensure that it meets the relevant regulatory requirements.
2. Guides on aspects of SaMD development and approval
Timeline: The path to medical device approval
2.1 Approval & certification of software medical devices (MDR)
Here we provide a holistic overview of all aspects of the approval of Software as a Medical Device (SaMD).
2.2 IEC 62304: Software life cycle processes for medical devices
IEC 62304 is arguably the most important standard for the development of software medical devices. But how exactly can it be put into practice, and can it be combined with agile development?
2.3 ISO 13485 – Guidance on requirements and content
The quality management system of a SaMD manufacturer should be in line with ISO 13485 within the framework of the MDR. This is the most important standard for the conformity of quality management systems for medical devices.
2.4 Software as a medical device: 11 certification tips for manufacturers
We have been developing software medical devices on a contract basis for other companies for over 10 years. We have written down our most important learnings and tips for future manufacturers here.
2.5 Validation of medical device software according to MDR
Before a software medical device can be placed on the market, it must be formally validated. You can find out exactly what this means here.
2.6 MDR Guide: Clinical evaluation of software medical devices
Clinical evaluation is at the heart of software medical device validation and poses major challenges for some manufacturers. We discuss what you need to do in this context. We also explain when you need to conduct a clinical study/trial and when a literature review is sufficient.
2.7 Artificial intelligence (AI) in medical devices – MDR guidance (2026)
MDR medical devices may, of course, also contain artificial intelligence (AI). However, the approval of such products brings with it a number of additional challenges. Here, we discuss what you should consider when developing AI medical devices.
2.8 Approving software medical devices without quality management & regulations?
DiGA and the Medical Device Regulation (MDR) present manufacturers with a host of challenges – from setting up a quality management system (QMS) to creating technical documentation. No wonder many companies are wondering whether they can outsource this complexity.
The good news is: yes, they can! By transferring the role of legal manufacturer to an external provider, the regulatory requirements can be completely outsourced to a third party.
3. Reimbursement & compensation for software medical devices
Approval as a medical device under the MDR enables you to market your product. However, this does not necessarily mean that you will earn money with it.
In the German healthcare system in particular, it is often advisable to find a way to have your product reimbursed by health insurance companies. Depending on the type of software product, there are a range of reimbursement options available.
The following guides provide an overview of important ways for software products to be reimbursed.
3.1 Digital health applications – our detailed guides
Approval as a DiGA is probably the most popular way for patient-oriented applications or DTx to be reimbursed. However, approval is anything but easy and involves enormous regulatory hurdles. We have written specialist articles on many aspects of approval to provide manufacturers with additional information.
→ Link to all insights on DiGA development and approval in 2025
3.2 Selective contracts with health insurance companies: The alternative to DiGA
Selective contracts with health insurance companies are suitable for a wide range of SaMD and are a popular route to reimbursement.
3.3 Certification of digital courses according to ZPP – Central Testing Center for Prevention
Manufacturers of products that focus on disease prevention should look into the Central Testing Center for Prevention. This represents a possible way to (partially) reimburse the costs of such applications.
3.4 DiPA: digital applications for nursing care
The counterpart to DiGA in nursing care is DiPA. Find out how you can potentially get DiPA reimbursed here.
3.5 Reimbursement of software in the GKV medical aids directory (HMV)
Software products that qualify as medical aids and, for example, compensate for a malfunction of the body, can potentially be included in the medical aids directory. This represents another way to obtain reimbursement from health insurance companies.
3.6 Innovation fund and other subsidies for health software
There are various public funding programs for manufacturers of digital health solutions, depending on the project focus, maturity, and target market. One of the most important and practical sources of funding in the German healthcare system is undoubtedly the G-BA Innovation Fund, which specifically supports new forms of care and offers attractive opportunities for software projects related to healthcare.
In addition to the Innovation Fund, there are other national and European funding instruments that can reduce development, study, or implementation costs and strategically secure market entry. Our white paper “Financing and Funding Digital Health Products” provides a structured overview of relevant funding programs, typical funding logic, and strategic classification.
3.7 NUB as cost reimbursement for software products in hospitals
Could the NUB procedure (“New Examination and Treatment Methods”) be a way to reimburse software innovations in hospitals? We analyzed over 2,400 NUB applications – with exciting results on the opportunities and limitations of cost reimbursement for digital solutions in hospitals.
4. Further current information on the development of medical device software and DiGA
We have invested a lot of work and time in creating these guidelines and articles. We hope that they will provide you, as a manufacturer, with support in meeting your challenges.
As an additional service, we recommend our newsletter, in which we send out detailed monthly reports on current topics in the field of medical device software and DiGA development.
You can subscribe to the newsletter here: to the newsletter
