#fdatransparency

Regulating software products

FDA regulates thousands of medical devices—everything from popsicle-stick tongue depressors to electrical brain implants. The swell of digital health is creating waves of new and complex software technologies, such as mobile medical applications. However, the FDA’s current regulatory process is not built to accommodate the fast-paced, iterative development that software products go through. Imagine if the weekly updates for the apps on your phone had to each go through the FDA approval process—app developers would be discouraged, and the FDA overwhelmed.

To avoid delays in getting new software products to patients while ensuring the application of the same standards of safety and effectiveness to all devices, FDA is developing a new regulatory approach that will first be tested on one type of software called software as a medical device, or SaMD. SaMD is software used for a medical purpose—to treat, diagnose, drive, or inform clinical management that operates independently of hardware. For example, the software internal to an infusion pump that controls the motors and the dispensing of medication is not SaMD because it is a part of and necessary for the pump to work. However, the software of a mobile app on a smartphone that analyzes images from an MRI to diagnose a patient is SaMD since that same software could also operate on your laptop.

General wellness apps are not SaMD since they are used to maintain or encourage a healthy lifestyle and not used to treat, diagnose, drive, or inform clinical management.

FDA launched the Digital Health Software Precertification (Pre-Cert) Pilot Program in mid-2017 and revised the model based on public feedback, with a second version, v0.2, released in June 2018. To ensure that patient perspectives inform the development of the program, on Nov. 27, 2018, FasterCures convened a small group of patient representatives to provide their perspectives on this pilot program to FDA staff. On January 7, 2019, FDA released a new working model 1.0, a test plan describing how FDA intends to iterate the model, and regulatory framework for conducting the pilot program.

About the Pre-Cert Program

The Pre-Cert Program evaluates software developers on whether they meet certain standards of quality and organizational excellence. Software developers are pre-certified if they demonstrate excellence in five principles: (1) product quality, (2) patient safety, (3) clinical responsibility, (4) cybersecurity responsibility, and (5) proactive culture. Pre-certified developers must also have a robust method for collecting and analyzing real-world data, and they must commit to monitoring these data to assure product safety and effectiveness.

Pre-certified developers can bring their SaMD products to market either without pre-market review or through a streamlined pre-market review. Which pathway a product takes depends on (1) the risk category of the product, (2) the level of pre-certification of the developer, and (3) whether the product is a new device or an iteration of an existing device. After entering the market, developers must follow the product’s real-world performance by tracking (and sharing with FDA): (1) real-world health analytics (e.g., clinical safety and health benefits), (2) user experience analytics (e.g., user satisfaction), and (3) product performance analytics (e.g., cybersecurity).

Comments from Patient Representatives

During FasterCures’ convening, patient representatives described their individual views on the pre-cert program; the meeting was not meant to elicit a consensus of views. Below is a selection of comments we heard during the discussion about elements of the Pre-Cert Program:

Excellence Certification Assessment:

Companies should be evaluated on their patient engagement efforts and should be encouraged to engage patients earlier in the development pathway for medical devices. FDA should include guidance for companies and patients on what specific actions meet the excellence standard for patient engagement.

The proposed organizational elements listed in Appendix B (of working model v0.2) to demonstrate excellence resonate but may be difficult for a lay audience to understand.

FDA should consider the disease state when creating measures to establish excellence. For example, for patients facing a decline in function, holding steady or even a small decline in function could be a benefit, so the measure should not require improvement.

Healthcare provider understanding of the product is important, especially for some diseases where the healthcare provider may be a user as well.

FDA should make it clear to patients and other users if only a part of a company is pre-certified or different parts of the company have different pre-certification ratings. The pre-certification could be related to each product to try to make this clear.

FDA should give guidance to developers on what the company can and can’t say about its pre-certification status (which might differ among products), to avoid the public assuming all products from a pre-certified company are pre-certified.

Excellence appraisal should include whether the company proactively engages with users to identify issues and how it reports (including to users), abets, and resolves product issues to them.

Real-World Data Monitoring:

User experience is important in assessing safety. System downtime and customer satisfaction are not the same things; clinical safety and accuracy are not the same things.

Patients want companies to reach out proactively to users regarding known issues.

Many device errors currently go unreported because of the burden of reporting on users, so companies should try to reduce the burden on patients to report errors. Companies should tailor error reporting for different patient populations (e.g., reflect any physical limitations of that population).

Patients expressed that cybersecurity is a top concern given that the correct performance of these devices and the protection of user privacy is very important.

Product performance is the most important of the three listed real-world data domains (the other two are user experience and real-world health).

FDA should develop monitoring requirements that are flexible enough to allow a product on the market (and stay on the market) even if it is only helpful to a subset of the patient population (i.e., it doesn’t meet the needs of all users).

 Transparency:

FDA should define transparency and encourage companies to share data with patients in a format they can use. FDA should also consider data access granted to healthcare providers and the complex webs of data flow between SaMD products and electronic health records.

Algorithmic transparency is important; patients should be able to know the inputs of an algorithm (in a way that does not compromise intellectual property protection).

Companies should tell users when they recognize inaccuracies or flaws in their products and that they are working to fix them. It is also important for companies to relay to users why they make changes to the product.

FDA should make sure that the description of its pre-certification approach and review process (on its website and other materials) should be easily located and described in lay terms for the public. The description should balance simplicity and depth: simple explanations and labels should build awareness for all consumers, while comprehensive information should be easily obtainable for consumers who want it.

How to Voice Your Opinion to FDA