Mobile Medical Apps
Medical Apps also referred to as Mobile Medical Apps, are applications for mobile devices such as smartphones or tablets that support medical professionals or patients in the diagnosis, treatment, or monitoring of a disease or injury.
This article describes when medical apps are subject to the legal requirements for medical devices and how manufacturers can meet these regulatory requirements.
When Medical Apps Turn into Medical Devices
Definitions: Medical device
„(1) ‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
- diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
- diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
- the investigation, replacement, or modification of the anatomy or of a physiological or pathological process or state,
- providing information by means of in vitro examination of specimens derived from the human body, including organ, blood, and tissue donations,
and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means.“
Medical Device Regulation
Mobile Applications are, according to FDA software, applications that run on mobile platforms such as commercial “handhelds”, whereby it is immaterial whether they work via a wireless connection (WiFi or 3G) or not. Even web applications that are designed specifically for mobile devices fall within the definition of “Mobile Application”.
Mobile Medical Applications are now those that additionally satisfy the definition of Medical Devices. This is where the challenge of distinguishing between Medical Devices and Non-Medical Devices begins. Very helpful for this differentiation, are the examples that the FDA gives:
Examples of apps that are classified as medical devices
- Apps that are an accessory or an extension of a medical device. Examples are apps that directly control (for example, starting a blood pressure measurement) or apps that remotely display the values of medical devices.
- Apps that perform support for individual patients such as drug dose calculations or detection of drug interactions, or contraindications.
- Software for analysis or processing of radiological images (with a diagnostic purpose).
Medical Apps in the gray area
The FDA gives examples of mobile apps that fall within the gray area and can be valued separately:
- Apps that support the patient in coping with their daily lives as a patient. For example, ensuring the regular use of medication.
- Apps that let patients document their values and check things such as blood pressure, pain, or other routine activities.
- Apps that give the patient available and specific information for their disease.
- Apps with which patients can communicate with their doctors.
- Apps that allow access to clinical information systems.
- Apps that perform simple calculations such as a BMI.
Apps that are not medical devices
Finally, the FDA gives examples of Mobile (Health) Applications that are not medical devices, i.e. not to be classified as a Mobile Medical Application:
- Apps complying with an electronic copy of a book or reference work.
- Apps that are used as a training example by clinical staff or patients.
- Apps that serve the payroll.
- Apps that have not been specifically designed for the medical field. For example, a digital magnifier.
Interestingly, there are Medical Apps for which the FDA does not enforce compliance with the regulations.
Support in Authorization
Need assistance to get approval respectively CE-mark for your Medical App?
Regulatory Requirements (EU and FDA) for Medical Apps
Regulatory requirements of the FDA
Once a mobile application is classified as a medical device, the relevant requirements of the FDA must be considered.
- the Quality System Regulations (21 CFR Part 820)
- the Guidance Document “Software Validation”
- the Guidance Document “Contents of Premarket Submissions for Software Contained in Medical Devices”
- the Guidance Documents “Cybersecurity”
How extensive the demands of the Quality System Regulations must be met, mainly depends on the risk from the respective app. The FDA distinguishes different classes which are not to be confused with the level of concern.
The FDA does not enforce all Mobile Medical Apps compliance with the legal requirements. This discretion also applies to medical apps that are classified as Medical Device Data Systems.
Regulatory requirements for the CE marking
The classification of Medical Apps of medical devices and non-medical devices, such as that made by the FDA, can be transferred substantially and directly to the definition of the term in Europe according to Medical Device Directive (MDD) respectively Medical Device Regulation MDR. However, the documentation requirements differ.
The technical documentation must include:
- a risk management file in conformity with the requirements of ISO 14971
- a usability file in conformity with the requirements of IEC 62366 and
- a “software file” in conformity with the requirements of standard IEC 62304
Unlike the FDA, the scope of the created (not submitted!) “Software file” depends on the software safety class. This safety class roughly corresponds to the FDA’s Level of Concern.
In Europe, manufacturers who ‘just’ develop medical apps for commercial devices (tablets and smartphones), but don’t develop specific hardware for them, don’t have to prove compliance with IEC 60601-1, the standard for electromagnetic compatibility or electrical safety. An extension of the terminal, for example, the above instrument for blood glucose monitoring strips, negates this simplification.
Development and Approval of Medical Apps: Challenges
The interpretation of auditors and authorities is that Mobile Medical Apps must be treated as any other medical device. While this is correct, in practice there are many challenges that the manufacturers of these “medical apps” should be aware of in order to successfully pass the “certification” of their apps.
Failing to cope with these challenges may cause:
- problems with the “Certification”
- unnecessary risks for patients
- the trouble with the authorities and
- delayed and more expensive development projects.
1. Challenge: diversity of platforms for Medical Apps
Whereas classical medical device manufacturers develop their embedded software for one runtime environment (for example, hardware, operating system), app developers need to support a variety of platforms. This diversity concerns:
- The hardware: The form factors, screen sizes, and screen resolutions. We have already encountered fatal problems because UI elements on small screens were not (properly) displayed.
- The operating systems: Especially with Android, the number of versions can hardly be overlooked.
- Other Software: The Medical app shares the platform with other apps that can be faulty or exchange components during installation. This can be difficult to predict.
2. Challenge: a variety of users and user environments
For an HF surgical device, it is relatively easy to specify the users and use environments. In Medical Apps, which are often offered without restrictions to a group of users, the same task can be particularly challenging for risk management:
- Variety of user groups: Different languages and cultures, intellectual and physical abilities, and the different mental models of users give difficulties when predicting the impact on the user behavior and thus on risks.
- The use environment is often unknown. Do the users use the medical app in the office or while driving a car? In lightness or darkness? With or without gloves in the operating room?
- As the user base is difficult to limit, it can be difficult to keep track of who is using the product. Do many Medical Apps, therefore, need a “Kill Switch”?
- Internationalization leads to further challenges, which app developers have to deal with.
The Apps must be able to deal with:
- different languages (of the operating system)
- number formats (for example, the decimal point)
- time zones (according to which time zone are the calculations, the client’s or the server’s?),
- character sets (encodings).
3. Challenge: technological challenges of medical apps
Mobile Medical Apps mostly use server functionality. Thus, they are dependent on secure client-server communication. Security here is CIA:
- Confidentiality (more on that soon)
Furthermore, it’s usually in the App-environment, to release several versions per quarter, sometimes per month. The development cycles, just like the technology cycles, are becoming shorter. This entails the following potential problems:
- The agile approach does not take place in conformity with the regulations such as IEC 62304. One meets Adhoc design choices, does not stick to the development plan, and is sloppy in the verification and validation.
- In particular, the manufacturer fails to repeat the usability validation when changes are made
- The product and associated documentation diverge.
- The manufacturer does not accompany the rapid changes by adequate risk management.
- The SOUPs, which are highly available with apps are not sufficiently described and analyzed.
- The process of conformity assessment and the involvement of notified bodies can’t keep up with this pace.
4: Challenge: regulations, laws, and more
Definition of the product: Many app makers, especially if they develop a server part, are not even able to tell what is now part of the medical device. Is the server hardware part of it? The operating system of the server? The web/application server? The database? The PHP runtime environment? This ambiguity also stems from the fact that there is often only one instance of the device (at least on the server part) of the product. Sometimes millions of copies of “Normal” medical devices are sold. In this case, it is clear what is part of it and what isn’t.
Medical apps deal with medical data. To comply with the relevant data protection rules in a country is already challenging. The challenge now is to meet the data protection laws of many countries. It must also be clarified which laws apply where in the country: The country where the user is located? The country in which the server is? The country, which the patient comes from?
Classification: In Europe, it is noteworthy that many apps fall into Class I. Even very critical apps, for example, those for the calculation of cytostatics. However, the MDR will change the classification.
The manufacturer is also operator: Once the manufacturer operates the server (or can operate) they must also refer to the statutory provisions, that are meant for the operator. The key points here are the MPBetreibV or IEC 80001.
Lack of experience: There is hardly any product category in which there are as many new “players” who have little idea about the medical device law, as in the Medical Apps: agencies, marketing departments, startups. But ignorance is no excuse.
Trends with Mobile Medical Apps
Growing importance and distribution
In recent years, manufacturers of Medical Apps, called Mobile Medical Applications by the FDA, brought in an almost explosively growing number of medical apps into the market. Stores like Apple’s AppStore or Google Play are full of applications for tablets and smartphones.
You can condemn or love Medical Apps. Either way, these apps are on the rise. Whether these are to be used already to replace classical medical devices, can be reasonably discussed. A doctor who uses his iPhone as a substitute for an EKG, I probably would not visit a second time. But it is supposed to happen, as Gizmodo reports.
Some manufacturers go a step further. In total Star Trek-style, there is now a little scanner that is carried over the patient and then gives information about the status of their health.
The proportion of these mobile apps, which demonstrably meet the regulatory requirements (particularly the FDA and the European legislator) is negligible. Medical device manufacturers failed to operational risk management in order to develop the software in accordance with a lifecycle model and to document and demonstrate the suitability for use of their products. However, the authorities are taking the producers of mobile apps increasingly more into focus.
With the speed with which web technologies develop, the developers of mobile apps must keep up because they share in the technologies of these Apps is also growing. Contributing to this are not just the cross-platform development tools like Apache Cordoba, but also the standardization of technologies within the platform-specific tools.
Support for the Development and Authorization of Medical Apps
- in creating an “audit-secure” technical documentation for your app in a very short time, for example
- to formulate the purpose
- to document the software in compliance with standards
- the risk management file
- to create the usability file
- to reach a condensed QM system, with which you can bring your own Medical Apps into the market
- to determine the classification for your medical app
- to perform clinical evaluation and documentation
- answer your questions quickly and competently (and often for free)