FDA Public Meeting on Mobile Medical Apps and Stand-Alone Clinical Decision Support Software

By Carmelina G. Allis - 

Below is a summary of some of the key issues discussed during FDA’s September 12 and 13, 2011, public meeting on the recently issued draft guidance document for mobile med apps.  During the meeting, FDA also requested input on how to regulate stand-alone software that provides clinical decision support, even though those support systems are not specifically addressed in the draft guidance.

In general, FDA received positive feedback regarding the draft guidance document on mobile apps.  However, it is clear that the agency still has some work to do, in particular, it needs to define the regulatory landscape in the area of stand-alone clinical decision support software.  There are some unanswered questions in both areas, as you will see from the discussion below:

Mobile Medical Apps

• There were three main proposals regarding mobile medical apps: (1) FDA should classify apps based on the level of risk to patient health; (2) FDA should issue guidance to explain what kinds of apps and/or claims the agency will not regulate; and (3) there should be a way to ensure that apps do not adversely affect the main device they connect to (and vice versa), such as requiring good software practices.

• Because many app “manufacturers” are not FDA-regulated entities, the draft guidance document needs clarity and information in order to help those that are having to learn the regulatory landscape.  The discussion on mobile medical apps centered around what does “intended use” mean and how to apply it.  A simple roadmap that helps entities/individuals to determine “how do I know that I am a mobile med app manufacturer” was suggested.

• The discussion on mobile med apps as “accessories” centered around proposals that FDA classify accessories based on intended use and functionality rather than specific characteristics or technology.

• There was some discussion that the draft guidance goes too far – for example, could general-purpose websites that have dosage calculators fall within the definition of a mobile medical app if that website (and, thus, the dosage calculator) can be accessed via a mobile phone?

• Another issue discussed was that of “interoperability” – there are apps that get information from many different sources/devices, and then an action is triggered.  How does FDA intend to regulate those apps?  Some suggested a risk-based approach.  However, the problem with the risk-based approach is how to define it: the risk if something goes wrong with the app vs. the risk that the use of the app poses?  FDA’s Bakul Patel noted that the agency discusses those issues internally all the time, but that at the end of the day, the issue is about patient safety.  Another issue regarding interoperatibility relates to who has the regulatory burden to ensure safety and effectiveness.  Is it the app manufacturer only?  But how do you ensure that the hardware (e.g., the iPad or Android platform, which FDA has said will not regulate) is safe for a particular app?

• It was suggested that FDA not discourage people from being able to make claims about the platform because of fear of becoming a medical device.  This issue came up because of comments regarding the Ford car that will supposedly provide access to apps specifically targeted to diabetics.  Does the car become an accessory to the app?  Does it all depend on the claims made by Ford?  Or could FDA allow certain claims and not regulate the car?

Stand-Alone Clinical Decision Support Systems

• FDA said that the factors it generally considers on how to regulate stand-alone clinical decision support systems involve: (1) the level of impact on subject health/condition; (2) the degree of acceptance in the clinical practice; and (3) the ability to identify erroneous output (due to incorrect output or clinically wrong information).

• There appears to be a strong concensus among some that national/international standards should be imposed/required to ensure that clinical decision support systems adhere to good software practices.

• Others suggested that regulatory requirements for clinical decision support systems should be based on intended use and risk.  Two general types of support software systems were outlined: (1) those that provide generic decision support, such as providing summaries of clinical articles or anecdotes, which FDA has said it does not intend to regulate, and (2) those that provide patient-specific support.  Among the latter, three main types were discussed:

– systems that provide or assist with simple functions;
– systems that provide assistance with therapeutics; and
– systems that assist with diagnoses.

No particular regulatory approach was proposed, as the landscape of clinical decision support systems varies immensely on intended use, intended population, functionality, and technological characteristics.  For example, while some clinical decision support systems are based on simple rules, like medication reminder software, others are based on more complex algorithms, such as assisting medical practitioners with diagnoses assessments or computing chemotherapy doses.  One possible approach not publicly discussed at the meeting would be for FDA to create a classification regulation requiring 510(k)s with special controls that applies to a well defined, but broad group of stand-alone clinical decision software (e.g., a classification regulation for software intended to assist medical practitioners with therapy determinations).

At this time it is difficult to advocate a particular regulatory pathway to clients for these device types, because there are no classification regulations that apply to many of these stand-alone clinical decision systems.  In addition, FDA has not defined what system types it intends and does not intend to regulate.  And because the 510(k)/de novo pathway is unpredictable and inefficient, manufacturers are unwilling to pursue any specific pathway to market until FDA further defines the regulatory landscape.  FDA does not want to be inundated with de novos or PMAs (which would be the default for lack of a predicate device), both of which are time-consuming and resource-intensive regulatory processes.  And that is why the suggested approach of creating a regulation with special controls for a defined, but general-scope stand-alone clinical decision support system looks appealing.