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 undermotivated. 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?