Medical Device Software Resources

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.

This article provides an in-depth exploration of medical device cybersecurity requirements, including best practices and FAQs. It also includes examples and resources for those looking to implement or improve their own threat modeling processes.

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?

April Fools 2023 Joke: New FDA AI/ML Draft Guidance: Recommendations and Risk Assessment of Generative (AI/ML)-Enabled Quality Management and Premarket Submission Review

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.

Practical suggestions and tips for authoring SBOMs for medical devices and for using them to monitor for cybersecurity vulnerabilities.

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.

This article explains why regulatory consultants who understand software can save your engineers time and help get your medical device to market faster. It also provides tips for interviewing regulatory consultants.

This article outlines the challenges of bringing radiology AI/ML to market, from clinical workflow to IT installation. It provides insights and lessons learned for those interested in developing and deploying AI models in radiology.

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.

Learn from a real-world MedTech OS software bug and explore various debugging techniques that can help you navigate through software issues and find solutions effectively.

The IEC 62304 standard requires medical device manufacturers describes their software’s structure and identify the software items, but how granular should your items be?

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 video explains why code reviews are essential for growing a 10x software engineering team and how to do code reviews well.

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.

An example Socratic dialogue exploring various definitions of software maintenance and construction, agile, and the validity of the building/software analogy.

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.

This article explains why code reviews are essential for growing a 10x software engineering team. The first part of the article is theoretical, while the remainder uses this theory to make practical suggestions about using GitHub pull requests for code reviews.

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.

We describe the SKUASH debugging methodology for medical device software defect investigation and documentation. We’ve used this method for several years on client projects, including an industry leading medical-device company with hundreds of installations around the world.

The DICOM standard is complicated and different medical devices support it to different extents. A DICOM Conformance Statement is a detailed technical document accompanying most devices that outlines exactly which features of the standard are supported.

Innolitics’ DICOM Standard Browser helps users locate metadata in DICOM files. This article describes how Arjun Venkata, an intern at Innolitics, incorporated example values from DICOM files into the browser using a set of Python scripts.

Security vulnerabilities in medical devices can have devestating consequences. They can lead to patient injuries and in the worst cases, death. In our first public 10x talk, learn about common cybersecurity pitfalls and how they can be mitigated using modern software testing techniques used at scale by companies like Google and Facebook.

In our first public 10x talk, we explore how common cybersecurity pitfalls can be mitigated using fuzzing—a modern software testing technique used at scale by companies like Google and Facebook. The high-profile Heartbleed bug is used as an example of how fuzzing can be effective.

A brief homage to our friend and extraordinary developer, Willy Mills. He was the first engineer we brought on our team and we were fortunate to work with him for several years. We present some of the lessons and stories he has shared with us.

How can machine learning help us improve medical images for human viewers or image processors? This article describes one machine learning method (generative adversarial networks) that has been adopted by the medical imaging community to enhance medical images.

Want to know how we develop safe, effective, and FDA compliant machine learning algorithms? This article describes how we develop machine learning algorithms, points out common pitfalls, and makes documentation recommendations.

Completing a web form requires an investment of time and energy by the user. An accidental navigation can destroy this investment. This article implements a simple yet robust confirmation that is displayed before a destructive navigation occurs.

Should your medical application be built for the cloud, native, or a hybrid approach? In this article, we compare six deployment strategies and how each relates to HIPAA compliance.

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.

There are many approaches to choosing a medical imaging segmentation algorithm. In this article, we provide an overview of how to choose a neural network architecture for medical image segmentation.

Annotating medical images is time-consuming and expensive. In this article, we explain how self-supervised learning can stretch limited training data and compare it to transfer learning. We also explore three self-supervised learning medical imaging tasks.

The DICOM standard’s purpose is to facilitate interoperability between medical imaging systems from different vendors. The standard defines a file format for storing medical images, protocols so applications can exchange them, and a conformance format so buyers can determine which systems can (hopefully) interoperate. But perhaps most importantly, DICOM provides a standardized model of reality. This information model is the foundation on which interoperability is laid.

Available since 1995, the DICOM Toolkit (DCMTK) can be helpful to anyone working on systems that use the Digital Imaging and Communications in Medicine (DICOM) standard. This DCMTK introduction is of interest to those exploring DICOM for the first time, as well as those familiar with it but wanting to take a renewed look at the DICOM tools landscape.

Text-based chat eliminates a lot of the feedback available during in-person conversations. In this article, we suggest how to use Slack’s features to make up for some of this missing feedback. Tips also apply to other platforms.

Does your team struggle to communicate on conference calls? Do people seem distracted, or are they perpetually interrupting one another? In this article, we provide five suggestions extracted from what we have learned over the many years we’ve worked remotely.

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.

Make has been used extensively for forty years and offers incremental builds, parallelization, and a declarative syntax. In this post we’ll take a look at how the .DELETE_ON_ERROR special target helps eliminate possible downstream problems in your makefiles. You’ll also come to understand why most makefiles should include it.

Experienced radiologists can identify the anatomical location of an axial CT slice within a second. They may say the slice is “near the apex of the heart” or “at the C7 vertebrae.” These anatomical landmarks are difficult to describe or detect using manually created features, but neural networks excel at this sort of pattern recognition. Can we create a neural network capable of performing slice localization with similar speed and accuracy to a radiologist?

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.

If you followed along with our last post, we developed a deep-learning model that achieves our goal of identifying Simpsons characters in an image. However, as with all software development tasks, getting a working program is only half the battle. In order to maintain a program and fix bugs, the developer must understand the system– in particular, they must understand how it fails as well as how it succeeds. This can be quite a difficult task for deep-learning models, as they are black-boxes by nature of their construction. However, there are some techniques we have at our disposal to open up the black box and get a view into what is happening in our trained model; these can help us to find “bugs” in the model’s learning and even indicate how to resolve them. Among the many techniques to visualize the internals of a deep learning model, we will be focusing on the use of class activation maps.

Deep-learning models are ideal candidates for building image classification systems. In this article, we demonstrate how to leverage Keras and pre-trained image recognition models to create an image classifier that identifies different Simpsons characters.

This document details the necessary processes for assessing the safety, effectiveness, and performance of SAMD, including the stages of clinical evaluation, risk management, and validation. Developers, manufacturers, and regulatory professionals in the medical device industry should read this guidance to ensure their software meets FDA standards for clinical efficacy and patient safety, and to facilitate a smoother approval process.

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.

The FDA guidance discussing risks and documentation for pre-market submissions when devices must inter-operate with other devices (e.g., via DICOM or other standards).

Many medical applications run within a closed network. This arrangement can make investigating software bugs more difficult because the only readily available information is an (often vague and incomplete) recounting of the problem, a zip file filled with system and application logfiles, and the application source code.

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.

Refactoring a codebase means changing its internal structure without altering its observable behaviour. Refactoring is an essential tool for keeping an evolving codebase maintainable. This article is a commentary on a book chapter about refactoring code—Chapter 24 of Code Complete.

In this article, we explore how to extend async JavaScript functions using a functional design pattern—the decorator.

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.

In this post, we provide a set of exercises that should help you solidify your knowledge of BASH. Note that these are NOT introductory level questions, and they assume that you are starting with a working knowledge of Linux and BASH.

Poor code quality can be an extremely expensive problem to fix. This article describes what code quality is, why its important, and how to handle issues related to it.

Developers often don’t think about database connection pools until they are having connection problems. This article explains the purpose of connection pools, how they work, and how to tune them, while remaining agnostic to a particular implementation. It also discusses other types of object pools.

Picking the right programming language for a project can be an important business decision, and making the wrong choice is usually expensive. After reading this, you should have enough background to have an informed conversation with your development team.

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 how manufacturers should maintain the cybersecurity of medical devices that use off-the-shelf software. The guidance provides general principles for software maintenance actions and answers frequently asked questions. Manufacturers should use the guidance to ensure their cybersecurity maintenance activities comply with existing regulations.

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.