Sara Koliner, Policy Analysis Project Assistant, Project HealthDesign National Program Office
Mobile apps have proven to be valuable tools for collecting ODLS in this last round of Project HealthDesign. While the benefits are clear, however, creators of mobile apps must contend with a complicated interplay of safety, cost, usability, and accessibility in order to produce high quality software. Weakening these foundations can lead to misuse by consumers, or rejection by practitioners. On the other hand, overabundance of requirements can stall progress and hinder the utility of these applications.
A few weeks ago, the Healthcare Information and Management Systems Society (HIMSS) held its 13th annual conference in New Orleans, LA. In one notable e-session, presenters Katharina Steininger and David Rückel outlined the values of key stakeholders in mobile health applications, and thus the priorities that should be used in applications themselves. A copy of their slideshow is available here.
In “Mobile Health Applications—Strategic Stakeholders’ Perspectives,” Steininger and Rückel name key stakeholders in mobile health applications: patients, practitioners in private practices, emergency medical services and mobile homecare, hospitals and nursing homes, application developers, and statutory and private health insurances. While the stakeholders often have common aims such as higher quality care and improved security, their priorities are unique and often contradictory.
The solution here is specificity: choose your stakeholders, and this will define your priorities. While the presenters describe doctor-to-patient and doctor-to-doctor style applications, they leave out the most relevant setting: patient-to-doctor communication.
Project HealthDesign teams inherently centered themselves around patients by designing mobile apps to use the data that embodies specificity: ODLs. By incorporating Observations of Daily Living, developers automatically look to the values of patients, and so produce a more effective application. Applications like BreathEasy even provided a separate dashboard for clinicians, allowing both the smartphone and computer-based portals to serve the exact needs of targeted users.
A final note on the importance of specificity: On Tuesday, March 19, the Energy and Commerce Committee hosted a hearing regarding the regulation of mobile health applications. In view of whether mobile health applications should be considered medical devices, gray areas indeed exist in applications that intend to replace monitors already used in the clinical setting. Applications dedicated to the capture of ODLs, on the other hand, add entirely unique patient-defined and patient-generated data to the workflow. The specifically non-clinical nature of ODLS requires a different framing of the quality question—one that addresses both the reliability from the patient’s perspective and accountability on the part of the clinicians. If quality standards are to be applied to this type of mobile app, they will have to be quite different from the standards currently used for clinical care metrics: if not necessarily relaxed, they must account for the idiosyncrasies of data shaped at the level of the individual.
Ingenuity and flexibility are essential to the development of quality mobile applications. As long as developers remain keyed into the patient perspective, they should be encouraged to use these faculties as effectively as possible.
