Over the past ten years, we have learned a great deal about the development of software medical devices. We are pleased to share this expertise in our technical articles with (prospective) developers of Software as a Medical Device (SaMD) so that not everyone has to learn the same lessons themselves.
We develop software medical devices for start-ups, pharmaceutical companies, and other firms, and therefore accompany the entire development cycle of these products—from the initial idea to permanent approval and beyond.
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 this subject, it makes sense to simply work through the content chronologically from top to bottom.
Table of contents
- 1. Qualification and classification of software medical devices
- 1.1 Phrasing the Intended purpose for (software) medical devices
- 1.2 Qualification: Is your software a medical device?
- 1.3 Classification of software medical devices: MDR guidance document
- 1.4 MDR Risk Class I vs. IIa: Differences for software medical devices
- 1.5 Class I software according to MDR – Is that still possible? (January 2025)
- 2. Guidance on aspects of SaMD development and authorization
- 2.1 Approval & certification of software medical devices (MDR)
- 2.2 IEC 62304: Software life cycle processes for medical devices
- 2.3 ISO 13485 – Guidance on requirements and content
- 2.4 Software as a medical device: 11 certification tips for manufacturers
- 2.5 Validation of medical device software according to MDR
- 2.6 MDR Guide: Clinical evaluation of software medical devices
- 2.7 Artificial intelligence (AI) in medical devices – MDR guidance (2025)
- 2.8 Approving software medical devices without quality management and regulation?
- 3. Reimbursement & compensation 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 according to ZPP – Central Testing Agency 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 Reimbursement of costs 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 Phrasing the Intended purpose for (software) medical devices
At the beginning of every medical device development, the intended purpose should be phrased, which also serves as the basis for classification into a risk class according to MDR:
1.2 Qualification: Is your software a medical device?
Once you have phrased the intended purpose, the question arises: “Is your software actually 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 document
The risk class of a medical device makes a huge difference to the effort and costs you will need to invest in order to obtain 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 huge differences in terms of costs and timelines for product development, particularly 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 into Class I as of 2025.
2. Guidance on aspects of SaMD development and authorization
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 process for software as a medical device (SaMD).
2.2 IEC 62304: Software life cycle processes for medical devices
IEC 62304 is probably the most important standard for developing software-based 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 compiled our most important lessons learned and tips for future manufacturers here.
2.5 Validation of medical device software according to MDR
Before a software medical device can be launched on the market, it must be formally validated. 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 many manufacturers. We explain 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 (2025)
MDR medical devices may, of course, contain artificial intelligence (AI). However, the approval of such products brings with it a number of additional challenges. Here, we discuss what you need to consider when developing AI medical devices.
2.8 Approving software medical devices without quality management and regulation?
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, you can! By transferring the role of legal manufacturer to an external provider, you can completely outsource regulatory requirements to a third party.
3. Reimbursement & compensation for software medical devices
Our white paper ‘All paths to reimbursement for medical software and health apps (in 2025)’ provides an overview of all paths to reimbursement.
Approval as a medical device in accordance with MDR enables you to market your product. However, this does not mean that you will automatically 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 paths for software products to obtain reimbursement.
3.1 Digital health applications – our detailed guidelines
DiGA approval is probably the most popular route to reimbursement for patient-oriented applications and DTx. However, approval is anything but easy and involves enormous regulatory hurdles. We have written specialist articles on many aspects of the approval process 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 agreements 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 Agency for Prevention
Legal manufacturers of products that focus on disease prevention should look into the Central Testing Agency for Prevention. This is one way to get (some) of the costs of these products covered.
3.4 DiPA: digital applications for nursing care
The equivalent of DiGA in nursing care is DiPA. Find out how you can potentially get DiPA reimbursed here.
3.5 Reimbursement for software included in the GKV list of medical aids (HMV)
Software products that qualify as medical aids and, for example, compensate for a bodily malfunction, can potentially be included in the list of medical aids. This represents a further step towards reimbursement by health insurance companies.
3.6 Innovation funds and other subsidies for health software
There are various public funding programs available for legal 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.
3.7 Reimbursement of costs for software in hospitals
From AI-supported diagnostic software to digital decision support systems, medical software products are increasingly finding their way into German hospitals. However, their success depends not only on their clinical benefits, but also on the right financing strategy. For manufacturers, the question is: How can they gain market access in inpatient care, and what billing options are available?
4. Further current information on the development of medical device software and DiGA
We have invested a great deal of time and effort 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 detailed reports on current topics in the field of medical device software and DiGA development on a monthly basis.
You can subscribe to the newsletter here: to the newsletter
You can also find the latest developments and news on DiGA & medical software on our news page.
