Regulatory Articles & Videos

A comprehensive guide to SaMD 510(k) submissions, featuring an unredacted 510(k) as a practical example to illustrate FDA submission requirements.

This article outlines the process of developing an AI/ML algorithm from scratch and getting it FDA cleared. It covers the four phases of the process (Explore, Develop, Validate, and Document) and discusses the costs, time, and data requirements involved. It also provides advice on regulatory strategy, data annotation, and algorithm prototyping. If you're interested in developing a medical device involving AI/ML.

This checklist is meant to assist in the review of a 510(k) submission. It is a version of the checklist we use internally at Innolitics when we’re reviewing 510(k) submissions for our clients. The checklist applies to any SaMD 510(k) submissions made for medical devices.

Medical device design begins with design inputs. The FDA says developing your design inputs is “the single most important design control activity,” yet writing good design inputs is difficult. This article presents Innolitics’ answers questions our clients frequently ask us about design inputs and analyzes a number of poorly written example requirements.

How to Write a Device Description for a 510(k)

An in-depth guide to navigating the use of off-the-shelf software (OTS) in the medical device industry. OTS software is general purpose software you didn’t develop yourself that you use in your device, e.g., open-source packages, cloud services, and operating systems. The article starts with the basics and then delves into more detailed issues, including strategies for documenting OTS software for the FDA.

Creating a shared glossary is easier said then done. In this article, I explore common pitfalls and propose solutions to creating a clear glossary that can speed up your submissions.

A short article that attempts to explain why badly made diagrams will confuse FDA reviewers and slow down your submissions. Includes links to the relevant guidance and a few best practices.

Need to write a user manual for a medical device? Not sure where to start? This article can give you a place to start

A Pre-Sub is a mechanism for requesting formal written feedback from the FDA, and (optionally) a one-hour meeting. This article provides best-practices and FAQs about pre-subs.

What is the difference between user needs and requirements?

Learn how to avoid invalidating your test dataset while still allowing yourself some flexibility to re-use the test data.

This article discusses engineering and regulatory factors to consider when deciding to rewrite or reuse existing prototype code. It should be useful to researchers or companies who are repurposing existing software into a medical-device.

This video discusses the potential avenues for getting generative AI applications cleared through FDA.

An overview of best practices and regulatory strategies related to digital therapeutics.

A comprehensive FAQ for people who are interested in creating a new medical device software to learn the basics about the US regulations.

An overview of best practices and regulatory strategies related to digital therapeutics.

If you’ve ever been working on a medical-device and have thought, “this is a waste of time,” this article is for you. It will provide a framework for understanding which activities are necessary and how to proceed if you believe one isn’t.

This article provides an overview of FDA’s webinar regarding a set of guidance documents that were recently released by FDA as a continued effort to modernize the 510(k) process. Specifically, this article focuses on the guidance documents applicable to SaMD: Best Practices for Selecting a Predicate Device to Support a Premarket Notification [510(k)] Submission and Recommendations for Use of Clinical Data in Premarket Notification [510(k)] Submissions.

This is a redline between the 2022 Draft cybersecurity guidance and the final 2023 cybersecurity guidance. It should be useful to medical-device regulatory professionals who want to see, in detail, what has changed since the draft guidance.

Medical-device software release frequency is a common question, particularly from software engineers familiar with agile development. The answer hinges on two key factors: whether the changes require regulatory submissions and the ability to produce all necessary design change documentation quickly.

The long-awaited FDA guidance on cybersecurity, touching both on regulatory submissions and quality system considerations.

This guidance document explains how medical device manufacturers can incorporate off-the-shelf software (OTS) into their devices, while still ensuring continued safe and effective performance. It provides a basic set of documentation necessary for all OTS software and a detailed discussion on additional needs and responsibilities of the manufacturer when the severity of hazards from OTS software failure increases.

This article provides a questionnaire for those looking to get their AI algorithm FDA cleared. It covers topics such as validation studies, non-ML and ML software items, and acceptance criteria for the device. Reading this article can help uncover gaps that may need to be addressed before FDA submission.

Describes all of the documents you need to include in 510(k) submissions for medical devices containing software functions. It’s the first big update since 2005 and removes the old “Level of Concern” concept and provides more details for some of the deliverables.

A distillation of the 27 page FDA guidance document ‘Multiple Function Device Products: Policy and Considerations’.

This guidance discusses the FDA’s Q-Submission program, which can be used to get feedback on your predicate device selection, performance study design, cybersecurity controls, or other aspects of your device. We often help our clients submit and run Q-Sub meetings.

FDA's Draft PCCP (Predetermined Change Control Plan) guidance should streamline model changes AI/ML-enabled devices, allowing for pre-approved modifications without the need for additional marketing submissions.

This webinar covers the four phases of the regulatory process: Explore, Develop, Validate, and Document. It also discusses the costs, time, and data requirements involved in the process. Additionally, it provides advice on regulatory strategy, data annotation, and algorithm prototyping.

We talk through a strategy for speeding up 510(k) submissions by using a letter to file for certain features that wouldn't trigger the need for another 510(k).

What is traceability? How does Notion help you handle it? How does Notion's flexibility empower medical device startups in ways that eQMS vendors can't.

The “Unresolved Anomalies” document is required for the FDA’s pre-market submissions. This article includes best practices, FAQs, and examples for writing this document.

A quick introduction to writing user needs and requirements for a medical device.

This FDA guidance document provides advice for making deficiency requests for medical device marketing applications in accordance with the Least Burdensome Provisions. It describes suggested formats for deficiencies and responses to facilitate an efficient review process. It also includes examples of well-constructed deficiencies and industry responses. The document is useful for medical device companies responding to requests for additional information.

This FDA guidance applies to AI/ML-enabled radiology software that assists in the detection of disease. Many of the principles and approaches, however, apply beyond this limited scope.

This guidance is describes FDA’s thoughts on evaluating the performance of CADe radiological devices. Designing standalone and clinical performance testing studies for AI/ML-enabled SaMD can be tricky. You want to do enough testing to ensure the device is safe and effective, yet you also need to avoid going bankrupt on the way!

The purpose of this guidance is to describe FDA’s regulatory approach to Clinical Decision Support software functions.

This FDA guidance document outlines the policy for medical device data systems, medical image storage devices, and medical image communications devices. It explains which software and hardware functions are considered devices and subject to FDA regulatory oversight, as well as which functions are exempt. Anyone creating a device in this space should read this document to better understand the regulatory landscape.

This document outlines the technical performance assessment required for premarket submissions of quantitative imaging devices to the FDA. It provides guidance on the evaluation of the safety and effectiveness of these devices, including the methodology for quantitative imaging and the appropriate use of imaging biomarkers. Medical device manufacturers may be interested in reading this document to ensure their products meet the required standards and to understand the regulatory expectations for premarket submissions.

Introduces standardized terms and definitions to foster a consistent understanding across the industry for ML-enabled devices.

This article contains a convenient transcript of the FDA's 2022 draft guidance on cybersecurity in medical devices. The article also provides general principles for medical device cybersecurity relevant to device manufacturers, including design for security, transparency, and submission documentation. At Innolitics, among other things, we specialize in cybersecurity-related services regarding medical device software such as whitebox penetration testing, cybersecurity risk management, remediation projects, and design controls, risk, and labeling documentation.

This FDA draft guidance document provides recommendations for the documentation that should be included in premarket submissions for device software functions. Innolitics has transcribed the draft guidance for easy access and use by clients. If you're overwhelmed by cybersecurity requirements for your SaMD, we can help with turn-key engineering solutions and regulatory consulting services.

The 21st Century Cures Act removed FDA’s regulatory oversite of certain types of “General Wellness” products. While this revision is a great opportunity for industry, it is also a cause of confusion and ambiguity. What products will the FDA consider to be “General Wellness” devices? It’s an important question! We’ve seen the FDA crush business ventures when they reclassify a General Wellness device to be a medical device. In this article, we will help you answer this question for your device.

This FDA guidance explains the regulatory approach and policy for multiple function device products, which are products that contain at least one device function and at least one “other function”. It clarifies when and how FDA intends to assess the impact of “other functions” that are not the subject of a premarket review on the safety and effectiveness of a device function that is subject to FDA review. The guidance provides principles, premarket review practices, and policies for FDA’s regulatory assessment of such products, and provides examples of the application of these policies.

This article provides an introduction to the US regulations that apply to medical software. To keep the article to the point, we omit some details that we feel are distracting and typically unimportant.

This guidance provides crucial information for developers and manufacturers on how the FDA classifies and regulates software functions and mobile apps in the healthcare sector. It outlines the criteria used to determine whether a software function or app is considered a medical device and, if so, the specific regulatory requirements it must meet. Individuals and companies involved in creating, distributing, or using health-related software and mobile applications should read this guidance to ensure compliance with FDA regulations and to understand the necessary steps for legally bringing their products to market.

This guidance document explains how medical device manufacturers can incorporate off-the-shelf software (OTS) into their devices, while still ensuring continued safe and effective performance. It provides a basic set of documentation necessary for all OTS software and a detailed discussion on additional needs and responsibilities of the manufacturer when the severity of hazards from OTS software failure increases.

When you’re developing a product that may be a medical device, one of the first questions to ask is: Is it a medical device? Usually this is a straightforward question to answer. One exception is general wellness products. This FDA Guidance discusses general wellness devices. If your product is a general wellness device, you’ll want to be certain the FDA will agree.

This guidance describes the abbreviated 510(k) program, which may be chosen when the device can be validated with FDA guidance document(s), demonstration of compliance with special controls for the device type, or voluntary consensus standard(s) for that device type.

This FDA guidance document provides a general framework for formatting and content of Traditional or Abbreviated 510(k) submissions. The document explains each section of a 510(k) submission and provides resources for information. It also describes the differences between Traditional and Abbreviated 510(k)s and the recommended format for each.

The FDA guidance on the least burdensome approach—the minimum amount of information necessary to adequately address a relevant regulatory question or issue through the most efficient manner at the right time.

This FDA guidance explains the relationship between standards and regulations and how to properly declare conformance to standards. It also covers how to handle changes in standards.

This FDA guidance provides context regarding device labeling. Labeling, which includes advertising, is important to consider early in the development of a new device.

A convenient transcription of the FDA's 2018 cybersecurity guidance for software engineers. It includes a list of suggested cybersecurity design controls to secure your device and a list of the cybersecurity documentation you need to include in your premarket submissions.

This FDA guidance document provides manufacturers of medical devices with information on when a new premarket notification (510(k)) is required for a software change to an existing device. By understanding the FDA's regulations on software changes, medical device manufacturers can ensure that their products are in compliance and avoid unnecessary delays in bringing their devices to market. This guidance is essential reading for any medical device manufacturer considering hiring Innolitics for software development and regulatory consulting services.

This FDA guidance outlines recommendations for managing cybersecurity vulnerabilities in medical devices, including a risk-based framework for assessing when changes to devices require reporting to the agency. Innolitics provides turn-key engineering solutions and regulatory consulting services to help with cybersecurity requirements for SaMD.

This document provides guidance for the FDA staff and medical device industry on how to navigate the benefit and risk factors when making product availability, compliance, and enforcement decisions. It offers insight into how the FDA prioritizes resources for compliance and enforcement efforts to maximize medical device quality and patient safety.

This FDA guidance document provides recommendations for medical device manufacturers to minimize potential use errors and resulting harm through the use of human factors and usability engineering processes. It is essential reading for those involved in the development of new medical devices.

This FDA guidance for industry and FDA staff about the current review practices for premarket notification (510(k)) submissions, and identifies, explains, and clarifies each of the critical decision points in the decision-making process FDA uses to determine substantial equivalence. It enhances the predictability, consistency, and transparency of the 510(k) program by describing in greater detail the regulatory framework, policies, and practices underlying FDA’s 510(k) review.

This FDA guidance document describes the types of communication that occur during the review of medical device submissions. It explains the four types of communication and provides details on Interactive Review. The document is useful for anyone involved in medical device submission or review, particularly for those interested in improving the review process.

The FDA guidance regarding Design Considerations for Pivotal Clinical Investigations for Medical Devices.

This document provides information on how device product codes are used in various FDA program areas to regulate and track medical devices regulated by the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER). It covers the use of classification product codes in premarket review, postmarket review, and more.

Provides essential recommendations for presenting results from studies evaluating diagnostic devices. It covers qualitative diagnostic tests' reporting in premarket approval and notification applications, emphasizing the importance of comparing new test outcomes to relevant benchmarks within the intended use population

This FDA guidance outlines general validation principles that are applicable to the validation of medical device software or the validation of software used to design, develop, or manufacture medical devices. Along with the design controls guidance, this is one of the big ones regulatory engineers should know about.

The big old FDA Design Controls guidance from 1997, transcribed into a linkable HTML document.