Medical apps are now being used more and more frequently, e.g. in disease prevention, disease diagnostics, disease treatment or for the monitoring of vital parameters. However, it is not that easy to launch a medical app on the market that is secure and compliant with data protection and medical device law within the MDR (Medical Device Regulation). In this article, we discuss the most important challenges app manufacturers face when developing a medical app.
Particular features in the development of medical apps
When developing medical apps, you must of course first consider the same things as when developing apps in other areas: an intuitive user interface, a scalable and flexible software architecture, etc.
However, there are some requirements that are particularly important for medical apps:
- Quality management within the regulatory framework
- Data protection
- Data security
- Software quality
- Communication with medical devices wearables
- Different hardware and runtime environments
In the following sections, we will take a closer look at these challenges.
1. Quality management within the regulatory framework
Defining the medical device class and intended purpose
In this article, we assume that you want to place your product on the European market first and do not focus on the regulatory requirements of other markets (e.g. the FDA in the USA). Medical device manufacturers in Germany and other EU countries must comply with the MDR (Medical Device Regulation) guidelines. The MDR replaced the MDD (Medical Device Directive) on 05/26/2021. In this article, we therefore deal explicitly with the requirements of the MDR. If your app is a medical device within the meaning of the MDR, you must set up and maintain a quality management system. You should clarify whether this is the case and what risk class it has in this case with a regulatory expert before starting development (please contact us in this regard). As a very rough rule of thumb, apps that have the purpose of preventing, diagnosing or treating illnesses are usually medical devices. We have also written an extensive guide on the topic of “Is your app a medical device?”, which you can find here. Further information can also be found in our article on the intended purpose. Which medical device class the app then has depends, among other things, on the patient risk. The higher the potential (indirect) damage caused by your app, the higher the medical device class will be. However, the classification rules are complex, and it is essential to consult an advisor. The following simplified decision tree (based on Rule 11 of the MDR) can be helpful for an initial rough assessment.
- If your app provides information that is used to make decisions for diagnostic or therapeutic purposes: Class IIa
- however, could your app potentially cause death or irreversible deterioration of a person’s health: Class III
- could your app potentially cause a serious deterioration in a person’s state of health: Class IIb
- Any other app: Class I
We have also written a comprehensive practical guide for the risk classification of an app, which you can find here.
Establishing a quality management system: ISO 13485
If you want to launch an app on the market as a medical device, you can hardly avoid setting up a quality management system certified to ISO 13485. Class I apps are the only exception. No certified quality management system is required here. However, a basic quality management system is also required for Class I products. A complete guide to setting up a quality management system in accordance with ISO 13485 is beyond the scope of this article. That is why we will focus on the most important standards here that you need to observe when developing a medical app.
Compliance with a documented software life cycle: IEC 62304
A medical app falls under the definition of “medical device software”. Therefore, you will work according to the IEC 62304 standard (not explicitly required, but the absolute standard) in order to pass the conformity procedure. The standard specifies five processes according to which the software must be (further) developed:
- Software development process
- Software maintenance process
- Software risk management process
- Software configuration management process
- Software problem-solving process
As part of the software development process, technical documentation must then be prepared, e.g. on the software architecture and on unit/integration and system tests. You must also document your SOUPs (Software of Unknown Provenance) extensively, for example. These are, for example, external software libraries that you use. Experience has shown that there are particularly many of these with mobile apps. From time to time, we hear voices saying that agile development is not possible within the regulatory framework. However, this is not correct. With a suitable quality management system and the right automation tools, agile development is of course also possible in the regulated development of medical apps. You can find more information on the standard in our comprehensive article on IEC 62304. It is also currently being discussed whether IEC 82304 will be used in addition to IEC 62304 in the future. IEC 82304 is an extension of IEC 62304.
Identifying and analyzing risks: ISO 14971
You should know exactly where the risks of your app are hidden. If your app calculates incorrect values, crashes or is simply used incorrectly, a patient could potentially come to harm. The ISO 14971 standard therefore deals with the risk management of medical devices. Risks must be identified and controlled (and, if necessary, eliminated by taking additional precautions). A basic distinction is made between damage (e.g. a cut), hazard (e.g. a knife) and risk (the combination of the probability of the damage occurring and the severity of this damage). You must now decide for each risk whether it is acceptable or unacceptable, taking into account the probability of damage and the severity of damage. Whether a risk is acceptable depends on the product benefit.. You must weigh up whether the risk is acceptable in relation to the product benefit. For example, if a product has no benefit, no risk is acceptable. There are various methods for risk analysis, such as the Preliminary Hazard Analysis (PHA), the Fault Tree Analysis (FTA) and the Failure Mode and Effects Analysis (FMEA).
Ensuring usability: IEC 62366
Your user interface should not only look good, but also prevent errors during use. Take, for example, an app for controlling an insulin pump: the patient must be clearly told in this app which button triggers an insulin injection. In the worst case, an insulin overdose can even lead to death. Accidental triggering is therefore an unacceptable risk. This is exactly what IEC 62366, the standard for the usability of medical devices, deals with. Many fatalities with medical devices are not necessarily due to malfunctions, but to poor usability and therefore incorrect use. Usability engineering is also part of risk management. To ensure the usability, it may also have to be proven by clinical studies and validated accordingly. Find out more here: Validation of medical device software according to MDR
Notified bodies and the auditing process
If your app falls under risk class IIa or higher, you must consult a notified body. Notified bodies are usually private-sector companies (such as TÜV) that have been selected by the state to assume sovereign tasks in the approval and monitoring of medical devices. Notified bodies check your technical documentation, for example, and audit and certify your quality management system. In addition, you will carry out unannounced inspections (so-called audits) at regular intervals to check whether, for example, the documented quality management system is being implemented by the team on a daily basis. Find out more about notified bodies and the process leading up to medical device approval here: Approval certification of software medical devices (MDR)
2. Data protection
First of all, please note that data protection and data security are two different fields. Data security is about technical protective measures to ensure the security of data (against viruses, manipulation, hackers, etc.). Data protection describes how personal data can be processed in order to protect it from misuse. 
Mobile health apps or medical apps usually store very sensitive data, e.g. your personal medical history. Of course, your neighbor should not know what illnesses you have or have had without your explicit consent – let alone a company. App manufacturers therefore need to think carefully about what data they want to store. When in doubt, less is more. In addition, the app must explicitly communicate which data is stored, where it is stored and what happens to this data. Companies that launch their product on the European market must therefore deal with the GDPR. Data protection under the GDPR is of course not an issue that only affects medical apps. Every app must be GDPR-compliant.
3. Data security
To ensure data security, you first need a very experienced technical team. They must have extensive know-how about where a software’s weak points could lie. You may make it onto the market with a medical app with inadequate data security, because even an auditor can only check this to a limited extent. However, the consequences of subsequent data leaks are drastic (as examples from Vivy & Co. show). Reckless actions can result in massive reputational damage and far-reaching legal difficulties. The particular challenge in this area is that data security does not allow for an 80 percent solution. While companies like to save costs when designing software, this can backfire when it comes to data security. If your app has even a single, easily exploitable vulnerability, hackers may find out about it. From this point on, all other security measures are irrelevant and the hacker gains access to the data.
If only one window is open in a locked house, a burglar can still easily break in.
4. Software quality
A scalable software architecture, structured code and automated tests (unit, integration and system tests) are important components for ensuring high software quality. For developers, poor software quality manifests itself in immense additional costs for software maintenance and the integration of new functions. App users usually notice a lack of software quality through malfunctions in the app, crashes, performance problems or a user interface that is difficult to use. Such defects are particularly fatal in medical apps: While a crash of the Facebook app, for example, is “only” annoying for users at first, the crash or misbehavior of a medical app can have dangerous or even life-threatening consequences. The reliability of the software must therefore be ensured. The influence of software quality is often underestimated, partly because it is difficult to evaluate as an outsider. You often only see the result when it is already too late. We therefore recommend that you consult your most experienced software developer/technician when selecting new applicants and external service providers. By asking specific technical questions, he can usually quickly get a feel for the other person’s expertise.
5. Communication with medical devices wearables
Medical apps are often used to control and monitor medical devices, such as glucose meters. Communication usually takes place via Bluetooth, Wi-Fi or USB. The following points, among others, must be taken into account. First of all, you need to understand the communication protocol of the device. An incorrect command can cause a medical device to perform incorrect actions or even crash. You need to know exactly which commands the device expects and in what form, and how your app should interpret the device’s data. This is often not so easy due to inadequate interface documentation. There are many different standards and many devices use a non-standardized, proprietary communication protocol. You should therefore clarify any documentation gaps in direct communication with the manufacturer of the communication protocol. Extensive testing is of course essential here too. You can also find more information on what is important for the interoperability of medical devices and apps in this article. If you are planning the development of a digital health application (DiGA), you will find specific support in the implementation of the interoperability requirements in this article . In addition, you must expect connection interruptions at any time. A Bluetooth connection can suddenly break off for many reasons. Your software must be able to handle this confidently and restore the connection automatically. Finally, you should ensure that transmission security is guaranteed, e.g. by encrypting data and verifying the identity of the sender and recipient. Otherwise, another device can simply read or even manipulate your transmitted data.
6. Different hardware and runtime environments
So-called “embedded software” only runs on a single device. The integrated software of a glucose meter is a good example of this. The framework conditions are therefore static and known in advance. However, this is not the case with medical apps. An app must work on a variety of different smartphones. The following things vary for each smartphone
- Hardware: screen resolution, camera, sensors, etc.
- Operating system and operating system version
- Other apps that influence the functionality of your own app (e.g. battery manager)
This is a major problem with Android in particular: there are an extremely large number of different devices. It is therefore impossible to test the app on all devices on which it will potentially run. 
How do you deal with such heterogeneous environments? To summarize, the following is important:
- Disciplined testing: Your software testers should test the app on every possible operating system version and on as many different hardware configurations as possible (for example, a low-cost smartphone with a slow CPU and small screen, and a high-end smartphone with a 4K screen and cutting-edge CPU).
- Training of the software team: developers must be careful not to make assumptions based on the hardware or operating system version of the phone.
- Automated testing: Manual tests can often take several weeks if they are to be carried out on many different devices. With automated tests, on the other hand, you can test your app on 50 different devices within a short period of time, for example.
- Use of cloud services to test the app: Services such as Amazon Device Farm make it easy to run the app and the associated tests on 50 different devices. Functionality based on sensors or Bluetooth, for example, cannot be tested in this way.
Conclusion
Developing a medical app poses many challenges. However, with an interdisciplinary team of experienced software developers, regulatory experts, testers and medical professionals, this is entirely feasible. In addition, the new Digital Supply Act (DVG) will make it more attractive to develop such an app: Remuneration will be simplified and price negotiations accelerated. Every hurdle is also always an advantage: if you overcome these challenges, you will have very little competition. Unfortunately, most start-ups don’t make it that far. You should therefore see this as an opportunity to secure a long-term place in the health market. We are happy to support you on this path. QuickBird Medical has already implemented numerous health and medical apps. Together with our customers, we developed and successfully placed these on the market. Our apps are not only secure and reliable, but also pass the audit of the notified bodies. Please contact us for a free initial consultation.
