In our case study, the decision has already been made to develop an app. Now the first step is to design a prototype of the “OtiApp”. The focus here is on answering the following questions, among others:

• Which user and/or patient requirements should the app fulfill? Evaluation and prioritization of unmet need from a functional, emotional and social perspective.
• For example, are there frequently occurring symptoms in the course of an ear infection - and what specifically characterizes them?
• Which “user stories” can be outlined based on this? What are the most important use cases that would have to be covered by the app and what do they look like – in broad terms?

An iterative approach, ideally carried out with a creative team (e.g., design agency), is recommended during the prototyping phase. This gets you from a rough draft of the idea to a working and presentable prototype. Advantages: The prototype is visualized at an early stage, which means that important issues regarding functionality arise and can be solved in good time.

Co-creation or co-development is another very important component, which can contribute significantly to the success of the project and its practicability. Here, the prototype is developed with patients and physicians and a foundation is laid for long-term cooperation. To further validate the results of this phase, social media monitoring can also be beneficial. For instance, by evaluating how ear infections are discussed in social networks and which aspects of this are not yet or insufficiently documented in clinical studies, for example.

At this point, the prototype should also be initially evaluated with regard to data protection, compliance and classification as a medical device. The team should now also have a rough idea of what a possible benefit assessment could look like in terms of “positive healthcare effects” After all, this is what ultimately determines permanent approval as a billable DiGA. And, of course, an acceptable option would be to implement this simply as are a “wellness app”, which is then not a medical device and therefore not a DiGA. However, we would then be in the realm of a purely informational app.

The prototype makes the application experience tangible and gives an idea of what the “OtiApp” should look like, from A to Z. Before directly starting with an implementation, a feasibility study should be conducted to determine how realistic an implementation might be. As a rule, aspects of technical, economic, organizational and time-related feasibility must be clarified here. Since this is a strongly regulated market, an in-depth analysis of the regulations must take place at this point. The following questions can serve as a guide for the feasibility study:

• What kind of risk analysis should to be performed? What impact does this have on the classification as a medical device – and, in particular, which class?
• Is the implementation of the idea technically possible? Are there technologically similar approaches and/or applications? Is the DiGA intended to be an in-house development or should a technology partner be used for the implementation?
• What data is the app going to collect? What are the data protection requirements in terms of GDPR and patient data protection law (PDSG)?
• Is it possible to ensure that all regulatory requirements in terms of quality management (e.g., according to ISO 13485) can be met?
• Are there other barriers to implementation besides the technological dimension? Especially at process, organization or ecosystem level?
• Which drivers are crucial to enable scalability on the market at a later stage?
• How can proof of positive care effects be obtained, e.g., in terms of a clinical study?

In this step, not only the technological feasibility needs to be evaluated, but the entire ecosystem also has to be understood. Only if the future solution can be integrated as seamlessly as possible into the healthcare system can a high level of acceptance be assumed. Finally, plausible proof of the clinical benefit is essential, which is the most important point in the interest of patients and physicians as well as for long-term approval as a DiGA. Following a positive result of the feasibility study, a practical implementation can take place in the next phase of the DiGA journey.

The OtiApp has successfully passed the previous steps. This phase is concerned with the concrete implementation. Similar to other software projects today, the aim here is to adopt as agile an approach as possible. However, a corresponding detailed planning phase should not be neglected so as to be able to evaluate topics such as budget and resource requirements more precisely. The basis here should be the information collected in the feasibility study. At this point, a decision must be made as to who is to develop and ultimately operate the app. In particular, the relevant regulations for placing medical devices on the market must be adhered to. The following key questions help you to carry out the detailed planning:

• How many and which resources are required, in terms of time and budget?
• Which work packages can be handled internally and for which is external support required?
• How complex is the solution architecture likely to be? What technical infrastructure already exists and/or should the solution be hosted in the cloud, if required?
• What IT security requirements need to be met?

At this point, it can be beneficial to bring additional initiators or even partners on board to ensure embedding in the entire ecosystem or to be able to better evaluate it. This might be a health insurer, compliance experts or technology providers such as app providers, who can contribute experience and use patterns from comparable products. Not only the development costs of the app must be considered, but also other costs such as for the approval, clinical studies, marketing and subsequent operation.

The OtiApp has now been classified as a medical device and provisionally included in the DiGA register. The proof of positive care effects is still missing. With the inclusion in the register, the app can now be prescribed by physicians and will then also be reimbursed by the statutory health insurers. The app publisher now has 12 months to confirm the clinical benefit. Otherwise, the device will be delisted from the DiGA register and thus the possibility of reimbursement by the statutory health insurers will no longer apply.

Unlike traditional medical devices, for which only basic compliance must be demonstrated, proof of positive effects on care is required for the DiGA. How exactly this is to be done and by what means has not yet been clearly defined. What is clear is that all data must be valid, comprehensible and collected according to scientific standards. The study's design itself can be freely selected and also depends on the type of DiGA. A retrospective study, which is explicitly mentioned in the DiGA guidelines, might be an option, for example. Merely citing studies that have already been conducted is never sufficient. In particular, we consider the following questions during the study design to be useful, especially with regard to the highest possible acceptance in the professional community when it comes to subsequent publication and marketing:

• Which results must the study produce to clearly demonstrate the effectiveness of the DiGA?
• Which patient target group can be considered for the study?
• Which experts (KOLs - key opinion leaders) could be attracted for the study and/or clinics could be of interest?
• How will the collected data be evaluated?
• Which data can be used for comparison purposes?

How can data integrity be ensured at all times?

In our case study, “OtiApp” is intended to prevent painful infections - but also to bring in money for the provider. Since January 2020, the German legislature has in principle provided for DiGA providers to be reimbursed when services are rendered to health insurers. This recently created opportunity for providers of healthcare apps is promising, but not the only variant for developing a business model. For instance, the app could be marketed directly to patients in other European countries outside Germany as a paid app. Or direct contracts with private medical insurers could also be concluded, for whom there is currently no basic reimbursement of DiGAs. For all direct marketing variants, it should be noted that the approved DiGA itself may not be used as a marketing instrument as advertising within the app is strictly prohibited.

If “OtiApp” is to be used in the future to prevent ear infections not only in Europe but also worldwide, the requirements of the FDA in the USA or other regulatory authorities must be taken into account. Decisive for the approval and reimbursement in Germany is the DiGA fast-track procedure mentioned above. 

Another option would be to enter into partnerships with pharmaceutical companies to offer the app as a white-label solution, for example. Alternatively, further use cases could be covered with the help of medical device providers. Data collected in studies and further usage data of the app could also be used on the one hand to gain knowledge, but also for other use cases - of course in compliance with all data protection legal requirements. It might also be possible to open up further sources of income. In the case of partnerships and close collaborations, however, careful consideration should be given to how to ensure proper handling of the issue of intellectual property.