The prescription numbers for digital health applications (DiGAs) are still low at the moment. In order for this to change, DiGAs must be successfully implemented – from the generation of ideas to the business model, with appropriate placement on the market. A case study explains the various phases and hurdles that providers of health apps have to overcome.
With the entry into force of the Digital Supply Act, around 73 million people with statutory health insurance have the opportunity to use digital health applications (DiGAs). With the help of smartphone apps, they can monitor their sleep, automatically transmit their blood sugar values to the family doctor or confirm suspicions of an infection. The software solutions are designed to help both doctors and patients in the treatment and prevention of diseases. The Federal Institute for Drugs and Medical Devices (BfArM) has already approved some apps as digital health applications (DiGAs) – but the number of prescriptions is currently still low.
The following case study is about an app that is supposed to reduce the number of ear canal infections. Around ten percent of the German population have painful experiences with this disease in their lifetime. With a corresponding app, users could not only recognize the first symptoms at an early stage but also receive advice on therapeutic measures. Now the question arises: what does such an app look like in concrete terms? What is technologically required? Three points are crucial in this first phase: the creation of a prototype, a feasibility study, and the project design.
The prototype
After the decision has been made to develop an app, the first step is to design a prototype. The prototype makes the application experience tangible and illustrates what the app should look like. It must be clarified which user and patient need the app should meet, which symptoms can occur in the case of ear canal inflammation and which applications can be derived from this.
In order to create a presentable prototype from a rough sketch of the idea, you should work iteratively and together with a creative team. Thanks to the early visualization of the application, important questions about functionality can arise and be resolved in good time. The prototype of the app should also be checked with regard to data protection, compliance, and classification as a medical device. In addition, the development team should already have an approximate idea of how an assessment of the benefit in terms of the “positive supply effects” could look like – because that is where the permanent approval as a billable DiGA stands and falls in the end.
The feasibility study
Between the prototyping and the actual implementation phase, the technical implementation of the idea should be checked by means of a feasibility study. This takes into account which data the app should collect and whether a clinical study is required as evidence of positive health care effects. So in this phase, it is not just a matter of checking the technological feasibility, but of understanding the entire ecosystem. A high level of acceptance can only be assumed if the later solution can be integrated as seamlessly as possible into the health system.
Project design and set-up
Implementation of the app now begins on the basis of the feasibility study. As is usual with software projects, the most agile approach possible is ideal. At this point, the relevant regulations for medical devices must also be observed. It can make sense to bring other initiators or even partners on board in order to ensure that it is embedded in the entire ecosystem. These can be health insurance companies, compliance experts, or app providers who have experience from comparable products.
Proof of effectiveness
In order to minimize the risks of the investment, the implementation of the app in the form of a pilot is recommended. This should be equipped with all important core functions so that a check can take place in the real world. For example, short field tests can be carried out with doctors and patients in order to gain empirical values about user-friendliness and practicality. If possible, the pilot should also collect information directly about positive health care effects – as a support for the later approval of the DiGA.
As soon as the app has been developed and all specified requirements have been met, you can register using the BfArM’s “DiGA Fast Track” procedure. As a result, a DiGA is a CE-marked medical product with the following properties:
- The medical device of risk class I or IIa according to MDR or, within the framework of the transitional regulations, according to MDD.
- The main function of DiGA is based on digital technologies.
- The medical purpose is essentially achieved through the main digital function.
- The DiGA supports the detection, monitoring, treatment, or alleviation of diseases or the detection, treatment, alleviation, or compensation of injuries or disabilities.
- The DiGA is used jointly by the patient or by the service provider and patient.
If direct positive supply effects can be proven, permanent inclusion in the DiGA register can take place. Preliminary admission is possible if the relevant clinical studies are still pending.
If the app receives approval from the BfArM for the German market, it should be continuously monitored how it is received by the target groups in order to make possible adjustments. System and product audits as well as data analytics check usability as well as information security and data protection.
From the idea to the business model
In this case study, the health app should avoid painful infections – but also bring the provider a monetary profit. Since January 2020, the legislator has provided for manufacturers to be remunerated when the services are used by health insurance companies. This possibility is promising, but it is not the only way to develop a business model. B. also sells directly outside of Germany in other European countries as a payment app. In addition, contracts can be concluded with private insurers, because there is currently no basic reimbursement of DiGAs with them. In the case of direct marketing, it should be noted that the approved DiGA itself may not be used for marketing purposes; Advertising within the app is prohibited.
As a manufacturer of a DiGA, the focus should not only be on other markets. The prevention of other diseases is also exciting. The know-how that was gathered during the development and approval of the DiGA can ultimately also be used for other digital applications, in this case, for example for other ENT diseases. DiGAs that have already been developed can be expanded and optimized or serve as the basis for other health apps.
You can find more articles on topics such as e-health and telemedicine in our topic channel e-health.
