So you have a great idea for an app. Not so fast: it took two years and over half a million dollars to get ours cleared for marketing by the US Food and Drug Administration (FDA).
Our app, DANA uses a mobile phone to records peoples’ reaction time during game-like tests. It also provides questionnaires that help clinicians evaluate brain health. Commissioned from AnthroTronix by the Department of Defense, the app will help diagnose concussion, depression and Post-Traumatic Stress Disorder (PTSD).
For something so important, a serious investment of time and money for clearance may not sound extravagant, but few small companies can afford a two-year go-to-market delay, not to mention the significant investment and heartache that goes with it. And although the FDA has tried to facilitate regulation by providing guides like the Mobile Medical Applications Guidance Document and the Mobile Medical Applications website, the regulatory process remains confusing.
Here are five simple lessons from our own experience that will help other entrepreneurs to do the right thing and engage with the FDA:Continue reading…
The Food and Drug Administration has spent decades refining its processes for approving drugs and devices (and is still refining them), so what would happen if they extended their scope to the exploding health software industry?
The FDA, and its parent organization, the Department of Health and Human Services, are facing an unpleasant and politically difficult choice.
Sticking regulatory fences into the fertile plains of software development and low-cost devices will arouse its untamed denizens, who are already lobbying Congress to warn the FDA about overreaching. But to abandon the field is to leave patients and regular consumers unprotected. This is the context in which the Food and Drug Administration, the Office of National Coordinator, after consultation with outside stakeholders, released a recent report on Health IT.
I myself was encouraged by the report. It brings together a number of initiatives that have received little attention and, just by publicizing the issues, places us one step closer to a quality program. Particular aspects that pleased me are:
- The suggestion that quality programs should start to look at electronic health records (p. 8). EHRs have been certified by various bodies, but usually just to check off boxes and declare that the systems comply with regulations–neither the quality of their user interfaces nor the quality of their implementations have been questioned. Reportedly, the FDA considered “safety and quality standards” for electronic health records in 2010 but couldn’t get them adopted. It also checks certain forms of clinical decision support, but only if they are built into a regulated device. The current HHS report refers back to aspirational documents such as a Health Information Technology Patient Safety Action & Surveillance Plan and a set of guidelines on the safety of EHRs.
- A call for transparent reporting and sharing of errors, including the removal of “disincentives to transparent reporting”–i.e., legal threats by vendors (p. 25). Error reporting is clearly a part of the “environment of learning and continual improvement” I mentioned earlier. A regulation subgroup stated the need most starkly: “It is essential to improve adverse events reporting, and to enable timely and broader public access to safety and performance data.” Vague talk of a Health IT Safety Center (p. 4, pp. 14-15) unfortunately seems to stop with education, lacking enforcement. I distinctly disagree with the assessment of two commentators who compared the Health IT Safety Center to the National Transportation Safety Board and assigned it some potential power. However, I will ask ONC and FDA for clarification.
- A recognition that software is part of a larger workflow and social system, that designing it to meet people’s needs is important, and that all stakeholders should have both a say in software development and a responsibility to use it properly.
Don’t imagine that the FDA is unused to regulating software. For quite some time they have instituted practices for the software used in some medical devices , and have tried to keep them up-to-date.
A waterfall-like process of risk assessment and testing called computer system validation has long been required for pharma and devices.
I recently had the great fortune of attending Health 2.0 in San Francisco. The conference was abuzz with new medical technologies that are harnessing the power of innovation to solve healthcare problems including many new mobile medical application companies showcasing their potential. As I walked and talked around the exhibit floor, one thing caught my ear, or I should say one thing didn’t catch my ear. Among the chatter about these products, the concern about FDA regulation of this product segment, or even FDA regulation in general was noticeably absent. While many of the application developers are well aware of potential FDA involvement, most would be hard-pressed to outline the impact this would have on their companies and products.
Being labeled a medical device, which is the direction the FDA is leaning, could have a significant impact on business model organization, top-line revenue, and product deployment. For unprepared start-ups, FDA regulation could signal an end for their company. This is in stark contrast to well informed developers who are preparing themselves for the change and would most likely be able to leverage these regulations to their advantage.