In my post for InformationWeek Healthcare, I discussed the implications of the U.S. Food and Drug Administration’s (FDA) final guidance for medical apps. While the September 2013 guidance specified that it would require clearance of any app intended to diagnose, treat, mitigate or prevent a disease, it left an open door to exercise “enforcement discretion” if an app meets the technical definition of a medical device but poses a low risk to the patient.
In this post, I will discuss the practical challenges resulting from this guidance, and how the evolving environment of app regulations should be folded into your business strategy.
The FDA does not want smartphones to become regulated medical devices—the sheer volume of phones and apps alone would overwhelm the agency’s resources. Hence, many apps will fall under “regulatory discretion.” For technical innovators moving into medical areas for the first time, this will present a number of new issues. Here are five considerations:
- Make sure your technology is being used as intended. For example, who will use an app that calculates insulin doses for diabetics? If the intended user is the clinician, then the FDA regards this app as a tool for a licensed professional who will ultimately use clinical judgement in making treatment decisions. But if the intended user is the patient, then the app would fall into regulated territory. This distinction can make a huge difference in defining what is a high risk to the patient.
- Incorporate regulatory review time and costs into your business strategy. The cost of a 510(k) device regulatory submission, while not nearly as expensive as a PMA (pre-market approval), can be substantial, depending on the studies needed to meet safety and efficacy requirements, and can take one to two years for the FDA to review. Resubmissions, while typically less expensive, can still be equivalent to a significant portion of the original cost.
- Remember that any changes to software will have to be resubmitted to the FDA for clearance. Without good QC processes in place, this can be difficult to manage and control given the dynamics of software development. Also keep in mind that the FDA, some consultants and software developers tend to be more comfortable in the hardware environment and may not be able to provide the best guidance specific to medically oriented software development.
- Strive to ensure your new device performs any clinical decision algorithms on the device itself, and not in the “cloud.” If decisions are made wirelessly beyond your device, the FDA may require the entire system infrastructure to be included in the regulatory filing, which may be technology over which you have no control.
- A regulated device will require more quality control staff and processes (including HIPAA data encryption), which can be expensive if starting out new. Fortunately, other medical app companies could be available for partnerships that have QC processes in place, or can advise you on creating your own.
The FDA’s avoidance of clear delineation for when you are crossing into regulated territory will call for more engagements with the agency and possibly collaborations with other, perhaps more established, medical app players. Most important, you and your investors will need an abundance of patience in the regulated environment. Focusing on the clinical need for such an app, and its intended use, will help you create a clear regulatory and business plan.
(mobile apps / shutterstock)