mHealth Technology: Design and Development of Mobile Integrated Therapies
As healthcare reform increasingly shifts the burden of patient management to the primary care setting, healthcare practitioners (HCPs) face a rapidly growing chronic disease population while their numbers struggle to keep up with the demand. According to the American Academy of Family Physicians, there are about 353,000 primary care physicians in the United States, and the country will need an estimated additional 45,000 by 2020. The number of medical students entering family medicine fell more than a 25 percent between 2002 and 20071. The need to create a new-to-the-world healthcare solution that supports the patient in all aspects of care is dire.
The primary care practitioner is well poised to be the central point-of-care, aiding a more holistic approach to the patient. However, the patient demand curve will quickly outstrip the supply of practitioners in even the best treatment models. An enhanced approach is necessary, one that enables patient self-management combined with efficiency tools for HCPs.
Products that offer this approach bring self-management, knowledge creation, and motivational tools to the patient, wherever they are and whenever they’re needed. For providers, they deliver new information and insights into the patient’s condition through the analysis of both patient reported information and data from traditional care. The HCP burden is then reduced as their patients are appropriately supported between office visits and the HCP can leverage clinical decision support derived from the patient’s medication, symptom, lifestyle, and biometric data to have more productive office visits. This merger of traditional healthcare plus support beyond the four walls of healthcare is incredibly powerful.
Today, few products deliver on this promise, but going forward, this new class of therapies will become increasingly integral to standards of care. These mobile integrated therapies (MIT) will also require traditional controls and validations, such as FDA clearance, prescription authorization from a physician, and robust clinical evidence, so that doctors can trust the products they prescribe.
Claims- and Risk-Based Framework
While the pros and cons of regulating mobile health “apps” is an ongoing debate , it is clear that the FDA and the healthcare industry are moving to a regulated model that appropriately mimics the framework in use today for traditional medical devices. Specifically, the regulatory status of an “app,” or of solutions like MITs, is dependent upon:
- The manufacturer’s intended use of the device
- The clinical claims that a manufacturer makes about the system’s features and benefits
- The level of risk to a patient’s health that the system might introduce
These claims and a risk-based framework are critical to the design and development of the solution. For MIT, the clinical, behavioral, and technology claims are essential to organizing and executing the product development lifecycle. Layered on this framework is the reimbursement structure or business model into which the MIT will be launched. This structure may drive the development lifecycle requirements (e.g., a randomized controlled trial to prove clinical outcomes).
In addition to clinical considerations, there are the technology claims associated with the platforms and devices on which MITs are supported (e.g., mobile operating systems, data-enabled device platforms, etc.). These technology claims can have a significant impact on the development lifecycle as the number of operating systems (OSes) and devices that must be supported increase.
User-Centric Technology Framework
Critical to developing an MIT that is successful in the market is a thorough understanding of the intended stakeholders (e.g., patients, clinicians, enterprise workers, and their use of technology. For example, it is important to understand the target patient demographic against the technology use characteristics of that target market. While smartphone penetration is increasing at a rapid pace in the U.S., the ongoing use of feature phones among many patient market segments may require a manufacturer to offer not only smartphone versions of their solution running on iOS and Android, but also versions running on J2ME for feature phones.
The same is true in the provider market, where technology adoption varies significantly—from practices that have adopted full-fledged electronic health record (EHR) systems to practices that are best served with fax-based solutions.
From a claims perspective, the market-based technology claims have a significant impact on the MIT development complexity. Consider, for example, a patient demographic of older, chronic disease sufferers being served by primary care physicians. In many markets, both patients and HCPs are going to be best served by a mix of mobile handset support (J2ME, Android, iOS) coupled with a web-based solution and a mix of fax-, web-, and EHR-based implementations for the providers.
Given the large quantity of feature phones still in use (J2ME-based OSes) and the wide variety of Android devices, a single MIT must be designed and tailored for each platform, considering important factors such as:
- Processor capabilities
- Memory requirements
- Screen resolutions
- Screen orientations
- Keyboard configurations
While the mobile web and the capabilities of technologies, such as HTML5, are evolving, many manufacturers continue to develop native OS platform solutions due to the increased capabilities and control that native application development allows. A key concern and a focus of increased scrutiny is how these solutions maintain not only quality and safety2, but also the security and privacy of all data contained in the system. Today, native apps often provide the greatest control over quality, safety, security, and data privacy and better enable manufacturers to provide the necessary evidence of compliance with all applicable regulations. Further, native design is a better fit for patient education and support as native design has been shown to maximize patient engagement, where as a one-size-fits-all design is more appropriate for transactional situations.
Validate Early and Often
Finally, as with all good product design and development, it is critical to validate designs early and often with target stakeholders. Developers are often surprised by the “mistakes” that their customers make when using their products. A key preventive measure is getting the designs into stakeholder’s hands as early as possible, even at the paper and pencil sketch stage. These design iterations with customers throughout the product development lifecycle will help safeguard that a manufacturer doesn’t experience costly “gotchas” late in development that are both expensive and time consuming.
For MIT, this early and frequent validation is a multi-stakeholder and multi-technology activity. For example, an MIT product that is delivered to the patient on three mobile platforms and the web plus a fax interface for healthcare professionals requires functional validation across mobile, web, and fax modalities. Further, the design validation should take into consideration not just product functionality but also the environment and “workflow” of each stakeholder.
This early and frequent design validation is even more critical to ensure that all of the clinical, behavioral, and technology claims can be met, significantly increasing the likelihood that a MIT will deliver not only a delightful user experience, but will help improve the health outcomes of patients and the effectiveness of their healthcare team.
For more information, visit www.welldoc.com .
1 Sataline, S., Wang, S. (2010, April 12). Medical Schools Can’t Keep Up. The Wall Street Journal. Retrieved from http://online.wsj.com/article/SB10001424052702304506904575180331528424238.html 
2 Brustein J. (2012, August 19). Coming Next: Using an App as Prescribed. The New York Times. Retrieved from http://www.nytimes.com/2012/08/20/technology/coming-next-doctors-prescribing-apps-to-patients.html?emc=eta1