Mobile medical apps

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.

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).

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:

• Quality Management System
• Risk Management System
• Usability
• Software Life-Cycle Processes
• IT Security and Data Protection

b) Specific requirements for mobile applications

Europe

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.

USA

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.

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?

Classification

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.