FDA opens forum to explore regulation of mobile medical apps

2011 02 08 14 41 28 731 Fda Logo Blue Thumb

How should the U.S. Food and Drug Administration (FDA) regulate mobile medical apps? More than 20 experts gave the FDA their opinions on Monday, the first day of a two-day public forum in the agency's Rockville, MD, headquarters. But as many questions were raised as recommendations posed.

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

A technology explosion

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 FDA 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. Yesterday's meeting was designed to give industry and experts the opportunity to comment on the agency's direction.

The first two panels on Monday 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.

Ken Dicks, CEO of MedApps, a company that provides mobile health monitoring devices and services for patients with chronic diseases, said that within the past three years, potential customers have passed the stage of implementing pilot programs and now want to implement programs that produced results. Large corporations are requesting technology that will deliver data in a timely manner to enable intervention to prevent healthcare incidents, rather than analyzing healthcare treatment claims data delivered 60 to 90 days later, he said.

The market exists. Robert Jarrin, senior director of quality assurance for Qualcomm, pointed out that 5.7 billion people have access to at least one mobile phone, and by the end of 2012, the number of smartphones in use will exceed the number of personal computers. Mobile apps have the potential to improve the level of wellness of a population by their ubiquity, and through the infatuation users have with this technology.

Anand Iyer, PhD, president of WellDoc, a developer of chronic disease management tools, emphasized that mobile apps can be both a virtual coach for patients as well as 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 emphasized.

And that brought up the subjects of patient safety risk, regulation, cost to meet regulatory requirements, barriers to market entry faced by fledgling "garage-based" entrepreneurs, venture capital investment decisions, and getting safe, useful apps to market.

Regulatory oversight

In the opinion of the majority of panelists, 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 that the agency was 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 Dr. David Hirschorn, director of radiology informatics at Staten Island University Hospital, who represented the American College of Radiology (ACR) at the meeting.

While the FDA requires the use of 5-megapixel medical-grade monitors approved for interpreting mammograms, nothing precludes Hirschorn as a radiologist from interpreting images that are not mammograms on a commercial-grade monitor that may be routinely used to display lab values. This is his decision regarding his practice of his medical specialty, he pointed out.

"FDA regulations have created trade-offs," he said. "I make the decision as to whether I can make a diagnosis from a monitor display, and whether I want to use a more cost-effective commercial monitor in my home to provide medical services in the most timely way."

"Because mammography monitors must be approved by the FDA ... they do not keep up with the times," explained Hirschorn. "On paper, these monitors meet minimum FDA guidelines, but in reality several years after their purchase, they may be the dimmest monitors in a radiology department. Some new monitors with better technology have better software with respect to displaying mammography images, yet we cannot use them."

He 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?

Panelists pointed out that "intended use" should be the main factor determining whether the FDA should regulate a particular application, but that there are major challenges. These include different levels of informed users, from those who know that a mobile platform is appropriate for a particular use to those who do not.

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.

One panelist noted wryly that the odds of an elderly patient using a mobile weight-monitoring device where incorrectly transferred data could trigger harmful clinical action might be much less worrisome than the elderly patient falling over the scale that provided data to the device. Would the cost to guarantee data integrity be worth it? Wouldn't it be just as effective for a nurse who received an alert triggering clinical action to contact the patient and ask that person to weigh him or herself again?

Interoperability

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? PACS components that all adhere to a DICOM standard yet do not process data properly was another example cited.

What is the responsibility of a mobile medical app software developer to make sure that its product will "play nicely" with other apps residing in a platform "sandbox?" Who guarantees that a regulated mobile medical app will interface with an unregulated app from a different software developer when both reside on different mobile devices? Who is responsible for failure among many potential permutations?

Using this as an analogy, how far should the FDA venture to guarantee that device functionality is not affected, especially when what may be affected is a cardiac monitoring device that interacts with one or more mobile apps?

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 of 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."

Page 1 of 775
Next Page