The FDA's recent guidance on mobile medical apps creates a gray area in which the agency will not automatically require approval for all new mobile medical apps, but may exercise "enforcement discretion," depending on how the app functions, the risks it introduces to patients/consumers, and its intended use.
In a previous post, I discussed the some of the regulatory issues with mobile medical apps and the FDA's new approach toward them, illustrating an uncertainty the agency has about placing all new medical software innovations under the regulatory umbrella. Some interesting scenarios came up during an FDA-focused event earlier this year, which I've discussed with Ken Block, head of Ken Block Consulting. Block has written extensively on the FDA's history of evaluating software and firmware innovations.
Just as the FDA was issuing its mobile medical application guidance last fall, Block was helping a US-based healthcare system develop an app that would be used only by clinicians within that system. He became more intrigued when he inquired with the FDA as to whether or not his client would have to apply for a 510(k) clearance. The FDA said no, as long as the app was used within the system's own practice. But if the app were marketed outside that healthcare system, the FDA would have to clear it.
[Texting Dr. Watson. Read IBM-Apple Deal: Healthcare iOS Nirvana?]
The FDA's answer surprised Block. Traditionally, a doctor was free to do what he wanted with a device as long as he used it only on himself, Block said, and there is long-standing case law in which a medical device requires regulation if used under the auspices of conducting business, including practicing medicine. In that case, the device is considered to be in commercial distribution. But with the FDA's announced enforcement discretion, Block said, if a doctor creates an app on a mobile device that connects to an external set of sensors for use on his own patients, this app may not be regulated.
The FDA has issued 510(k) clearances for mobile medical apps, including viewing of medical images, mobile blood pressure monitors, and medical device data systems that attach to a consumer mobile device. But the FDA does not want (and does not have the resources) to handle the oversight of 100,000 apps currently in existence. Therefore, Block said, questions remain:
- What would stop a healthcare practice, hospital, or other such system from developing an EKG monitoring system built on a smartphone platform for internal use without FDA oversight?
- What are the risks in this case with no risk analysis, operating system compatibility testing, and so on?
Block said that it really comes down an issue of labeling and promotion. An entity can use any internally developed software as long as it's not promoted outside that entity.
From my point of view, the lack of clarity is a bit concerning, as the lines between consumer and medical products are blurring. There are clear financial incentives for ensuring a solid hardware design release before going into production compared to releasing a piece of software. In both the consumer and medical device sectors, the capital outlay needed for manufacturing changes to implement a hardware revision is not insignificant; good design practices include thorough verification testing before a design is locked down for production, regardless of any regulatory requirements.
Although verification testing is also part of good software development practices in the consumer world, the financial repercussions for not ensuring a solid software release are less severe, and in the wireless age, the logistics of issuing an interim update between major releases are less challenging. Consider the difference in the number of consumer product recalls (around 1,500) versus the number of FDA product recalls (around 8,000) versus the number of software updates on any mobile platform in a year (too countless to even measure -- as of last year, there are almost 12,000 distinct Android devices).
Too much is at stake for software used in a medical setting, compared with a consumer application. A revision released too quickly for an app that was not vetted thoroughly may cause the app to have poor performance or to crash. This may be acceptable if it's a game or social networking app that mainly results in user frustration with no dire consequences. But suppose this is an app falling in the enforcement discretion gray area that a clinician depends on to monitor a patient with a chronic illness?
As the medical device industry evolves to include more software-driven products on consumer platforms -- and as we see more developers from outside the medical sector create applications intended for medical use -- we will see situations arise where the FDA will be forced to be more proactive in closing this loophole. My recommendation to healthcare organizations seeking to develop such apps is to contact the FDA early in the development process to clarify any questions via the pre-submission program and to ensure that your software developers are using best-practices during development.
Has meeting regulatory requirements gone from high priority to the only priority for healthcare IT? Read Health IT Priorities: No Breathing Room, an InformationWeek Healthcare digital issue.