Liberate the Data! Tidepool's docket comments on FDA MDDS Draft Guidance

On June 20, 2014, the FDA released Draft Guidance that would update the way they enforce Medical Data Display Systems, or MDDS.

The guidance also proposes changes to the already-adopted Mobile Medical Applications (MMA) guidance. Overall, this new guidance is a great step forward and we applaud the FDA for moving in this direction.

Here’s the even better news: The FDA wants us to help them make this guidance even better. They’ve asked for our feedback as a community, and the time is now. COMMENTS ARE DUE BY AUGUST 25, 2014. The more personalized your comments are, the better, but it’s most important that the FDA hear from as many of us as possible. The comments that Tidepool has submitted are below.

You may also want to check out the great comments drafted by the awesome folks over at Strip Safely.Here’s how you can comment on the MDDS draft guidance:

Copy the text below (just the indented part), or use the text from StripSafely or draft your own comments (you may wish to read Tips for Submitting Effective Comments

1. If possible, edit the text to reflect your own personal comments. Please note there is a 5000 character limit to your comments.
2. Click here to go to regulations.gov, then paste your comments in the comment box.
3. Fill out your information. You’re commenting as an individual so UNCHECK the box that says “I am submitting on behalf of a third party” .
4. Click the Category, “Individual Consumer”Click continue.
5. Review, check the confirmation box, Submit your comments. You’ll get a receipt to confirm your comments were posted.

Tidepool’s Comments on the MDDS Draft Guidance

We are supportive of this draft guidance and encourage the FDA to adopt it quickly for the benefit of all people with diabetes. In combination with the Mobile Medical Applications guidance, we applaud the FDA’s pragmatic approach towards digital health applications.Section I Introduction“... the FDA does not intend to enforce compliance with the regulatory controls that apply to MDDS devices ...”We encourage the FDA to clarify that this means “application developers who fall under the definition of MDDS/MMA do not need to register/file with the FDA nor submit pre-market approval applications.”Separating GENERATION of data from DISPLAY of dataWe encourage the FDA to continue to regulate the safety and efficacy of devices that GENERATE health data such as blood glucose meters and continuous blood glucose monitors.We believe that the STORAGE, TRANSFER and DISPLAY of data poses very little risk and that the FDA should allow the mobile, web and digital ecosystems to iterate quickly without regulatory enforcement. This will enable rapid innovation.We encourage the FDA to guide device makers to include provenance, authenticity and validity mechanisms for GENERATED data, for example through a CRC or digital hash. This allows downstream consumers of data to demonstrate authenticity and further reduce or eliminate the already small risk while data is in transit or being processed by software.Section II BackgroundRegarding “not intended to be used in connection with active patient monitoring”:We encourage the FDA to make a distinction between “active patient monitoring” in a hospital or clinical setting (with many devices, patients, and healthcare providers) and “real-time access to data from personal health devices by a consumer.”By way of example, here are two very different scenarios:1) Real-time, remote display of an EKG in a hospital setting.2) Continuous Glucose Monitor (CGM) data being monitored remotely by a parent or athlete on her smartwatch or smartphone.The former example of “active patient monitoring” clearly needs substantial safety and efficacy oversight to mitigate risks of multiple-patient dashboard displays and alarm fatigue. The latter example carries very little risk but substantial benefits and is used during normal, daily routines.The diabetes community has spoken loud and clear on this topic: the potential risks of real-time monitoring of diabetes data are far outweighed by the advantages of a flourishing digital health ecosystem with minimal regulatory oversight. Over 5000 people have joined the “CGM in the Cloud” Facebook Group since May, 2014. The risks that are mitigated by allowing real-time display of data, enabling early detection and avoidance of hypoglycemia events (such as the ability to monitor children while away from home) DRAMATICALLY outweigh the risks of not allowing it to happen rapidly with minimal regulatory enforcement.Regarding “Custom software that is written by entities other than the original medical device manufacturer”:We encourage the removal of the word “Custom.” “Custom” may imply that the guidance only applies to software written for a specific site’s custom situation. We believe the guidance should apply to all software that meets the other MDDS guidelines.Section III Policy for Medical Device Data SystemsRegarding “the FDA does not intend to enforce compliance with the regulatory controls, including registration and listing, premarket review, postmarket reporting and quality system regulation for manufacturers of these types of devices”:We encourage the FDA to clarify that this means applications that fall under the MDDS guidance would not be subject to filing, registration or listing, even for Class 1 General Controls.Proposed MMA ChangesRegarding the proposed edits to MMA V-A-1 “Mobile apps that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or for use in active patient monitoring or analyzing medical device data”:We propose that you replace the phrase after “or” with “or for use in active patient monitoring in a hospital or clinical setting or analyzing medical device data for the purpose of generating automated therapy changes or automated medical decision making.”We agree that applications that control the delivery of therapy should be regulated (at the same risk level as the device itself). However “active patient monitoring” should only apply to hospital/clinical settings, not to personal use or ancillary display of device data (as in the remote CGM example above), and especially not in “read only” scenarios.We agree that software that makes automated therapy recommendations or changes (e.g., automated insulin delivery) should be regulated. However, software that finds patterns in data, e.g. software that finds and presents patterns in blood glucose data (from BGM, CGM or insulin pump), should not be regulated as the risk is low.