[Ed. This is the second of a three part series examining the past & present of FDA regulation of mHealth]
By: Felasfa Wodajo MD, Rene Quashie JD
In part 1 of this series, we covered the FDA “basics”: what does the FDA regulate, who needs FDA approval and what are the different classes of medical devices. We are now going to delve a bit into FDA culture, the recent final ruling on “MDDS” devices and try to guess how the FDA will interact with future mHealth devices.
In its early days of regulating medical devices, the FDA was primarily interested in electromagnetic emissions as there were many hospital devices that could interfere with each other, as found in intensive care units, operating rooms, etc. Over time, as the devices became more sophisticated, the FDA’s scope broadened to include not just the electromagnetic characteristics of the devices but also the controlling software .
The first example of this was software for planning radiation therapy, for example, for treating prostate cancer. This was a logical starting point as the potential for harm from inadvertent radiation overdosing due to faulty software was no less urgent than that due to improperly calibrated radiation sources. The verity of this was demonstrated in a New York Times report just last year in which software errors led to serious harm or even death in patients receiving radiation therapy in various hospitals.
The agency’s interest in software continued to expand, even reaching the code used to control IV pumps. The year 2000 and fears of the “y2k” bug really focused the agency attention on software. Going forward, it is reasonable to assume that the FDA, like many regulatory agencies, will continue to interpret its scope as broadly as possible.
The primary role of the FDA is to protect the public health. This must be remembered by any mHealth entrepreneurs who feel like the FDA is not doing enough to promote technological advances. In the realm of patient care, failure is to be avoided at all costs. This predictably sets up a culture clash with the fast moving mentality of silicon valley startups where “fail fast” is mantra.
Rather than focusing immediately on the potential benefits of a shiny new technology, the FDA will be first interested in risk, and even more specifically on the most serious potential risk. In other words, the regulators will look carefully at the worst case scenario. Therefore, if your FDA application spends page after page extolling the time and money savings of your new device and passingly mentions the faint chance that a patient could die due to incorrect insulin dosing, you should know the reviewers’ eyes will gloss over the good news and quickly alight on the risks section.
In 2008, a preliminary rule was proposed to reclassify Medical Device Data Systems (MDDSs) from class III (premarket approval) into class I (general controls). The final rule (21 CFR Part 880) was published Feb 15, 2011 and went into effect April 18, 2011.
According to the rule, the definition of MDDS devices are those that are:
intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. MDDSs perform all intended functions without controlling or altering the function or parameters of any connected medical devices. An MDDS is not intended to be used in connection with active patient monitoring.
Thus it would seem MDDS designation would thus cover the large proportion of medical apps currently in the marketplace, and simplify the lives of mHealth entrpreneurs who can introduce these devices as class I . However, the stipulations are strict enough to exclude many useful devices. As Tim Gee described on his Medical Connectivity blog, a device can be described as an MDDS if it:
- Directly receives data from medical devices
- Converts the data from one format to another according to preset specifications (e.g., parses the original protocol and converts it into a format used by your system, and/or converts units of measurement or changes data labels)
- Stores and/or displays the data
- Makes that data available to other systems
If it fails any of the above criteria or, equally importantly, the device “provides additional capabilities or features”, it would not meet MDDS criteria and thus would not necessarily be a Class 1 device.
The mHealthRegulatory Coalition organized itself in July 2010 to “guide” the FDA by framing the questions around regulating mHealth devices. In their white paper titled “A Call for Clarity: Open Questions on the Scope of FDA Regulation of mHealth”, they pointed out that MDDS
“are not intended or designed to provide any real time, active, or online patient monitoring functions” or “provide any diagnostic or clinical decision making functions”.
And, while MDDS can deliver and store alarm data, they
“do not have the capability to display, create, or detect alarm conditions, or to actually sound an alarm. In particular, an MDDS can record the fact that an alarm sounded, but cannot by itself sound an alarm in response to patient information” or “create alarms that are not already present from the connected medical devices.”
Thus, it would seem the safe haven of Class I MDDS designation would apply only to devices which act merely as links in a bucket-brigade of information, without clinically meaningful interactions with patients or clinicians.
Reading FDA tea leaves
The FDA is fundamentally an audience of engineers, and as such they are looking for specifics of how devices function at their limits, i.e. the borders of their indications. As such, it is up to the applicant to “tee the ball up” when applying. Meaning that, rigorously describing each potential failure point is better than leaving it to the regulators to try to surmise them. In other words, it is better to pose the questions and thus drive the answers.
In terms of approving the platform, devices with “off the shelf” hardware and software, will more likely be presumed safer than proprietary components, which will likely incur more scrutiny.
The initial hope when the medical device amendment was passed was that many device applications would be Class III, a few Class II. However, due to competitive pressures, that did not happen. Nowadays, FDA is thus stuck with more than 10,000 applications annually for “substantial equivalence” Class II devices and just a couple of dozen in Class III.
So, with some risk of embarrassment, we can make the following predictions:
- There will be increasing FDA regulation of mobile software in the future.
- This will also affect home use devices and remote sensing devices.
- Some of the push to get these devices to market will come from patients who want to communicate with their doctors via smartphones.
While most of these will almost surely go via 510k process, there may well be testing requirements as part of the “substantial equivalence” standard, while there may still be a few PMAs. If the volume continues to increase, a division that handles just the communicative portion of devices in the future may be formed to coalesce folks with the appropriate expertise, much like a division for orthopedic products is apparently being contemplated.
The difficulties posed by rapidly evolving technologies in applying the “substantial equivalence” standard for Class II clearance may eventually result in a sort of “Class IIb” designation where manufacturers submit manufacturing or clinical data only for the purpose of deciding whether the device should be categorized as Class II or III.
FDA Draft Guidance, July 21
Earlier this month, the FDA issued the first and highly anticipated draft guidance on how it intends to regulate mobile health apps. These guidelines begin to spell out what the FDA considers “components” and “accessories” and what types of apps it will regulate. From the press release, the subset includes mobile medical apps that::
a. are used as an accessory to medical device already regulated by the FDA(For example, an application that allows a health care professional to make a specific diagnosis by viewing a medical image from a picture archiving and communication system (PACS) on a smartphone or a mobile tablet); or
b. transform a mobile communications device into a regulated medical device by using attachments, sensors or other devices(For example, an application that turns a smartphone into an ECG machine to detect abnormal heart rhythms or determine if a patient is experiencing a heart attack).
Check tomorrow for the final Part 3 of this series where we delve further into this new draft ruling.
Rene Quashie JD is a government relations director/regulatory attorney at Drinker Biddle who is focused on the role of federal regulation in health care delivery. We would like to acknowledge the kind assistance of Joel Slomoff, a FDA veteran and expert in FDA regulation. Nonetheless, any omissions or mistakes herein are entirely our own.