As just about everyone knows, last week the FDA published its final guidance on mobile medical apps. That guidance explains in plain English the types of mHealth apps the agency regulates. Over the coming weeks, many of us will be dissecting that guidance to assess what it really means and how the guidance affects the numerous apps already released, as well as those on the drawing board. I have made plans to meet with various mobile medical app developers in the next few weeks to hear their questions regarding how this guidance should be applied, and I plan to post my findings as we start peeling the onion of our understanding.
But the guidance, really only address the scope of FDA regulation; it does not explain how the various regulations are actually applied to mobile apps.
This fall, with help from ONC and FCC, FDA will draft the government’s strategy for how to regulate mHealth. In doing so, FDA might consider such things as which types of regulated apps need to undergo FDA premarket clearance, and how the quality system regulations will be applied to mobile apps. In formulating the government’s strategy, the agencies are supposed to encourage continued innovation in mHealth as much as possible. The question is, how should they do that?
It seems to me they ought to start by understanding the factors that drive innovation in mHealth. So what are those factors, beyond the availability of pizza?
In this post, I’m going to share what I think are some best practices that support innovation. But I’m merely an observer, not a participant, so I would love it if readers would tear these thoughts apart and put forth what you’ve seen as the key drivers of innovation. Here we are not talking about macroeconomics and policy such as the availability of venture capital and good IP protection, but rather microeconomics and company conditions that need to exist for innovation to thrive. After giving readers some time to comment, I will offer a second post on how these factors mesh with FDA requirements, in an effort to identify those FDA requirements that need to be modernized.
The Nature of Innovation in mHealth
I divide the universe of factors important to innovation into two broad categories, specifically (1) the act and process of innovating and (2) the business model for supporting innovation.
The Act and Process of Innovating
I have tried to collect best practices from leading companies in mHealth to discern how they succeed in innovation. I’m sure this is only a partial list, but hopefully it represents a good start in identifying what needs to be protected and allowed to flourish.
- Collaboration among app developers, clinicians, medical device developers and scientists of many sorts. Collaboration is the wellspring of innovation. Perhaps in some areas of technology, innovation can occur from a lone, brilliant scientist tinkering late at night in his own lab. But in the area of mHealth, true innovation uniformly comes from collaboration among very disparate sets of expertise. After all, mHealth often is about connecting the patient to this data, and often to his caregiver.
- Finding talent wherever it might be. In a sense, this is a continuation of the collaboration need, but here I am focused on the fact that the needed experts might be dispersed around the world. In other areas of technology development, it’s more traditional to bring everyone together under one roof to facilitate the development process. In IT, it’s quite common not to bring everyone together physically but to let them interact virtually throughout the United States and the world.
- Tinkering and experimentation, with feedback loops. Any form of engineering requires the development of prototypes, but software development in particular involves the development of beta versions that can be tested in real world situations in order to obtain feedback and strengthen the technology. Consequently, to make real progress in mHealth, we need to ensure that that tinkering and experimentation can continue in some appropriate way.
- Major breakthroughs followed by many, many incremental improvements. The pace of innovation is uneven. Certainly there are inspirations in which new technologies are created, or new uses for existing technology are identified. But those breakthroughs typically are followed by a significant number of incremental enhancements over sometimes a prolonged period.
- Nonlinear process. Creative minds tend to zig and zag. If you add to that collaboration where many people are working together, innovation tends to happen here and there, not necessarily according to some linear process. Regulatory restrictions, for example, in the name of a quality system that attempt to make development a purely linear process are doomed to cause confusion and unnecessary burden.
- Short product lifecycles. Indeed, this is simply the other side of the coin from the rapid progress in mHealth technology. But it’s important also to understand and appreciate the cultural impact that the short lifecycles have on the developers themselves. Developers thrive in an environment in which change is constant, and progress is something that can be made virtually every day. Fundamentally changing that culture and environment by imposing regulatory obligations that would dramatically lengthen the product lifecycles would have a tremendous stifling impact on the exciting cultures that exist in these technology developers’ organizations.
- Sensible technology standards driven by industry. The promise of mHealth depends tremendously on the interoperability of medical devices and IT systems. Thus, for mHealth to flourish, the developers of these technologies need to agree upon common standards to be used. While this in a sense constrains innovation, industry organizations are in a position to develop the standards in a way that balances the need for innovation with the need for standardization.
- Modularization of software. It never makes sense to reinvent the wheel. Software development is no exception. Over the last few decades hundreds of thousands of software developers have created literally millions of software programs that accomplish a mind-boggling range of tasks. It simply doesn’t make sense to ignore those existing software modules when developing new programs. So instead, developers stitch together existing programs and then add a new innovative coding to do whatever is new or different that the developer wants to accomplish. Sometimes this is done by drawing those modules together into a single program, and sometimes it is effectively accomplished by a software program being designed to interact with other software on a given platform, such as a mobile phone. A simple example is a software application on a mobile phone making use of the existing program that tracks date and time. Any regulation needs to appreciate this fundamental design dynamic.
