Articles & Videos

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.

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

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 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.

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.

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

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

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.

This article provides suggestions on what cybersecurity documentation to include in a 510(k) submission for medical devices that only include a USB port.

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).

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 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.

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 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 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 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?

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.

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.

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.

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.

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.