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.
The Business Model for Supporting Innovation
mHealth innovators must live in the real world, and that real world has economic issues as well. The following are at least a few of the economic factors that need to be considered as we look to preserving and enhancing innovation in mHealth.
- Small companies. Fortunately for everyone, mHealth in particular is not a capital-intensive business, so small companies can engage in innovation and product development. This is good news, because it means that we can open up to a broader group the opportunity to develop innovative products. The bad news is that these companies tend to have less capital, and also tend to need more assistance from government regulators in understanding and navigating complex regulatory systems.
- Venture capital and angel investment. These small companies, because they often lack sufficient capital from the founders, need to seek out and obtain venture capital and angel investments. Okay, that’s a macroeconomic factor but I use it to lead into a microeconomic factor. To access that capital, the innovators need to be able to put together business plans that identify clearly the regulatory demands and the timetables associated with bringing their products to market. Thus, clarity in the regulatory pathway becomes extremely important.
- Access to markets in a reasonable time. There’s no getting around that mHealth is a business. While we all certainly have a focus on the patient and protecting the patient, healthcare doesn’t work in this country if those engaged in it can’t make a living. Thus, when determining the appropriate level of regulation, we need to keep in mind that the healthcare system cannot succeed in caring for patients if those working in it cannot operate a viable business and cannot bring their products to the market in a reasonable time. Again, this is partly because the innovators are often small, and may not have a diverse portfolio of products.
- Joint ventures and other deals between parts of the mHealth ecosystem. Because we are focused on technology networks, we need to appreciate that this will mean many different forms of business agreements among vendors supplying various components of those systems and their customers. These deals will impact the intended use of the various components of these mHealth systems. Regulators such as FDA focus on a product’s intended use, so the regulatory framework will need to be flexible to accommodate these innovative joint ventures that will undoubtedly impact the intended use.
- Reasonable and clear regulatory risk. Above we talk about the need for a relatively clear regulatory pathway to market, but here we are focused on regulatory liabilities associated with marketed products. For innovative businesses to attract capital, the regulatory risks need to be reasonable and quantifiable. These regulatory risks include such post-market obligations as adverse event reporting and conducting recalls. In a networked environment, presently these obligations are anything but clear.
Ambiguity and the Entrepreneur
I have just suggested that clarity is often desirable in regulatory requirements. But it is important to be precise in where clarity is desirable. In fact, depending on the particular regulatory requirement, ambiguity can be either good or bad in its impact on innovation.
- Ambiguity can be good when it creates the opportunity for flexibility in compliance. It’s actually okay for many regulatory standards to be written in a general way. The quality system regulations are written at a high level, which in a sense makes them ambiguous with regard to what they require. But that form of ambiguity is good in that it allows flexibility and innovation on the part of the manufacturer in determining how it will come into compliance.
- Ambiguity tends to be bad when it relates to the scope of a regulatory requirement. Industry needs to know whether a particular requirement applies or not. Knowing whether a given piece of software is subject to FDA regulation can make a big difference in the cost and timeline associated with bringing that software to market, so the developer of that software needs a fairly clear and certain understanding of the scope of FDA regulation. Likewise, knowing the classification of a medical device is critical to determining what types of regulatory requirements apply. Ambiguity there is not helpful.
So that’s my assessment of important conditions at the individual company level that allow creative people to innovate in mHealth. As I asked at the outset, please tear it apart. I’d love to get your thoughts on this topic. After folks have had a chance to offer their own observations on the innovation process, I’ll attempt to identify the key FDA requirements that the agency should modernize to allow this innovation to flourish. My hope is that our friends at FDA might read your comments and mine as they think about the strategy they are developing this fall for the future regulation of mobile health.
