FDA forum explores regulation of mobile medical apps

How should the U.S. Food and Drug Administration (FDA) regulate mobile medical apps? More than 20 experts shared their opinions with the FDA on September 12, the first day of a two-day public forum in the agency's Rockville, MD, headquarters.

Nobody disagreed that the FDA should regulate mobile medical apps used specifically for diagnostic or clinical treatment purposes. But for apps in which the use might not be clearly defined, apps that are accessories to other medical devices, and accessories supporting medical apps, the opinions that were expressed reflected controversy and concern.

Mobile devices and the medical apps that support them represent a technology explosion, sure to make a revolutionary change in healthcare delivery. The crux is how the FDA can keep up with mobile developments, protecting patients from potential harms without stifling innovation and R&D investment.

In mid-July, the agency published a draft guidance document on its proposed regulatory approach, and the agency is soliciting comment through October 19, 2011. The document defines mobile medical applications designed for mobile computing devices and smartphones that the FDA intends to regulate, and delineates mobile medical applications that affect or could affect the performance or functionality of currently regulated medical devices.

Monday's meeting was designed to give industry and experts the opportunity to comment on the agency's direction.

The first two panels included representatives from nonprofit organizations promoting Web-delivered patient education content and innovations to lower the cost of healthcare, as well as a consulting firm specializing in global medical device regulatory requirements, a venture capital firm, mobile apps developers, and hardware vendors. All emphasized that the potential for mobile apps to change the healthcare world is enormous.

The market exists, according to Robert Jarrin, senior director of government affairs for Qualcomm. Nearly 6 billion people have access to at least one mobile phone, he said, and by the end of 2012, the number of smartphones in use will exceed the number of personal computers.

Anand Iyer, PhD, president and CEO of WellDoc, a developer of chronic disease management tools, emphasized that mobile apps can be both a virtual coach for patients and an expert system that watches for longitudinal patterns and takes data and converts it into information, knowledge, and/or action. Apps need to be innovative yet also protect and balance patient safety, he said.

Regulatory oversight

Most panelists said they believe regulatory oversight should be determined by intended use as stated by the manufacturer, and the level of risk of endangering patient safety by the intended use. Bakul Patel, who served as the FDA's moderator for the forum, said the agency is trying to find the right balance on the range of regulation for mobile medical apps, based on patient safety, marketplace needs, and what the agency has done in the past. This could range from enforcement discretion -- namely, watching how apps with specified intended use were actually used -- to class III premarket approval.

Even with different levels of justified oversight, oversight and regulations can be made obsolete by technology, noted David Hirschorn, director of radiology informatics at Staten Island University Hospital, who represented the American College of Radiology at the meeting.

Hirschorn pointed out that mobile medical apps designed for diagnostic interpretation of radiology images display very small images, and he agreed that they should fall under FDA regulation. However, the lines between a medical display for a mobile device and a commercial display will soon blur with the speed of technological advances. Do we need clarity about software that is developed specifically for mobile applications versus Web-based applications to display images? Shouldn't a radiologist be able to determine if the quality of a mobile display or the size of an image is appropriate?

Bernie Liebler, director of technology and regulatory affairs of the Advanced Medical Technology Association (AdvaMed), agreed with Hirschorn that the FDA can't control how a particular piece of hardware, such as a display monitor, is used, no matter how it may or may not be regulated.

He also pointed out that even after FDA validation, complex medical software will have yet-to-be-discovered bugs. How will the FDA deal with the issue of bugs in mobile app software designed for data collection and automatic transfer? What happens when a $39 device with an app for patient self-monitoring gravitates to moving data from a personal health record (PHR) to an electronic health record (EHR) and displaces an FDA-approved $1,000 device used for this purpose?

Daisy chaining and data analysis

How to deal with the transfer of data from one device to another, or daisy chaining, generated much discussion. So also did the issue of data analysis. There was general consensus that each app should be responsible for maintaining the integrity of data transfer, but when the data are being analyzed for potential clinical decision-making, the app that performs analysis should be regulated. But precisely how should the FDA regulate an app that might integrate data from multiple apps from multiple vendors, each of which might not know how their data are being merged? That question was raised repeatedly.

Maintaining security for data that were not used for a clinical purpose in the originating unregulated app -- but that might be transferred to a different app -- concerned more than one panelist.

"Security must be built in," Hirschorn emphasized. "You can't assume that someone else is going to take care of security. Both patients and physicians need to see health information in a secure manner. Developers need to plan for security, just as they need to plan software development to meet a quality standard."

Panelists suggested that the FDA draft guidelines do not clarify where regulatory borders exist as mobile medical apps interact with networks and with EHRs. Defining risk assessment, the probability of risk assessment, and how the risk assessment may affect a patient and a care provider can become nightmarishly complex.

A huge issue that panelists said the FDA has not confronted in its draft guidance document is dealing with interoperability of multiple unrelated mobile medical apps. Leslie Kelly Hall, a senior vice president at Healthwise, a health content and patient education provider, emphasized the importance of considering how mobile apps interact with other devices.

Hall stressed the need for companies to adhere to standards developed by the mobile device industry or the FDA, and be able to prove that they could do so. This does not mean adding a layer of regulation, she said, because this could get too complex.

Hall asked who is liable if mobile apps do not work as they should with each other. She used the example of Lego blocks -- all pieces are interoperable, but interoperability does not guarantee stability. Who is liable when harm occurs to a patient if the building blocks collapse?

And what if individual devices that are FDA-approved -- and that are supposed to work flawlessly together because they all adhere to a standard -- don't function? What is the responsibility of a mobile medical app software developer to ensure that its product will "play nicely" with other apps residing in a platform "sandbox"?

Mobile apps as accessories

Patel asked panelists and forum attendees how they felt the FDA should make sense of mobile apps as accessories to medical devices. Should it be based on intended use?

Attorney Bradley M. Thompson, a partner of the law firm Epstein Becker Green, suggested that when it comes to regulating accessories, the clearest, cleanest way is to classify them. He suggested that there be a specific classification, however broad, based on functionality rather than the uniqueness of what the mobile app does.

"This would free up and avoid overregulation, even with the rules proposed by different tiering," Thompson said. Manufacturers would have an obligation to have proof of functionality needed for a specific classification.

Patel concluded the day's session, which raised many more questions than recommendations for changes to the draft guidance document, with an observation.

"An app in 10 years may be services and utilities that have no bearing to the definition of an app that we know of today," Patel said "An app has the definition of self-contained functionality going forward. The more we can avoid definitions of computing and understand how regulations may deal with change and design, the more helpful it will be to everybody."