Introduction

If you’re bringing new medical-device software to the United States market, then this guide is for you. We begin with best practices that are useful early in your journey. Then we provide succinct answers to questions we’re commonly asked by our clients. Finally, we list some detailed examples.

The focus is big-picture—costs, timelines, overall process, and project risks. Our answers target Software as a Medical Device (SaMD), although much will apply to devices generally.

If you have other questions, please ask using the chat button in the bottom right corner.

Thank you Jim Luker and Mary Vater for reviewing this article and providing feedback and additional insights.

Best Practices

Here are best-practices that we’ve observed by working with our clients over the years:

• Establish a regulatory strategy early. Once you can describe your device’s functionality and intended use, you should establish and document a regulatory strategy (see FAQs for more about this topic). This is especially true for SaMD, since software is, well “softer” than hardware and easier to modify, thus opening more strategic options than with hardware devices.
• If your product is SaMD, pick a regulatory team that knows software and cybersecurity. This is especially true if you plan to make significant changes to the software after the first release, or have flexibility with regards to what features are included in the initial release. SaMD is significantly different than hardware devices.
• Take regulatory risks that align with business needs. The FDA does its best to be consistent and predictable, but sometimes there are unavoidable regulatory risks. For example, if we feel our validation dataset is sufficient to make the device safe and effective, but we’re worried FDA will require more, then what do we do? The goal isn’t always to make a submission that flies past the FDA without any pushback (i.e., no requests for additional information); if it does, it may mean you went overboard with documentation or clinical-evidence gathering and lost valuable time getting your device to market.
• Raise enough money. Plan for the costs of clinical performance validation, non-clinical performance testing, software documentation, and cybersecurity. ****Not all devices need all of these, but if yours does, each by itself can add $100,000s of cost and months or years of delays to your projects. It’s best to identify them as early as possible in a regulatory strategy.
• Hire software engineers who have worked on medical devices before. If they haven’t, it will be difficult to write the documentation needed for regulatory submissions.
• Plan your cybersecurity controls early in the development process. FDA is ramping up it’s focus on cybersecurity. You will need to implement a security risk management process and a number of cybersecurity controls, and it’s easiest to do so if you plan for them instead of trying to insert them into the software after the fact.
• Don’t document too much before the design is settled. Most medical device startups set up their Design Controls (part of a Quality Management System) process too late, causing documentation busy work and engineering rework. On the other hand, it is also possible to begin documenting too much too early. Documenting your plan and high-level needs and risks early is valuable, but much of the lower-level documentation is best done later in the process when the design has settled and the chances of re-work are lower.

Device Classification

Who regulates medical devices in the US?

The Food and Drug Administration (FDA) is the primary regulatory body that oversees medical devices in the United States.

Can software be considered a medical “device”?