Who We Help
We help companies create and clear medical devices with the FDA. Are you asking yourself any of the following?
- Is my product a medical device?
- Will adding certain functionality make our product qualify as a medical device?
- What is the fastest way to get your device onto the market?
- What are the costs and timelines involved brining a medical device to market?
- Our team has experience with hardware devices, but we’re adding software or AI/ML features to our product line.
- Which features should we include in our device first? How will certain features affect the regulatory strategy?
- We sell our device in Europe already. How can we sell it in the US?
- Our product didn’t used to be a device, but the FDA is regulating it. What do we do?
How would it affect your business strategy if you could get reliable, straight-forward answers to these questions in a timely manner?
What if you could reduce your costs in half?
How much will it cost you if your current regulatory strategy fails? What if you need to re-run your clinical evaluation?
Software Experience Saves you Money
Regulatory teams can have varying levels of software experience:
- Suboptimal: Most experience is with hardware devices
- Good: Experience with software devices
- Best: Have software engineers
If you’re working on Software as a Medical Device (SaMD), or a device that contains software (SiMD), regulatory consultants who know about software will save your time:
- They can translate regulatory language into something the engineers understand, reducing pushback from the engineering team.
- They can assist in drafting documentation (see our guaranteed 510(k) software docs in 3 months) or provide concrete examples to guide the team.
- They can help adapt your existing automated software development processes to meet regulatory requirements more naturally, resulting in a more efficient process that will pay dividends well into the future.
- They know which documentation tasks are time-consuming and can help the team achieve the right balance between over-documentation and under-documentation.
Innolitics Regulatory Strategy
Innolitics staff has 20 years of experience providing regulatory strategy, design documentation, and submissions for Software as a Medical Device (SaMD) and Software in Medical Devices (SiMD). We can help you make the correct choices to obtain timely and cost-effective market access to the United States (we also provide support for entry into the EU, UK, and Canada).
(We also provide end-to-end medical-device development services, by the way.)
Innolitics shall be developing a regulatory-strategy document for Client to help them bring their first Software as a Medical Device (SaMD) product onto the US market. Here’s a brief description of our typical process:
- Understand Business Goals
- What are you trying to accomplish by bringing the SaMD to market?
- What markets do you want to sell it in and what is their relative importance?
- What marketing claims do you need to be able to make about the device’s performance to accomplish these business goals?
- How will the software be used (e.g., within the clinical workflow or directly by patients)?
- Draft a rough intended use statement for the device.
- If the device is a series of modules will each module have it’s own IU statement? Will there be an overall software ‘Platform’ which serves as the user interface and which may perform some functions (i.e., image viewer, report generation)?
- Understanding Software and Clinical Workflow
- What work has been done on the software?
- What do you hope to implement in the next year or two?
- What functionality is the highest risk?
- Develop Regulatory Strategy
- Determine the product code for the device
- Identify applicable FDA guidance and Standards
- Determine available market pathways (e.g., 510(k), De Novo, PMA)
- If a 510(k), identify possible predicate devices.
- Will the SaMD need clinical performance testing, and roughly what form this would take?
- Identify key regulatory risks and ensure they’re inline with the business goals.
- Plan pre-subs meetings with the FDA and how we’ll mitigate regulatory risks
- Determine any architectural design constraints that could reduce how much of the software is considered part of the device (per the 2020 Multiple Function Device Product FDA Guidance)
- If there will be multiple submissions (this is common for SaMD), what order should we complete them in?
The final deliverable is a regulatory strategy document, addressing the following items:
- Summary of business goals
- Key marketing claims
- Draft intended use statement(s)
- Possible pathways to US market (e.g., 510(k), De Novo, PMA, etc.)
- If a 510(k), possible predicates
- Key regulatory risks (i.e., issues that may prevent getting the SaMD to market, and how likely they are to occur)
- Software architectural recommendations related to “Other Function”s
- Software architectural recommendations related to cybersecurity
- Strategy related to future submissions (although the focus of the strategy will be on the first submission)
- If the device involves AI/ML, do we want to include a PCCP in the first submission?