Launch HN: Enzyme (YC S17) – Automating FDA Compliance and Approval
We’re building software that helps life science companies with FDA approval and compliance. Think of something like TurboTax but for companies that are regulated by FDA. Our product reduces both the time and cost of taking a drug or medical device to market.
People often talk about how software is eating the world, but that process has taken longer for heavily regulated industries in part because of their complexity. However, there are now subject matter experts who grew up using and writing software and who have also spent enough time in their industries to be able to write useful software for them. This problem is very personal for my cofounder and me. We’ve both spent 11 years in the med device/biopharma industry and have personally felt the pain of how inefficient this is, having seen products we put our heart and soul into take months (sometimes years) longer than they should to reach patients and change lives.
We’re taking a labor-intensive, paper-based business process and replacing it with software that allows existing teams to perform much of the needed compliance work themselves, reducing the need to engage consultants or full-time compliance officers. Staying compliant is unfortunately very costly: small companies spend $100K+/yr on consulting fees, while larger companies spend $100M+/yr on FTEs and $10M+/yr on software packages that perform only a small part of the compliance workflow!
We’re focused on medical device/diagnostic/digital health companies for now, so if you’re a founder in this space we’d love to talk.
We can answer questions about regulatory/compliance strategy -- in the US, EU, and other geographies -- along with other aspects of medical product development (such as design controls, verification & validation strategies, risk management, user experience, etc).
There's some additional info on our TechCrunch launch announcement, here: https://techcrunch.com/2018/01/18/enzyme-io-wants-to-make-fd...
Thanks for reading and we welcome your feedback!
27 comments
[ 2.1 ms ] story [ 68.6 ms ] threadThere is a YC incorporation company that didn’t scale (not meant to be a dig), so curious about what’s different.
1) Compliance is an ongoing activity regardless of how many new products you release. Think something like HIPAA, but more pervasive. So there’s an ongoing need that is ordinarily fulfilled by people - everything from a consultant for a garage startup to 1,000s of FTEs for a Fortune 500 company. This creates an ongoing, sticky customer relationship for anyone who can deliver significant value.
2) Our product and approach is valuable to more than just startups and enterprise life science companies routinely spend $10M+/yr on software systems.
FDA has policy dynamicism which creates a moat.
Many foreign countries co-opt the FDA process as their own. That's how performant our FDA happens to be, despite criticisms from a lot of people in web tech.
If you are dealing with digital health products, what are your thoughts on the pre-cert pilot that is occurring right now? How significantly do you believe the changes will impact your process and infrastructure given minimal data about FDA timelines?
Registration and listing: harder to automate because information systems on FDA’s side aren’t quite there yet. For GUDID, yes
CAPA, labeling, submissions: yes
Alternative submission pathways: what do you mean by this precisely?
Pre-cert: I think the premise is correct, in that the current quality system regulations aren’t well suited to modern SW development practice. But the devil will be in the details. Regardless it won’t affect us significantly because whatever gets released will have to have a phase-in for existing process that we’ll be able to adapt to.
De novos, abbreviated 510(k)s, lesser used pathways.
> Pre-cert: I think the premise is correct, in that the current quality system regulations aren’t well suited to modern SW development practice. But the devil will be in the details. Regardless it won’t affect us significantly because whatever gets released will have to have a phase-in for existing process that we’ll be able to adapt to.
My general concern being in digital health is implementation timeline. 1 year timeline is different than 2 year timeline is different than 5 year etc. In my eyes it's really a question of how long FDA will be expecting traditional submissions while they roll out a model geared more around approval of companies vs products.
De novo’s definitely, abbreviated 510(k)’s as well (that’s more of a requirements -> standard conformance challenge which a system like ours is particularly suited to demonstrate), but to your point they’re not that common.
> In my eyes it's really a question of how long FDA will be expecting traditional submissions while they roll out a model geared more around approval of companies vs products.
Yes but in a certain sense for many digital health companies this is already true, because they’re 510(k) exempt and FDA’s oversight occurs retroactively via QMS auditing.
The near term challenge for digital health, until precert comes online, is that there are a limited number of software experts at FDA. To the Agency’s credit, they have recognized this and are trying to remedy it. But the big problem we see with software submissions is that things get overlooked, and in such a way that speaks to an overworked reviewers. This of course leads to delays, which is why it’s very important for software submissions to be buttoned up. This is one the things we’re tryijg to make happen with our QMS, which generates more reports that clearly map from requirement->code->test.
Yeah fair enough; it's true that there has been a large regulatory shift with the appearance of general wellness and enforcement discretion and the resulting erosion of class 1 and somewhat of class 2.
> The near term challenge for digital health, until precert comes online, is that there are a limited number of software experts at FDA. To the Agency’s credit, they have recognized this and are trying to remedy it. But the big problem we see with software submissions is that things get overlooked, and in such a way that speaks to an overworked reviewers. This of course leads to delays, which is why it’s very important for software submissions to be buttoned up. This is one the things we’re tryijg to make happen with our QMS, which generates more reports that clearly map from requirement->code->test.
I totally agree with this. If you could create a software submission which efficiently communicated traceability, verification and validation info, and the other key metrics the FDA wanted to see, that would be pretty huge in terms of submission turnaround time. Best of luck guys.
Thanks! Sounds like you’re pretty well-versed in this, if there’s some way you can help you with a future product please reach out!
And, yeah, FDA recently increased the range of condom sizes they would accept, thus enabling the kind of thing you’re proposing.
AFAIU, medical devices tend to require a lot of fuzzing and secured upgrades.
The Update Framework requires multiply-signed releases.
...
FDA > Digital Health > Cyber security: https://www.fda.gov/MedicalDevices/DigitalHealth/ucm373213.h...
""" Information for Healthcare Organizations about FDA's "Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software" """ https://www.fda.gov/RegulatoryInformation/Guidances/ucm07063...
It is exceedingly hard to find people w/ a decade's worth of biotech experience looking to move into viable software for the space.
Rooting you on from the sidelines mate!