Yesterday, Pear Therapeutics announced the regulatory clearance of Somryst, its prescription digital therapeutic for chronic insomnia. And while the product is noteworthy for these patients and Pear's broader business, it also stands as a major milestone for the digital health industry – the first product to be evaluated throught the FDA's Digital Health Software Precertification Program.

Now years in the making, the agency's experimental program seeks to lower the burden that software makers face when releasing or iterating upon digital products through an upfront review of their internal processes. And while the FDA released an initial version of its Working Model some time ago, the industry now has a representative who can share, from beginning to end, what some of those extra processes might practically entail.

MobiHealthNews spoke with Pear's chief medical officer, Dr. Yuri Maricich, about his company's experience clearing a digital health software product through the experimental program: What kinds of qualifications the FDA sought, the unexpected surprises Pear faced, and which digital health companies might be interested in pursuing precertification once the program has been finalized.

The below Q&A has been edited for length and clarity.

Doing two regulatory processes at once – was that an exceptional burden? Did it put additional strain on Pear to jump through the normal hoops and then assist FDA with test driving the initiative?

It was definitely additional work, but I wouldn't describe it as burdensome. As a member of the Digital Health Pre-Cert Program, we signed up to help FDA test their Working Model, and I think, before getting too far down the discussion, I think it's important to note that while FDA is working to develop this program and pathway; it is not an open pathway, which I think is a misnomer that I have to remind our own people [of] as well as external companies. There's no FDA Pre-Cert pathway that someone can go to and apply, this rather was an exercise of us playing as a participant in the program. We were selected to help FDA test their Working Model.

But there was additional work. In addition to doing the whole traditional 510(k) pathway submission, we also submitted additional materials and documentation, and went through those processes of the Excellence Appraisal to help test the FDA Pre-Cert Working Model.

At a broad level, could you give an idea of what those extra submissions and work entailed?

Sure. First off was the Excellence Appraisal, and it was really interesting and a really positive experience for us. We've had standard FDA audits, because we're an FDA-regulated device manufacturer, and those come across as your traditional audits. We do our own internal audits that are all very quality focused.

[For the Excellence Appraisal] there was pre-work and post-work, where the FDA team came to our offices and evaluated what our software development processes were like. But it was much more expansive than a traditional audit, which is typically focused on if a company is adhering to the [Code of Federal Regulations Title 21] quality management systems that they've implemented.

The Excellence Appraisal was looking at what does it mean to do high-quality software development that impacts, is meant to address or treat human health. So there was an additional area where they focused not just the quality – they definitely focused on the quality side – but they also focused on clinical. And I'd say one of the areas they really got into was the level of clinical expertise for the specific products. We used Somryst as the main focus of our Excellence Appraisal, so they really spent time trying to understand what does good look like, what are thresholds we looked for in the development of this software.

And then they also looked at maybe two other areas. One is implementation – so, how do we implement those best software practices? How do we implement the therapeutic, whether in clinical studies or how it'll be implemented in the real world? And then lastly was what are our feedback mechanisms to help make our processes better, and ultimately the software quality, better from a safety and effectiveness [standpoint]? What I mean by that is they wanted to see what type of data we use to assess quality, and what types of data that we use for decision-making, and what are the feedback loops in the company so that we are a learning organization when it comes to best practice.

That's what made it broader. Yes, it was additional work, but I think it was really important additional work, because it's the kind of work that any company that wants to work in this field and manufacture therapeutics or healthcare products in this time should be focused on. And because it was one of the first ones, it was focused on assessing how Pear does that, but also focused on the FDA learning what types of processes, what types of thresholds of assessing quality and what kinds of feedback mechanisms exist out there that they should use as blueprints for the next phase of the program.

When FDA Pre-Cert does become locked in stone, would you anticipate that the processes and factors FDA was looking at for Somryst and Pear would be similar for another company?

You're asking me to speculate, so it's hard to know. But I would say that I would not be surprised if it is at least directionally similar. I think we probably did some additional things because they, the FDA, is trying to determine what does this look like when they expand it. There were probably some things we did that not every company will go through, and I think the FDA is also trying to right-size this for different types of companies, with different levels of products that have different risks and intended use. So they're trying to think about, we develop this framework that works for different types of products – a step tracker, for instance, is different than a prescription digital therapeutic.

But overall I thought it was a very positive experience, and what I was impressed with was that, typically when we interact with regulators, it tends to be the quality, the clinical and the regulatory people. And [our] engineers, [our] product-development people were really engaged, and it really resulted in a robust discussion, where I think we both learned from each other.

Even in the test group of nine companies, there's a pretty broad range of participants and company types. To be clear, you would suspect that the process might be fairly different for, say, a big tech company or a pharmaceutical company working on technology products, than it was for Pear, a smaller digital therapeutics-focused company?

Yeah, and I think that's the challenge. The FDA, why they're being so deliberate about this is to come up with a framework that can accommodate Samsung and Fitbit, and then Pear and Verily and Roche. That's a pretty broad expanse of products, right? And so, what is a Fitbit fitness tracker? What is the need there around what is quality software development and that process, versus what does Pear do and what does Roche do? Those should be right-sized around the level of risk around those products, and that's going to be a major learning [area]. But it takes time to figure out: how do you not miss something, while at the same time not submit[ting] one particular class of products or companies to things that aren't germane to their [business].

Interesting. With that in mind, does it seem like the Pre-Cert program as you have experienced it would be the type of program that everyone in this field – digital health, software health products – should be looking to enroll in when the opportunity comes?

Based on our experience and the way that it's been explained to us, this is probably most appropriate to organizations that are going to develop therapeutics, or software products of some kind that are intended to impact human health, and are going to have constant iterations. [They also would] want to adhere to very high levels of quality, but also want to make sure that there's a process for taking advantage of the speed and velocity of software improvement.

What I mean by that is ... the analogy of TSA Pre-Check. If you only fly once a year or once every other year, it may not make sense to get TSA Pre-Check. On the other hand, if you fly once a month or a couple times a month, it probably does make sense.

I think that's the vision with which the Precertification Program has been developed. If you're just going to submit one 510(k) or software program and you're not going to do anything [after that], I don't think it makes sense for that company. But if you're going to be coming back multiple times, if you have multiple products, if you want to find a way to adhere to high-quality software development standards that affect human health and show that's a priority for your company, then this is definitely something worth considering once it gets rolled out.

Throughout Pear's experience with the program and what was being asked of your company, can you think of something off the top of your head that particularly surprised you? Is there some kind of experience or takeaway you'd want to pass on to other companies as a heads-up?

I wouldn't say during the submission process that there was anything surprising. The submission process was basically the traditional 510(k) pathway, within the parallel pathway like the FDA Working Model is where they have a separate group that is blinded to the review in the Software Pre-Cert side. Then they looked at things and compared their determination seperately. There's a couple nice illustrations within the FDA Working Model 1.0 that show this graphically. And since we've already gone through the 510(k) pathway before, and the De Novo pathway before, I don't think there was anything there surprising.

I would say the one thing that was surprising, not in a bad way, but I mentioned it earlier, was just the excellence appraisal, where FDA seemed very focused on looking not just at quality systems. So, I think if a company was getting ready to go to an Excellence Appraisal and thought, 'Oh, we just need our quality people to show up; this is just an overview of our quality systems,' it was much broader than that. It was, writ large, what does high-quality software that impacts health look like? And how do we think about that not just from a quality systems perspective but from how do we think about that from a clinical perspective, from an organizational level around monitoring and refining our actual development process in an agile way to make the software better over time."

Yuri, is there anything else involving the Pre-Cert process, Pear's experience or otherwise, you would want to share with those looking on?

Maybe just one thing to underscore is that our experience was that FDA is definitely trying to come up with an approach that really can be accommodating or has a framework for really different product types. And that's challenging. But they also, while continuing to hold a really high bar around safety and clinical effectiveness, don't want to limit the innovation that software can bring. And so, I would just recommend people to really work with FDA to help accomplish both of those ends: How do we keep high standards? While at the same time, how do we enable the capabilities of software in a way where we can take advantage of them?