Update on the Status of the FDA’s Regulation of Mobile Apps

Robert Belfort, Project HealthDesign Regulatory and Assurance Advisory Group, Manatt, Phelps & Phillips, LLP

Last July, the U.S. Food and Drug Administration (FDA) issued draft guidance on how the agency intended to regulate certain mobile medical applications (apps). My colleague, Deven McGraw, described the guidance in a post last year. The draft guidance sparked heated debate. And some in Congress recently pushed to delay the FDA’s final adoption of the guidance for fear that it might stifle innovation.

The story of Congress’s brush with the proposed guidance is brief but noteworthy. During a Senate Health, Education, Labor and Pensions Committee hearing in April 2012 on the Food and Drug Administration Safety and Innovation Act, the legislation that authorizes the FDA to collect user fees from the companies it regulates, Senator Michael Bennet (D-CO) proposed an amendment that would have placed a moratorium on the FDA’s publication of the final guidance.  “I appreciate very much the work the FDA has done to receive stakeholder input, but this interaction between health information and medical devices must be handled delicately. Technology is evolving and being adopted rapidly. I think Congress must provide the proper due diligence on this issue for our constituents, including a number of startups, small businesses, and patients in my home state,” said Bennet as he described his rationale for the moratorium.

Ultimately, Congress passed the Food and Drug Administration Safety and Innovation Act without the moratorium. As enacted, the Act allows the FDA to move ahead with its plans to regulate mobile medical apps while the U.S. Department of Health and Human Services develops a report on an “appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety and avoids regular duplication.”

Now that the specter of a moratorium is no longer, the FDA is expected to release its final guidance as soon as the end of the year. A brief refresher on the FDA’s regulation of medical devices and on the guidance, as the FDA proposed it in July 2011, is below.

1. Background on the FDA’s Regulation of Medical Devices

A product is a medical device under the federal Food, Drug and Cosmetic Act (the FDCA) if it is “an instrument, apparatus, implement, . . . including any component, part, or accessory, which is . . . [either] intended for use in the diagnosis . . . or . . . cure, mitigation, treatment, or prevention of disease, . . . [or] intended to affect the structure or any function of the body of man . . .”  The FDA has stated that for software to fall under this definition, “it is sufficient that it is intended to be used in the process of diagnosis, preventing, or treatment of medical conditions, and it is not necessary that the software actually make or recommend a final diagnosis.” The FDA evaluates intended use by looking at factors surrounding the product’s promotion and distribution.

Vendors of software that qualifies as a medical device must register as manufacturers and list their products with the FDA. The FDA classifies and regulates devices under three categories, according to the amount of potential risk associated with the device’s intended use and indications for use. Class I devices present the lowest risk and are typically exempt from the pre-market submission process, but are subject to general controls required for all devices, including registration, labeling, adverse event reporting, and good manufacturing practices. Class II devices must generally undergo the pre-market notification process. Class III devices are most stringently regulated and require pre-market approval.

2. The FDA’s Draft Guidance on Regulation of Mobile Medical Apps

The FDA’s July 2011 draft guidance document indicated that the Agency intended to apply its regulatory oversight to a subset of mobile apps called “mobile medical apps,” defined as a mobile app that meets the definition of a “device” that either is used as an accessory to a regulated medical device, or transforms a mobile platform into a regulated medical device. The FDA proposed to monitor and apply enforcement discretion to other apps that qualify as devices but do not meet the mobile medical app definition; a manufacturer may choose to register and list, and to seek the FDA approval or clearance for such apps.

The guidance also listed certain apps that the FDA does not consider to be “mobile medical apps,” including “mobile apps that are solely used to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining general health and wellness.”  Examples of health and wellness apps are provided in the guidance, and include dietary tracking logs, appointment reminders, dietary suggestions based on a calorie counter, posture suggestions, exercise suggestions, etc. In contrast, a mobile medical app is one that is intended for “curing, treating, seeking treatment for, mitigating, or diagnosing a specific disease, disorder, patient state, or any specific, identifiable health condition.”

As Deven pointed out in her post last summer, the FDA tried to draw clear lines and offered more examples of mobile medical apps in the guidance (see appendix A). However, the distinction between mobile medical apps and health/wellness apps is not always clear. Today, medical conditions are significantly improved — and even prevented — by healthy behaviors, and providers might prescribe or at least recommend particular diet or exercise protocols as part of medical treatment. Many mobile health applications in development and in active use today fall in a gray area between medical and health/wellness. Where do you think the consumer-facing health applications that the Project HealthDesign teams are testing fall?

Comments on the FDA’s draft guidance were due by October 19, 2011 and reports indicate that the FDA received no small amount of feedback. We anxiously await the final guidance and will keep everyone posted.

Read more posts about legal and policy issues.

Project HealthDesign Comments on Nationwide Health Information Network Request for Information

Patricia Flatley Brennan, Ph.D., R.N., Project HealthDesign National Program Director

This comment was submitted to ONC in response to a request for information on the Nationwide Health Information Network: Conditions for Trusted Exchange (pdf). The comment period for this RFI is now closed.

As director of Project HealthDesign, a national program of Robert Wood Johnson Foundation’s Pioneer Portfolio, I respectfully submit these comments on the Nationwide Health Information Network: Conditions for Trusted Exchange Request for Information, issued May 15, 2012. Project HealthDesign is a national program of Robert Wood Johnson Foundation’s Pioneer Portfolio, and was established in 2006 to foster innovation in personal health technology. Since 2006, the program has involved 14 interdisciplinary teams that have worked with hundreds of patients and clinicians to develop and implement systems that allow patients to self-track information about their daily lives and health. We call this information, which ranges from data about an individual’s mood to insights about his or her energy or pain levels, observations of daily living (ODLs).

We applaud ONC’s efforts towards the governance of the Nationwide Health Information Network (NwHIN), and support the end goal of robust data exchange that is both safe and secure. Additionally, we are encouraged to see several conditions for trusted exchange (CTEs) that acknowledge the importance of patients’ roles as direct participants in health information exchange (e.g., S-3: allowing individuals a meaningful choice regarding whether their IIHI may be exchanged, S-8: allowing individuals to request a correction or annotation to individually identifiable health information (IIHI)).

Please consider the following comments on specific CTEs:

Condition S-3: An NVE must ensure that individuals are provided with a meaningful choice regarding whether their data may be exchanged by the NVE

We support this effort to engage individuals by allowing them to opt in or out of data exchange. This condition will also allow individual patients to see themselves as direct participants in the exchange process. However, caution should be taken to understand the individual health and public health consequences for opting in or out of data exchange. Trade-offs will need to be made in prudent ways.

            Question 28: Under what circumstances and in what manner should individual choice be             required for other electronic exchange purposes?

            We encourage you to consider whether it might be appropriate for individuals to opt in or out of             data exchange at a more granular level (e.g., opt in to all data exchange except the exchange             of data related to behavioral health). However, this approach would require a reliable system for             keeping track of individual’s granular preferences, as well as good privacy management             strategies that lay people are able to understand.

Condition S-6: An NVE must not use or disclose de-identified health information to which it has access for any commercial purpose.

We agree with this condition. We also recognize the importance of establishing a clear definition of what qualifies as a “commercial” purpose in order to avoid creating obstacles to the use of de-identified data for research and public health purposes.      

            Question 38: On what other entities would this have an effect?

            This provision would serve to increase not only providers’ trust in exchanging their data through             an NVE, but also patients’ trust in the exchange.

Condition S-8: If an NVE assembles or aggregates health information that results in a unique set of IIHI, then it must provide individuals with electronic access to their unique set of IIHI.

            Question 40: What further parameters, if any, should be placed on what constitutes a             “unique set of IIHI”?

            No additional parameters should be placed to qualify what constitutes a unique set of IIHI. Any             IIHI not accessible to individuals through a singular channel should be made available as             described.

Condition S-9: If an NVE assembles or aggregates health information which results in a unique set of IIHI, then it must provide individuals with the right to request a correction and/or annotation to this unique set of IIHI.

            Question 42: Are there any circumstances where an NVE should not be required to provide             individuals with the ability to correct their IIHI?

            No. Allowing individuals the ability to correct their IIHI when incorrect or incomplete (as             described in the HIPAA Privacy Rule) will help build patient trust in the data exchange process.             We also recommend using an audit trail to document when original data sources have been             modified.

Thank you for providing this opportunity to comment on the Request for Information. We appreciate ONC’s leadership in this area and look forward to a set of evolving CTEs that foster safety, security, and meaningful exchanges of data. For more information about our work, please contact me directly or visit projecthealthdesign.org.

Read more health policy comments from Project HealthDesign.

Chronology.MD: Lessons Learned and Next Steps

Kathleen Morrison, Chronology.MD Project Director, Healthy Communities Foundation; Linda Neuhauser, Chronology.MD Co-Principal Investigator, University of California, Berkeley; Deryk Van Brunt, Chronology.MD Co-Principal Investigator, Healthy Communities Foundation; Marcos Athanasoulis, Chronology.MD Chief Technology Officer, Healthy Communities Foundation

Crohn’s disease presents major treatment challenges for patients and clinicians to manage. The Chronology.MD project has developed an interactive mobile system in which patients with Crohn’s disease can input important observations of daily living (ODLs) such as symptoms, medication adherence, sleep, and activity, and share these data with clinicians during visits to enhance treatment decisions. In our last post, we reviewed preliminary data from patient responses to our online survey. We found that the vast majority of our patient participants liked our system and used it. We learned that patients had diverse views of the value of specific ODLs, and that age and sex may influence their views of what is personally relevant. For example, patients ages 40-50 were slightly more likely to track stress, while patients ages 20-30 were slightly more likely to track pain. Women reported that menstrual cycle information would have been an important ODL. Because our small cohort comprised only 30 patients, this information is not statistically significant, but it does help inform future research and practice.

We learned from patient interviews that each patient has a unique story of their illness, as well as unique priorities. Tracking ODLs often helped patient participants identify important factors (e.g., activity, sleep, stress, medications) that influence their symptoms and pain. Our use of contextual inquiry (focus groups, surveys, and interviews) allowed us a more comprehensive understanding of important ODLs and the factors that influence a patient’s use of a mobile device for ODL collection.

Clinician participants primarily saw the Chronology.MD system as an important patient app – a data collection and visualization system that helps patients focus and prepare for office visits. If patients are more focused, then the visit is more efficient and both patients and providers will be more satisfied with the encounter. Our clinician participants suggested that we incorporate the ODL data visualization graphs into the University of California San Francisco clinic’s Epic EHR system in real time. That way, the provider wouldn’t be overwhelmed by too much data in their EHR interface outside of the appointment. This way, providers would pull up the data at the time of the appointment, and the patients could discuss the ODLs that were most important since the last visit.

Because we developed our technology during the study and used iterative participatory design processes, we had a lot to do in a relatively short amount of time. Going forward, we know that our patients would like a single app for data collection and visualization, along with the ability to enter ODL data via SMS text message. We also learned that system bugs and crashes are a deterrent to utilization, and that a more comprehensive list of ODLs should be included. Our patients are committed to finding a way to continue using and improving the system, and many have reported that the use of the system is what keeps them healthier, more pain-free, and able to reduce the use of narcotic pain-killers.

Going forward, our clinicians would like to see this app add even more utility to the clinical visit. For example, incorporating data that address validated indices such as the CDAI (Crohn’s Disease Activity Index) and/or the Harvey-Bradshaw index (a simpler Crohn’s disease index), would permit providers to review these index scores with patients in real time and would allow patients to monitor their scores on a daily or weekly basis. Clinicians said that incorporating one or both of these indices would greatly enhance their ability to collaborate with patients.

In addition, our clinicians felt that this app could be used to equip patients with important information about Crohn’s disease – including where the disease occurs, the course of the disease, how to determine remission, the importance of medication adherence, the benefits of biologic vs. steroid drugs, and the importance of paying attention to general health maintenance (e.g., up-to-date vaccinations, pap-smears, and skin cancer screening). Ultimately, if this app could help better educate, inform, and prepare patients for office visits (including visits to other specialty providers not well-versed in Crohn’s disease) and if it could include more detailed information about medications, lab tests, scans (e.g., last colonoscopy, GI involvement), and symptoms to discuss, then providers would see it not only as an important patient app, but also as a very useful provider app. Clinicians told us that this app could  change the standard of care for Crohn’s.

We have learned from this pilot study that both clinicians and patients are interested in finding the balance between collecting and tracking data that is important to each group. Neither group wants to collect extraneous data, nor do they want to collect data for extended periods of time. The balance point between clinician and patient, and the ODLs that are personally relevant to patients, as well as clinically significant for providers, we call the ODL Prescription (ODL Rx). We are exploring support for future studies that will build on pilot study findings to create a technology that helps identify the ODL Rx for individual patients and satisfies the goals of both patients and providers to help manage this complex disease.

Learn more about the Chronology.MD project.
Read more posts from the Chronology.MD team.

ONC Announces “What’s in Your Health Record” Video Challenge

Libby Dowdall, Communications Coordinator, Project HealthDesign National Program Office

If you’ve ever requested or downloaded a copy of your health record, then you’re eligible to enter ONC’s latest video challenge. To enter, create a video that’s less than 2 minutes long to share how you accessed and reviewed your health record. This challenge is one of several recent ONC efforts to ensure that patients and their families know and understand their legal right to request copies of their health records from most health care providers. There are several ways to access these records, including via an online patient portal, through an online personal health record, by email, or in person.

Video entries should describe a specific example (personal story, experience, testimonial, or thoughtful idea) of getting access to view your health record and what you found in your health record or what you did with that information once you had it. Cash prizes are available for this challenge, and first prize is $3,000. Entries are due Aug. 20, 2012 at 5 p.m. EST.

Learn more about the “What’s in Your Health Record” video challenge.
Learn about your legal right to access copies of your health record.

Patient-Generated Data Governance: Fitting into the Clinical Setting

Dorothy Miller, J.D., M.P.H., Health Policy Project Assistant, Project HealthDesign National Program Office

This post is second in a series contemplating governance of patient-generated data in a clinical setting.

How can we encourage providers to integrate patient-generated data into their clinical decision-making? Providers need to feel confident that the patient-generated data they are accessing is trustable and authentic. Providers often have limited time to meet with patients and could see patient-generated data as an additional task to be completed, instead of a way in which patients can effectively communicate a richer picture of their day-to-day health.

Providers can think about patient-generated data fitting in with a traditional model of clinical decision-making in two ways. First, the data can be considered another means of understanding a patient’s description of their health. The model below (see Figure 1) shows the patient-generated data entering the clinical workflow as a type of information presented to the provider by the patient as they describe their condition.

Figure 1

A provider might traditionally ask a patient to describe their health status and expect an answer that describes the patient’s experience. With patient-generated data, the patient uses an alternate method to explain her health status and related experiences. A second way that patient-generated data can be integrated into clinical decision-making is for the provider to access patient-generated data as an external source of knowledge. The model (Figure 1) also shows the patient-generated data in that capacity, informing the provider as an external resource. Along with test results, medical history, and other types of information a provider consults, the provider may also access patient-generated data to provide additional information. 

Figure 1 demonstrates how patient-generated data can be integrated into the clinical setting. By understanding patient-generated data’s integration into clinical decision-making, we can create governance tools that integrate the principles emphasized in the previous blog post: data accuracy, integrity, and appropriate use. So what types of governance tools would encourage providers to take these steps in integrating patient-generated data at both levels? Providers should be encouraged to integrate patient-generated data into clinical workflows. Today, many patients interact with providers without the opportunity to discuss their patient-generated data. One solution to this challenge is clinical workflows that give patients opportunities to share their data. If the provider is worried about being overwhelmed with data that is voluminous or difficult to interpret, a clinic could provide standardized summaries accessible to providers, without compromising patients’ abilities to collect and generate data as they desire. 

Regarding laws and policies that govern patient-generated data, we need to thoughtfully and carefully balance provider concerns with the advantages patient-generated data can give patients and providers. Laws and regulations should be designed that give providers confidence in patient-generated data, both in terms of data accuracy and data integrity. When providers feel confident that the patient-generated data they receive is trustable, accurate, and reflects the patient’s day-to-day experiences, they may feel more confident in acting on that data. Clear guidelines allow patients to be comfortable with sharing their own data and may decrease providers’ concerns about liability stemming from using patient-generated data. 

If you’re wondering how provider liability fits into this picture, stay tuned. Our legal and policy advisory group at Manatt, Phelps & Phillips, LLC, and the Center for Democracy & Technology is working on a paper on this exact topic, and we will share more information about it soon.

---

Citation for Figure 1: Robert B. Elson et. al. The Practice of Informatics: Viewpoint: An Industrial Process View of Information Delivery to Support Clinical Decision Making: Implications for Systems Design and Process Measures J Am Med Inform Assoc 1997; 4:4 266-278 doi:10.1136/ jamia.1997.0040266.

 

Patient-Generated Data Governance Tools: Our Perspective

Dorothy Miller, J.D., M.P.H., Health Policy Project Assistant, Project HealthDesign National Program Office

This post is first in a series contemplating governance of patient-generated data in a clinical setting.

How does patient-generated data fit into the clinical setting? How do we encourage patients to engage in their own health care by enabling them to bring their own data into the clinical setting? And how can we reassure providers that their patients’ data can be treated as trustable and authentic sources of information for clinical decision-making? Understanding how to integrate patient-generated data into clinical decision-making focuses on three key principles:

• Integrity: Patient-generated data is trustable and authentic for both patients and providers.
• Accuracy: Providers are confident that the patient-generated data reflects the patient’s inputs.
• Appropriate use: Patients are confident that the data they generate is being used as intended.

Project HealthDesign’s five current teams have equipped more than 135 patients with chronic diseases to track, review and share their “observations of daily living,” or ODLs. These ODLs are patient-generated, patient-defined and patient-sourced, and can range from information about an individual’s pain or energy levels to truly unique observations about his or her moods. Each team has taken a different approach to the systems and technologies used to capture ODL data and share the resulting data and/or summaries with the patient’s clinicians. These new approaches also present new challenges as we think about how patient-generated data fits into the clinical experience. As a result of our work with ODLs, we’ve started to think critically about ODLs and other innovative types of patient-generated data.

We want patients to have the ability to bring the patient-generated data they value into a clinical setting. At the same time, we believe that governance tools for patient-generated data must be carefully and thoughtfully crafted.  Keeping in mind the three principles of integrity, accuracy, and appropriate use, we believe that policies and governance tools that recognize the unique nature of patient-generated data can be crafted. Stay tuned for the next post in this series, which deals with how patient-generated fits into the clinical workflow.