How to Get FDA to Clear a Mobile Health App, as appeared in MobiHealthNewsDecember 1, 2009
(I would like to thank John Murray of FDA, Scott Thiel of Roche Diagnostics and Russ Gray of the Anson Group for their comments on a draft. The views expressed — right or wrong — are only the author's and should not be attributed to the commenters.)
Most people in the wireless health industry have heard by now that FDA has started to clear applications for cell phones with medical indications. A widely-reported example is AirStrip OB, cleared to deliver patient waveform data — including fetal heartbeat and maternal contraction patterns — in virtual real-time directly from the hospital labor and delivery unit to a doctor's mobile wireless device, specifically to an iPhone or a Blackberry. Other software developers are probably interested to learn when FDA clearance is required, and what it takes to accomplish that FDA clearance. In this article, I'll address both of those questions at a high-level.
This article is part of a series, and in the first article I outlined the factors FDA considers generally when deciding which products need to be regulated and which fall outside of the scope of a medical device regulation. In the second article, I outlined the basic steps for getting a medical device cleared by FDA. This article will focus on the unique aspects of those two questions in the context of mobile device apps.
From those two prior articles, it's important to remember that medical devices, including software, can be divided into three categories: (1) standalone devices, (2) accessories and (3) components. Standalone are those devices that are intended to directly provide the diagnostic or treatment, while accessories are sold directly to end-users and work with standalone devices. Components, in contrast, are purchased by manufacturers of standalone or accessory devices for incorporation before sale. Mobile device (e.g. cell phone apps) can be an accessory, as opposed to a component, if they are sold or even given directly to the end-user: the patient. They can also be standalone if they do not connect physically or virtually to any device other than the mobile device platform.
Understanding that is important because determines the regulatory requirements that apply. If the app is designed, for example, to facilitate the downloading of information from a blood glucose meter, the app and maybe even the software environment are accessories and will be regulated in the same manner as the blood glucose meter. The classification and most of the requirements for the submission to FDA will be dictated by how the parent standalone device is regulated. So, the Airstrip OB app is regulated as part of a perinatal monitoring system generally, just as the sensors and other hardware that gather the information.
Some apps will not be simply enablers of transmitting data from a medical device, but will actually serve a standalone purpose. From the prior two articles, remember that it's the claims the software developer/seller choose to make, within reason, that triggers FDA regulation in the first place, and the degree of that regulation when it comes to obtaining clearance.
Once you properly figure out which of the three roles the software plays, you can figure out its regulatory status. Typically that's one of the following three choices:
Software that does NOT meet the legal definition of a device and is not regulated by FDA.
Software that does meet the legal definition of a device but is currently not actively regulated, and FDA is unlikely to require pre-market review.
Software that does meet the definition of a device and FDA is actively regulating and would require a pre-market review.
Except for a few specific exempt device types identified in the classification regulations, that middle category isn't today a regulatory classification you'll find defined in any FDA records. Fortunately or unfortunately, depending on your perspective, FDA has been very reluctant over the last dozen years to define with any real precision its policy on which types of software must undergo premarket review and clearance, or even approval. The agency has held open public meetings and floated concept papers, and more recently has proposed a limited device classification for medical device data systems, but by and large has not with any certainty clarified its policy on when software trips the premarket requirement.
So the following is just my personal observations about how FDA regulates software in practice, as I can glean from watching FDA enforcement actions, podium policy, and the informal statements FDA has made in concept papers.
In its explanation surrounding the agency's proposed classification of Medical Device Data Systems published in 2008, FDA explains:
It is FDA's long-standing practice to not regulate those manual office functions that are simply automated for the ease of the user (e.g., office automation)?... For example, the report writing functions of a computer system that allow for the manual (typewriter like) input of data by practitioners would not be?... [regulated] because these systems are not directly connected to a medical device. In addition, software that merely performs library functions, such as storing, indexing, and retrieving information not specific to an individual patient, is not considered to be a medical device. Examples include medical texts or the Physician's Desk Reference on CD-ROM that are indexed and cross-referenced for ease of use.
FDA goes on to say it won't regulate "software that allows a doctor to enter or store a patient's health history in a computer file." On its face, that description of unregulated software is somewhat narrowly written. That is not surprising since FDA always takes an expansive view of its jurisdiction, and is not likely to concede much ground in that regard.
Beyond that passage, I would add that there are two key features for most unregulated software.
The data are entered manually; they are not inputted directly from any machine that touches the patient or a patient specimen. That's important to avoid becoming an accessory to a medical device.
Depending on how inputted, the output amounts simply to providing the stored data back to the patient or professional. The system does not automatically guide the diagnosis, nor does it guide any other instrument. In other words the software does not contain any algorithms that provide clinical-like functions that go beyond what FDA often refers to as library functions. It merely displays the data for the user to read and interpret.
Many mobile device apps do indeed fit this category of unregulated software. But it is important to remember to conduct an honest evaluation of the intended use of your product. The evaluation should focus on the clinical intended use of the product and less on the technical characteristics of your software or your system. In FDA's eyes, your software product does not have to provide a complete cure, mitigation, treatment, or prevention of disease to meet the legal definition of a device. If your software is intended to provide any part of cure, mitigation, treatment, or prevention of disease, FDA will probably consider it a device. Understanding the limits on the unregulated category is probably best explained, though, by looking at the other two categories.
Regulated Software Exempt from Premarket Clearance
Since the late 1980s, FDA has been publicly declaring that there exists a category of software that technically qualifies as a medical device but for which FDA has no intention of requiring the submission of a premarket notification or approval application. For those who are really interested in this topic, it probably makes the most sense to start with the "FDA Policy for the Regulation of Computer Products, 11/13/89 Draft."
In that policy, there are two categories of software products that were technically regulated but also considered exempt from the major requirements: (1) general purpose articles as defined in a regulation and (2) software that involves competent human intervention. Unfortunately FDA never got around to actually codifying the competent human intervention exemption. In its classification process, FDA has adopted certain general purpose or low risk exemptions that cover software, such as laboratory information management systems (LIMS) (21 CFR 862.2100) used as calculators or data processing modules for clinical use.
About 7 years after FDA published the 1989 draft policy, it appeared FDA was moving toward formalizing its computer product policy. In addition to publicly announcing that intention, FDA hosted a large meeting in Washington and invited many stakeholders to discuss what the policy should be. In preparing for that meeting, FDA drafted a summary of what it considered to be its then existing policy on computer products. Those workshop materials explained that much of the software the agency was seeing constituted accessories to medical devices, and the competent human intervention concept was only intended to apply to truly standalone software. The agency also argued that the concept of what constitutes competent human intervention had become increasingly complex and difficult to administer. FDA observed:
In general, to permit competent human intervention, the software decision process must be completely clear to the user, with a reasonable opportunity for challenging the results. There must also be adequate time available for reflection on the results.
But again, FDA never followed through to adopt a new regulation or policy.
In early 2008, departing somewhat from the 1989 approach, FDA proposed a new category of software that would fit within this general category of regulated software exempt from premarket clearance. They proposed to call the new category medical device data systems (MDDS), and they defined it to include:
The electronic transfer or exchange of medical device data from a medical device, without altering the function or parameters of any connected devices. For example, this would include software that interrogates a ventilator every 15 minutes and transfers information about patient CO2 levels to a central patient data repository;
The electronic storage and retrieval of medical device data, without altering the function or parameters of connected devices. For example, this would include software that stores historical blood pressure information for later review by a healthcare provider;
The electronic display of medical device data, without altering the function or parameters of connected devices. For example, this would include software that displays the previously stored electrocardiogram for a particular patient;
The electronic conversion of medical device data from one format to another format in accordance with a preset specification. For example, this would include software that converts digital data generated by a pulse oximeter into a digital format that can be printed. Examples of medical device data systems that would be used in the home are systems that periodically collect data from glucose meters or blood pressure devices for later review by a healthcare provider.
This category is only available as an exemption from premarket clearance so long as the data set is intended for professional use and does not produce irreversible data compression.
Based on the following preamble from the proposed MDDS rule, I would suggest that through this process FDA is seriously rethinking its software policy.
Since 1989, the use of computer-based products and software-based products as medical devices has grown exponentially. In addition, device interconnectivity and complexity have grown in ways that could not have been predicted in 1989. This growth and expansion have created new considerations for elements of risk that did not previously exist. FDA realized that the Draft Software Policy was not adequate to address all of the issues related to the regulation of computer based and software-based medical devices. Based on this history and the complexity and diversity of computer software, FDA decided it would be impractical to prepare one ''software'' or ''computer'' policy that would be able to address all the issues related to the regulation of computer- and software based medical devices.
While FDA has proposed the MDDS category, as of this writing the agency has not adopted it in final form. During the interim, however, it seems to be the best guidance available for deciding whether a premarket clearance is required.
Dividing Line Between Software Requiring Premarket Notification And Not
In defining medical device data systems, FDA was merely trying to define one relatively narrow, cohesive type of data set that the agency would regulate but exempt from premarket notification. However, that is only one example, and it is not meant in any way to be the only example of software that would be treated as regulated but exempt. Indeed my understanding is that the agency plans to publish future proposals defining other regulated — exempt and nonexempt— categories.
But what are software companies supposed to do in the meantime? What else fits within this regulated but exempt category? The unfortunate answer is that this represents a huge gray area. The best anyone can do is look at a variety of risk factors to figure out which side of the premarket clearance line again a piece of software falls. Based on FDA comments and actions over the last 20 years, I would propose the following list of factors be considered.
Whether the software is intended or designed to provide any real time, active, or online patient monitoring functions.
The capability to display, create, or detect alarm conditions, or actually sound an alarm, or the capability to create alarms that are not already present from the connected medical devices.
The seriousness of the particular disease or condition which the medical software device is intended to diagnose, cure, mitigate, treat or prevent and how the software contributes to the user's decision-making for diagnosis or clinical management of the patient. Example: Is it software designed to call attention to imminent hazard conditions or is it software that provides long-term storage for diagnostic information?
The amount of time available before using the information provided by the medical software device, i.e., the time until a therapeutic or additional diagnostic intervention must be implemented by the health care provider after the results of the software have been provided. Example: Is the device an EKG reading and analysis package whose output is "SHOCK NOW" or does it provide a proposed reading with notation that the rhythm itself should be checked?
Whether the data output is provided or manipulated in a novel or non-traditional manner, or whether decision trees within the software depart from customary use. Example: Do the system's algorithms, parameters, internal decision trees, or other output manipulations depart from customary use or traditional data presentation?
Whether the medical software device provides individualized patient care recommendations, e.g., whether the software suggests or recommends specific treatment for a specific patient. Example: How specific is the software output with regard to particular patients? Is the software providing general advice or information, like a library, article, or textbook, or is the software designed to provide a specific recommendation for a specific patient whose individual data have been entered as input?
Whether the mechanism by which the medical software device arrives at a decision is hidden or transparent, i.e., does the product use undisclosed parameters or internal decision trees or other mechanisms that are not available for review by the health care provider. Example: How transparent is the software manipulation to the intended user community? Included in transparency is the extent to which limitations on the process are made known to the user, such as data contraction, deletion, editing, or simplification. Also, how are comparisons made to normative databases and how are normative databases created?
Does the product provide new capabilities or intended uses for the user?
Until FDA decides to further clarify the middle category of regulated but exempt from premarket notification, a practical consideration of those factors should help the company decide whether in FDA's eyes the software is risky enough to require premarket clearance. As I said, you won't find that in any existing FDA guidance or regulation. That's just based on practical observation.
Software Requiring FDA Pre-market Clearance
In the second article in this series, I outlined generally the approach for securing FDA clearance. In the case of software, the first step is identifying the most appropriate classification from among the roughly 1700 classification regulations. The word software is contained in 431 different regulations, so it's not an easy task.
Remember that software that accessorizes a medical device is classified with that medical device. So if a cell phone app allows for the downloading of blood glucose data, the app is classified with the blood glucose meter and regulated to the same degree. As another example, if the app is designed to help with medication management, there is a specific classification for such software in 21 C.F.R. § Sec. 880.6315. This can obviously get very complex in an interconnected system, perhaps on a wireless network, but that's too much for this article.
Usually in the context of clearing an app, FDA will check to ensure that the software manufacturer is complying with any published special controls. The special controls are typically stated in FDA guidance documents and include, for example:
Guidance for Industry — Wireless Medical Telemetry Risks and Recommendations
Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices
General Principles of Software Validation; Final Guidance for Industry and FDA Staff
Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software
Device-specific guidance (e.g. glucose monitors)
The submission will need to be based on an appropriate level of validation for the software. If the app is an accessory, the parent device determines the level of validation required. If not an accessory, to determine the validation required, you will need to figure out whether FDA classifies the software as "major", "moderate" or "minor" "level of concern."
It's major if the software directly affects the patient or anyone else such that a failure could result in death or serious injury
It's moderate if the injuries would be non-serious
An app's risk and the associated "level" determine:
the depth and degree of hazard analysis and mitigation that is expected
the depth and degree of documentation
what needs to be submitted vs. merely documented
the rigor applied to the verification and validation of the software
The degree to which the device manufacturer's software development process is scrutinized
And of course, before you can actually bring the product to market, you will need to make sure that your manufacturing meets the FDA requirements for quality systems. In the case of software, those requirements are acutely felt in the development stage as the software needs to be developed under special FDA design controls and in the post-launch stage as the manufacturer deals with product recalls, updates, event reporting, product lifecycle management and so forth.
Those are the basic FDA requirements that apply to bringing an app or other piece of software to market in the mhealth field. Undoubtedly, to those not accustomed to the FDA regulated world, those hurdles might seem high. In the next article, we'll tackle the benefits and burdens of going through those admittedly rigorous FDA requirements from a business standpoint. In particular we'll focus on the competitive advantages that can be derived from entering the regulated space, weighed against the cost of achieving those advantages.