Last week, we talked in-depth about what a mobile medical application is and why it is important to develop these projects in line with FDA regulations. Today, we’re focusing on the other side of the spectrum: what is not a mobile medical application and why these apps are exempt from FDA oversight.
If you’re developing a mobile app for patient or clinician use, understanding what is not a mobile medical application is just as critical as knowing what qualifies as one. Apps that do not aid in the treatment, diagnosis, prevention, or monitoring of a health condition generally fall outside the FDA’s definition of an MMA. This can be good news for you, as it often means fewer regulatory hurdles and faster time to market.
Still, it’s important to determine where your app stands before development begins. Discovering too late that your project requires full FDA compliance can cost both time and money. In this article, we’ll walk through what MMAs are, what they are not, and explore the gray areas in between so you can better understand where your software fits.
Quick Overview: What Is an MMA?
A mobile medical application (MMA) is any phone or tablet app that aids or supports in the diagnosis, treatment, prevention, and/or monitoring of an ailment or disease. These devices can be standalone software or software that communicates with an accessory that connects to a mobile device.
These kinds of software applications are considered medical devices and fall under the same regulations as more traditional medical hardware. To go to market, these applications must meet specific FDA regulations.
Some examples of regulated mobile medical devices from the world of diabetes include:
- Direct-connect smartphone CGM and pump apps.
- Blood glucose meter apps that include dosing information and CGM calibration.
- Meal planning apps that also calculate insulin dosing.
- Apps that alert the user or other connected users to high or low blood sugars.
- CGM apps that store and interpret CGM data and provide dose adjustment recommendations.
For more in-depth information on FDA-regulated MMAs, read our previous article on mobile medical apps and how they are regulated.
What is Not a Mobile Medical Application
There are many different types of mobile applications that are used by healthcare professionals and patients that do not diagnose, monitor, prevent, or treat diseases or ailments. These apps may aid in communication, help patients and doctors share information, or guide patients or doctors through routine or standardized practices. These applications can be highly specific to a certain disease or use, but as long as they do not give customized treatment or diagnosis information, or connect to a device that directly monitors health conditions, they fall into the definition of what is not a mobile medical application.
Because they are not MMAs, they are not regulated by the FDA. Knowing what is not a mobile medical application is just as important as understanding what qualifies as one, since it determines whether your software requires FDA oversight or not.
The FDA gives 18 specific descriptions of mobile software that is often used by the medical community but falls outside medical device regulation. Of these, 10 examples are pertinent to potential and existing diabetes-related software.
1. Software functions that are intended to provide access to electronic “copies” of medical textbooks or other reference materials with generic text search capabilities.
Diabetes-related apps covered under this definition include those that provide access to pump and CGM device manuals, insulin and medication reference material, dictionaries of diabetes-related terms, and/or general textbook and diabetes education information.
2. Software functions that are intended for health care professionals to use as educational tools for medical training or to reinforce training previously received.
Specific to diabetes, this category would include training apps for new pump and CGM users that healthcare professionals can reference during live and online patient trainings. This could also include refresher information to reinforce training for diabetes diagnosis and treatment.
3. Software functions that are intended for general patient education and facilitate patient access to commonly used reference information.
This category has many potential applications in the diabetes community. The takeaway here is that the app must be used to educate, empower, or increase patient awareness to support patient-centered healthcare. It should not be used to diagnose, cure, mitigate, treat, or prevent disease by aiding clinical decision-making. Examples include apps that act as a reference for carbohydrate amounts in different foods, illustrate body maps for injecting insulin or placing pump sites, and connect patients to applicable clinical trials.
4. Software functions that are intended for individuals to log, record, track, evaluate, or make decisions or behavioral suggestions related to developing or maintaining general fitness, health, or wellness.
These apps differ from mobile medical devices in that they track, monitor, or allow the recording of non-ailment-specific metrics. Examples include meal-tracking apps, fitness monitors, calorie-burning algorithms, and apps that provide motivational tips or social connectivity to encourage better health.
5. Software functions that allow a user to record (that is, collect and log) or upload data.
The key here is that these apps do not alter the data beyond changing formats and do not actively interpret the results to provide treatment recommendations, diagnosis, or other care advice. Examples include applications used to transfer data from CGMs, pumps, meal trackers, or mobile blood glucose logs to healthcare providers or caregivers.
6. Software functions that provide health care professionals easy access to information related to patients’ health conditions or treatments, and enable the health care professional to independently review the basis of the information provided by the software function.
This category speaks specifically to apps that allow healthcare providers to match their patients’ diagnoses, treatments, etc. to published archives and practical guides to help guide medical decisions. Importantly, the results provided must allow the doctor to independently review the information and form their own treatment plan or diagnosis. An example would be an archive of completed diabetes-related clinical trials with an advanced search function to match trial criteria to a specific patient’s treatment needs.
7. Software functions that provide patients with simple tools to organize and record their health information.
These apps must only allow for the recording of information without supplying data analysis or care recommendations. An example would be an app that a person living with diabetes could use to log their medication, meals, exercise, mood, and blood sugars.
8. Software functions that meet the definition of Non-Device-MDDS.
The FDA defines non-device-MDDS as software functions that are solely intended to transfer, store, convert formats, or display medical device data and results. These devices do not analyze or interpret the data. Applications meant to transfer CGM, pump, blood glucose meter, or smart pen data to doctors or caregivers without interpreting that data or providing treatment recommendations would fall into the category of non-device-MDDS.
9. Software functions that display patient-specific medical device data.
This category speaks specifically to image-based data, which would include raw graphs generated by CGMs.
10. Software functions that are intended for transferring, storing, converting formats, or displaying.
The movement of data from these apps must be achieved without modification. The application must also not control or alter the functions or parameters of any connected medical devices. Examples include secondary CGM applications that show CGM readings and convert them to useful graphs and charts without offering medical advice or interpreting the data beyond tags attached by the CGM, and without direct control over the device.
FDA Regulation Enforcement Discretion
Between regulated MMAs and applications not considered MMAs is a gray area. The devices that fall into this category are considered mobile medical applications but are not regulated as medical devices. The FDA chooses to exercise enforcement discretion with these types of applications. Because of this, manufacturers are not required to submit premarket review applications.
The FDA gives many examples of mobile apps that fall into this category, including apps that:
- Provide reminders to calibrate, take medication, or log information.
- Provide information on drug-herb interactions based on data input by the user.
- Provide patient-specific preventative recommendations based on characteristics input by the user.
- Create and provide historical trending and comparisons of blood sugar levels.
- Provide prediabetic patients with guidance on exercise and diet to help prevent disease escalation.
As you can see, many apps in this category verge on treatment, prevention, or monitoring of medical conditions, but do so in a way that poses minimal risk to the user. Proving your application is low risk is a necessity to achieving regulatory enforcement discretion for any mobile app that toes the line between MMA and what is not a mobile medical application.
How to Determine Where Your App Stands
Mobile applications that fall under the definition of what is not a mobile medical application require much less oversight to develop and bring to market. But only if the FDA agrees with your determination of the app’s standing. Developing an app out of line with FDA regulations only to discover too late that you need to submit a premarket review application can be a costly and time-consuming mistake.
Before you begin your project, it is worth reaching out to the FDA to gain a clear understanding of what is not a mobile medical application and how your app would be categorized. If you receive a designation as an MMA, it is worth partnering with a software development company like Sequenex that can help you navigate the process of FDA approval and streamline your SaMD development.
In addition to FDA regulations, we have a vast knowledge of global med tech guidelines and decades of experience designing and building medical software in line with ISO 13485. We’ll help you turn your diabetes software idea into a successful MMA. Contact us today!
