The impact of FDA's digital health Pre-Cert program has yet to be fully seen. There is much debate about the relative advantages of big vs small companies on the development side of the device/product equation. The classic view is that big has the resources and experience, but perhaps is over constrained and under motivated. Small has entrepreneurial zeal and fewer rules. I once heard that zeal turned into advice to job candidates that you shouldn’t express interest in any hobbies during your interview because they didn’t want people with distractions. Small may also have no income, but that is a separate matter. However, design/product development is only part of the challenge in medical devices.
Another challenge is regulatory compliance where big might have a great advantage. They probably have their own regulatory department, they have prior experience in FDA compliance generally and filings in particular. And an established company may have a good reputation at the FDA which can lead to smoother sailing, whether or not this is supposed to be the case. (Of course, they might also have a bad reputation leading to resistance and closer scrutiny at the FDA.) But however light or heavy the regulatory burden is, established companies are likely going to find it easier to carry that burden than smaller companies and start-ups. In this regard we might want to remember that the purpose of the burden is to protect the public through the reasonable assurance that the medical devices available to them are safe and effective. The purpose is not just to plague developers.
The Digital Health Precertification (Pre-Cert) Program is supposed to address the regulatory burden in the software arena by “looking first at the software developer and/or digital health technology developer, rather than primarily at the product”. This will involve “enabling companies to demonstrate their embedded culture of quality and organization (CQO) excellence”. In other words, companies with an established track record and certain internal systems in place will be advantaged over new companies with no track record and fledgling systems.
The premise of this program is that FDA’s traditional approach to medical devices is not well suited to software products. This reflects the software world’s self-promotion that software is fundamentally different, that it is and needs to be designed differently, and that frequent change and “upgrades” precludes the discipline of hardware Neanderthals. In other words, those in software are the cool kids and they can’t be bothered with requirements, design controls and documentation because that will stifle them. This is a new twist on the old stereotype that the software developers were the people you didn’t want to talk to. Here we can overlook that software has brought us hacks, data theft, bots, ransomware and meddling. But at least we don’t have to worry about privacy anymore because we no longer have any.
Notice of the Pre-Cert Program occurred in July, 2017, and a pilot program was launched thereafter. In September nine companies selected for the pilot were announced. This group includes some familiar names (Apple, Fitbit, Johnson & Johnson, Roche, Samsung) and others not so familiar. There was a two-day workshop in January to discuss the early days of the pilot. I’m just guessing, but I think Apple can probably put more resources into this arena then some of the companies I have not heard of. In this regard at least some of the companies will set a high standard for what the FDA can expect companies to do on their own. There was a public workshop on the pilot in January.
The Pre-Cert goals include enabling a modern and efficient regulatory framework that facilitates allows software iterations and changes, creating an easy to follow process, and ensuring high quality and safe and effective software by enabling companies to demonstrate their CQO. It is perhaps interesting that the goal of facilitating iterations and changes does not mention the original design. All companies would like to see facilitated changes and iterations, some of which are already in place in the form of PMA supplements, Special 510(k)s, “no 510(k) rationales", devices that FDA has chosen not to actively regulate, distinguishing enhancements from other design changes, and non-reviewed upgrades of certain kinds including those for cybersecurity.
CQO sounds like the FDA's Quality System (QS) revisited in that it carries the same assumption as the roll-out of the QSR, that process review can replace product review. In addition, ensuring safety is something that should be proven rather than just asserted. The idea of using post-market feedback (real world data) to do this basically means that we are going to let the public find out if the product is dangerous, probably without them knowing that they are participating in this process.
An interesting question here is whether a standalone software product that is in fact a medical device (Software as Medical Device, or SaMD), would come to market using a different path than a similar product not from a pre-certified company. Depending on the classification of the product the traditional paths are PMA, 510(k), De Novo, or no premarket restraint. Would a Pre-Cert product be similarly classified? If, for example, if it was Class II, would it just skip a 510(k) or would there be a streamlined 510(k)? Note that if the product isn’t a medical device, the FDA and its routes to market are moot.
The FDA has also said that only low risk devices can be expected to be in the Pre-Cert arena. This may make the Pre-Cert window rather small in that the product would have to a medical device but also be of low risk, and probably not Class I because Class I already sees minimal scrutiny. Low risk pretty much eliminates Class III, leaving a target area of the bottom risk end of Class II.
The FDA is not rushing to the endpoint, with the pilot scheduled to take all of 2018, and program iteration planned for 2019. Part of the FDA’s, and nominally the public's, assessment includes the attributes of a Minimally Viable Program. Think about the wording here, do you want to depend on medical software that is minimally viable?
UPDATE: More information on the Pre-Cert program from FDA.
On June 19th the FDA posted a 45 page update to its Working Model of the pre-cert program. In lieu of the user friendly 350 character URL, you can try http://tinyurl.com/ydaq2dh2.
An unusual feature of the update is that they actually marked where changes have been made, although there remains a significant question of, “Okay, but what does this really mean?”
The Digital Health Precertification Program strikes me as not much more than spin. Let’s say most digital health apps are Class I medical devices and a subset are Class II. With this Precertification Program, developers get “precertified,” effectively registering as a manufacturer with FDA and implementing the quality system. Then they can create their apps and sell them, just like any other manufacturer selling Class I devices. Higher risk apps will require premarket clearance.
Before the Precertification Program, digital health developers were up in arms about how FDA regulations would stymie innovation. Now that they have their own “special” program, they’re happy as clams.
We can’t buy a toilet at Home Depot that’s not designed and manufactured following ISO9001 (which is similar to the FDA’s quality system). I can’t see why digital health or any other healthcare IT should be any different. Besides, toilet manufacturers don’t follow ISO90001 because some regulator is making them, they have a quality system for the benefits they receive as a consequence of the higher quality of their products: lower manufacturing costs, lower warranty costs, greater customer satisfaction, etc.
In an industry that kills 400,000 of their own customers every year (just in the US), we should all be a bit more interested in improving quality in hopes of impacting patient safety.
One thing that remains unclear (of which there is probably alot) is how CQOE (culture of quality and organization excellence) differs from compliance with the QSR (quality systems regulations). If it is different, how is it different? If it is the same, why does it need a new name? If different then companies with multiple product lines would have some under QSR and some under CQOE. Is that an improvement? One difference between QSR and CQOE may be that a CQOE assessment might result in an overall “score”, perhaps by combining in some way some equally vague elements such as “Providing safe patient experience”, “Being clinically responsible”, Delivering highest product quality,””Being cybersecurity responsible” and Being proactive v/s reactive”. (from workshop: https://www.fda.gov/downloads/Training/CDRHLearn/UCM569275.pdf) This can lead to some fake math (as I have previously discussed in other contexts) wherein some elements appear to offset others. Note also that these elements have post-market attributes, which might mean that you have to have already marketed a product to show a high CQOE score. So can a one product start-up qualify here? But not to worry, this will all be resolved by the Pilot, won’t it?
Although not directly related to the pre-cert program Apple, who is a pre-cert participant, obtained marketing authorization under the DeNovo program for EKG software that will be part of the iWatch4 and which will use a sensor that is part of that product. In reviewing this application the FDA curiously announced that it looked only at the app and not at the sensor since the sensor was already part of a consumer general health product. Apple having the resources to play in this arena no doubt drove its ability to be successful.