Mobile medical apps, also known as medical apps, are applications for mobile devices such as smartphones or tablets that support medical staff or patients in the diagnosis, treatment, or monitoring of illnesses or injuries.


This page provides a quick overview of medical apps and links to further articles for a more in-depth understanding.

  1. Mobile medical apps as medical devices or accessories
  2. Regulatory requirements for mobile medical apps
  3. Special challenges
  4. Support for manufacturers of medical apps

1. Medical apps as medical devices or accessories

a) General

Qualification and definition of “medical devices”

Whether medical apps count as medical devices depends on the laws in the respective markets.

  • In Europe, the definition of medical device in Article 2 of the MDR, respectively IVDR, applies. The MDCG Guideline 2019-11 must also be observed.
  • The “Food, Drug & Cosmetics Act” defines what constitutes a medical device in the USA. It excludes many software applications. The FDA has published a guidance document on medical apps that explains this law (see below).
Further information

Further assistance can be found in the articles on the qualification and classification of medical devices and standalone software and the article on the qualification and classification of IVD software.

Definition “Mobile“

The EU does not define when a medical device is “mobile”, respectively, “portable.” Only IEC 60601-1 (more on this later) recognizes “portable” medical devices.

According to the FDA, “mobile applications” are software applications that run on mobile platforms such as commercial “handhelds,” regardless of whether they have a wireless connection (WLAN or 5G) or not. Web applications designed explicitly for mobile devices also fall under the definition of “mobile application.”

b) Examples

Medical apps that qualify as medical devices

In both the EU and the USA, these are considered medical devices:

  • Apps that perform calculations or analysis for individual patients, such as software for analyzing laboratory data
  • Apps that calculate drug doses or identify interactions
  • Apps that are used to diagnose radiological images

In Germany, all digital health applications (digitale Gesundheitsanwendungen – DiGA) are medical devices by definition.

Medical apps in the gray area

The FDA gives examples of mobile apps that fall into the gray area and must be evaluated individually:

  • Apps that help patients manage their daily lives as patients, such as ensuring they take their medications regularly
  • Apps that patients use to document and track their values, such as blood pressure, pain, or other routine activities
  • Apps that provide patients with information specific to their disease
  • Apps that patients can use to communicate with their doctors

In Europe, apps that only transmit, display, or store data do not count as medical devices according to MDCG 2019-11.

Medical apps that are not medical devices

Some apps do not qualify as medical devices in the USA and Europe:

  • Apps that are equivalent to an electronic copy of a book or reference work
  • Apps that are used for training purposes, e.g., for clinical staff or patients
  • Apps that are used for billing purposes (only)
  • Apps that have not been developed specifically for the medical field, e.g., a digital magnifying glass

Apps that are accessories

By definition, accessories are not medical devices. However, the same regulatory requirements apply. Examples of medical apps that can be considered accessories are:

  • Remote control for an X-ray table
  • Service tool, e.g., for diagnosing or calibrating a medical device
  • Apps that display the measured values of a medical device
  • Apps that belong to an extension of the platform or control it; for example, a blood glucose measuring unit that can be docked onto a cell phone to start it or to read out, calculate, and display values

2. Regulatory requirements for medical apps

a) Requirements that apply to all medical devices and SaMDs

Mobile medical apps that are medical devices must meet the same regulatory requirements as all other medical devices. These are in particular:

Further information

The article on the MDR requirements for software provides an overview of the relevant standards and laws.

IEC 82304-1 applies to all “health software”.

The article on the FDA lists relevant guidance documents.

Please also note the FTC’s requirements and its “interactive tool,” which helps to identify all regulatory requirements.

b) Specific requirements for mobile applications


The MDR only addresses mobile applications in Annex I:

Software referred to in this Section that is intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise).

MDR, Annex I, Section 17.3

Accessibility requirements apply not only to mobile apps but also to all DiGAs, for example.


The FDA has published a guidance document specifically for mobile medical apps. One special feature is the concept of “enforcement discretion.” Here, the authority gives itself the freedom to decide on a case-by-case basis whether to enforce the regulatory requirements for medical devices.

In addition to the FDA’s requirements, manufacturers should consider the FTC’s requirements with the Health Breach Notification Rule and HIPAA, even if these are not specific to medical apps.

IEC 60601-1

In Europe, manufacturers who “only” develop medical apps for commercially available end devices (tablets and smartphones), but no specific hardware for them, do not have to provide proof of electromagnetic compatibility and electrical safety. The associated standard IEC 60601-1 is not applicable.

However, an extension of the end device, such as a physical attachment for a smartphone to evaluate blood glucose monitoring strips, would invalidate this simplification.

IEC60601-1 und Mobile Medical-Apps

3. Particular challenges for manufacturers

Challenge 1: Diversity of platforms for medical apps

While traditional medical device manufacturers develop embedded software for exactly one runtime environment (e.g., hardware, operating system), app developers have to support a variety of platforms. This diversity affects:

  • Hardware, especially form factors, screen sizes, and screen resolutions. We have already encountered fatal problems because UI elements were not displayed (correctly) on small screens.
  • The operating systems: Especially with Android, the zoo of versions is hard to keep track of.
  • Runtime“: For medical apps, this primarily includes the browser with its JavaScript engines, the Java Runtime, or the .NET runtime environment. Anyone who believes that websites with identical HTML, CSS, and JavaScript code are displayed in the same way in different browsers and on different platforms has never done any serious web development.
  • Other software: Medical apps share the platform with other apps, which may be faulty or exchange components during installation. This is almost impossible to predict.

Challenge 2: Diversity of users and use environments

For an electrosurgical device, specifying the users and use environments is comparatively easy. For medical apps, which are often offered without restrictions to a user group, this task can become a challenge, especially in risk management:

  • Different languages and cultural backgrounds, intellectual and physical capabilities, and the different mental models of users have a difficult-to-predict impact on usage behavior and, thus, on risks.
  • The environmental conditions are often unknown. Do users benefit from the medical device app in the office or while driving? In brightness or darkness? With or without (surgical) gloves?
  • International distribution leads to further challenges that app developers have to face: The apps must be able to deal with different languages (of the operating system), number formats (e.g., decimal separators), currencies, character sets (encoding), and time zones (which time should be used to perform calculations, that of the client or that of the server?).

Challenge 3: Technologies and development

IT security

Mobile medical apps usually use server functionalities. However, this makes them dependent on safe client-server communication.

Iterative development, short development cycles

In the app environment, publishing several releases per quarter, sometimes monthly, is common. Development cycles are becoming shorter and shorter, as are technology cycles. This harbors potential problems:

  • The agile approach does not conform to regulations such as IEC 62304, if ad hoc design decisions are made, if the design and development planning is not adhered to, and if verification and validation are sloppy.
  • In particular, the manufacturer fails to repeat the usability validation when changes are made.
  • The device and the associated documentation diverge.
  • The manufacturer does not accompany the rapid changes with adequate risk management.
  • The SOUPs, which exist in particularly high numbers for apps, are not sufficiently described and examined.
  • The conformity assessment process and the involvement of notified bodies cannot keep up with this speed.

Challenge 4: Regulations, laws, and more

Delimitation of the device

Many app manufacturers, especially when developing a server part, cannot name what is part of the medical device. Is the server hardware part of it? The virtualization layer? The operating system of the server? The web/application server? The database? The PHP runtime environment?

This lack of clarity also stems from the fact that there is often only one instance of the device (at least the server part). “Normal” medical devices, on the other hand, are frequently sold by the millions. Here, it is clear what is included and what is not.

Data protection requirements

Medical apps handle medical data. Complying with the relevant data protection regulations is challenging, especially when many countries are involved. Which laws apply in which country must also be clarified: The country where the user is located? The country in which the server is located? The country from which the patient originates?


In Europe, almost no apps fall into class I due to Rule 11 of the MDR. This means that a notified body must be involved even for non-critical apps. This significantly delays the placement of these devices on the market.

Manufacturer is also operator

As soon as the manufacturer also operates the server (or has it operated), he must comply with the legal regulations that apply to operators. Key points here are the MPBetreibV or IEC 80001.

Lack of experience

There is hardly any other product class in which there are so many new “players” who have little idea about medical device law, as in the case of medical apps: agencies, marketing departments, and medical start-ups. But ignorance is no defense against punishment.

4. Support for manufacturers of medical apps

a) Support through free offers

The starter kit provides you with a quick overview of the regulatory requirements.

If you still have questions about mobile medical apps, you will receive answers in our micro-consulting free of charge.

b) Support through education

The seminars provide you with an easy introduction. For manufacturers of medical apps, we particularly recommend the

The Medical Device University is an e-learning platform that explains all the necessary work and documents step-by-step in videos and contains ready-made templates for a complete product file and a complete QM system.

c) Further support

Our qualified experts will help you with all activities:

If you don’t have the time or money to set up your QM system, you can also commission the Johner Institute as a legal manufacturer.

Contact us immediately so we can determine the next steps together to develop your app in compliance with the law and bring it to market as quickly as possible.

Verification and validation: Differences and definitions

What is the difference between verification and validation, and how are these terms defined? Even standards and regulations use the terms incorrectly or misleadingly. This article 1. Verification a) Definition This definition does not explain what type of “requirements” need to be confirmed by verification. Limiting these requirements to product or component requirements is recommended to avoid…


7 steps to the DiGA directory

Since 2020, the German legislature has allowed the reimbursement of digital health applications (DiGA). DiGA manufacturers must fulfill several requirements for this. This article describes the steps required to do so. Step 1: Define the business case a) Determine the intended purpose of the DiGA The intended purpose is the basis for all further steps.…


MDR Classification Rule 11: The classification nightmare?

The MDR contains the Classification Rule 11. This rule is especially for software. The Rule 11 has serious implications: it bears the potential to further undermine Europe’s innovation capacity. Manufacturers should familiarize themselves with the MDCG’s interpretation to avoid misclassifying software and to be able to follow the reasoning of notified bodies and authorities. This article…


Electronic instructions for use for medical devices (EU law)

EU Regulation 2017/745 (MDR) establishes the general requirements for instructions for use (IFU). Whether they can also be provided in electronic form (eIFU) is regulated by Implementing Regulation (EU) 2021/2226.  We have summarized the requirements for electronic instructions for use for you. 1. Requirements for the use of electronic instructions for use According to Implementing Regulation (EU) 2021/2226,…