Real 510(k) Example

This document aggregates all the information you will submit to the FDA in a structured way. It also contains “?” that you can click that will provide you some guidance on how to fill out the information. The guidance can be quite vague and having an example will probably save you days to weeks. For instance, do you need to declare conformity to the DICOM standard? We did not. That just saved you thousands of dollars to get a DICOM conformance statement just for the FDA. Your customers may still want it anyway but you can always address the problem when it actually is a problem and you won’t have any customers without FDA clearance first.

This outlines the plan for developing and bringing the CT Cardiomegaly medical device to market. It covers the scope, definitions, references, procedures, project responsibilities, phases and deliverables, traceability plan, configuration management plan, archival, standards, methods, tools, integration and testing, algorithm development, software verification and validation, and problem resolution.

The first time I inherited such a document from scratch, it was 70 pages long and mostly contained fluff. There is a tendency to think that more is better. All that does is just overwhelm your team with complexity they did not know they have

This document describes how risk management is planned to be done. Several methods will be used to identify safety risks, including reviewing MAUDE alerts and the FDA Total Product Life Cycle database for related product codes, performing FMEAs, identifying usability risks, and evaluating safety-related device characteristics. Safety risk likelihood is classified into 5 qualitative levels from improbable to frequent. Severity is classified into 5 levels from negligible to catastrophic. Acceptability is determined using a risk matrix based on the likelihood and severity, with risks classified as acceptable, attempt to mitigate, or unacceptable

The first time I prepared a 510(k), seeing a concrete example of this would have probably saved my team 4 months full time engineering time wasted in over-doing it. Heck, even knowing an FDA approved risk management plan was only a total of 7 pages would have probably saved me a month.

The purpose of the architectural design chart is to provide a clear roadmap of the device design, showing the software items and layers, their relationships, data inputs/outputs and flow, and how users or external products interact with the system.

Seeing this architectural diagram would have been immensely helpful when I first started designing software medical devices. It provides a clear, visual representation of how to structure the software, segregate responsibilities, and ensure a modular, maintainable design. The diagram also highlights key considerations like data flow, external system interfaces, and the use of containerization for consistency and security. Having this example as a reference would have greatly accelerated my understanding of medical device software architecture and best practices.

When I first started working on the software requirements specification for a medical device, I was overwhelmed by the amount of detail and organization required.
This 8-page document effectively communicates the key requirements for the CT Cardiomegaly software, from the types of images it must handle to the algorithms it employs, the reporting capabilities, and even the user manual contents. It covers functional, performance, interface, security, and regulatory requirements in a concise manner. Seeing this example earlier in the process would have saved my team countless hours of overengineering and second-guessing. We would have had a clearer understanding of the level of detail required and the important aspects to focus on. Even just knowing that a software requirements specification for an FDA-approved device could be effectively communicated in 8 pages would have been a game-changer.

This 52-page document comprehensively covers potential hazardous situations, from compromised data quality due to various biases in the training data, to software design errors, compatibility issues, and even malicious system access. Each risk is systematically analyzed, including the sequence of events leading to the hazardous situation, the severity and likelihood of harm, and the resulting acceptability level.

If I had access to this example earlier, it would have provided a roadmap for conducting my own risk assessment. I would have had a better understanding of the breadth of risks to consider, the information to include for each risk, and how to structure the assessment for clarity and completeness.

In hindsight, a template like this would have saved us **6 months of effort** and given us confidence that we were conducting a thorough and compliant risk assessment. That peace of mind would have spared me 6 months of poor sleep while we were waiting for FDA review our file.

What goes into a user manual? Good question. There are a lot of examples online but I never understood how it all fit into the overall submission. Did you know that you can have requirements “implemented” in the user manual and verification tests that just check for the presence certain verbiage in the user manual? Having known this alone would have saved my team a cumulative of 8 months over the course of 5 years of writing and maintaining laborious automated tests that could have just as easily been a checkbox.

For instance, we had a requirement stating that the user should be informed about the device's contraindications. We wrote a complex test script to simulate various contraindicated scenarios and ensure that the software behaved accordingly. Had we known that we could satisfy this requirement by simply including a clear list of contraindications in the user manual, we could have saved weeks of development and testing time.

The Risk Management Report is a document that summarizes the risk management activities and conclusions for the CT Cardiomegaly software medical device. Its purpose is to document the device's safety-related characteristics, confirm that the overall residual risk is acceptable, ensure that appropriate methods are in place for collecting and reviewing production and post-production information, and verify that the Risk Management Plan has been properly implemented.

Foreseeable misuse scenarios are also addressed, such as using CT Cardiomegaly as the primary input for diagnosis, applying it to unsupported image types, or running it on unsupported devices like mobile platforms.

Finally, the report concludes that the overall residual risk for CT Cardiomegaly is acceptable, and the clinical benefits of the device outweigh the remaining risks.

In a previous position at a large medical device company, it took my team more effort to get through a single line item in the risk benefit analysis vs the time it took us to compile the entire risk management report. This probably would have saved us 2 FTE months in suboptimal committee meetings.

The substantial equivalence discussion focuses on several key areas, such as the devices' intended use, target population, technological characteristics, and performance testing. The document provides a detailed comparison table that outlines the specific characteristics of each device, such as the input, output, measurements, report structure, software requirements, and algorithm type.

Honestly I would not have saved a substantial amount of time on my first submission if I had this example because substantial equivalence is on every public 510(k) summary and I was working with an excellent consultant—who is working at Innolitics now by the way.

Did you know that if you filled this form out incorrectly the FDA can release all your documents to the public? If not, you might want to check out the example and make sure you fill out your form similarly.

This is already publicly available on the FDA’s site so I won’t dwell on it much longer. However, you will see the 510k summary had changed based on FDA feedback later in the process so you can ensure you don’t make a similar mistake we did. This probably would have saved a 60 minute conversation with FDA, which may seem small in the grand scheme of things, but is substantial considering how limited interactive conversational time you have with the FDA.

In the full example you’ll get the FDA’s redlines and related comments. This could give you some ideas on how the FDA will respond to similar verbiage in your application so you can fix these proactively instead of reactively.

This is a one pager pointing to the user manual. Some have made the mistake of duplicating the information here which makes it difficult to update the information if it exists in multiple different places.

Overall, the Device Description document provides a clear and detailed overview of the CT Cardiomegaly software, its intended use, and its role in assisting healthcare professionals in the detection and assessment of cardiomegaly and related conditions. The contents of this document are typically very similar to the section found in the 510k summary and other documents.

This is a relatively new section from the most recent software guidance. It supersedes the older “level of concern” questionnaire. It actually reduces the documentation burden for low to moderate risk devices. If you have a device that is a similar or lower risk than CT Cardiomegaly then you can be rest assured your device falls under the basic level of documentation.

This is a listing of all your software dependencies. Don’t overcomplicate it. Most software teams can generate a similar SBOM in just a couple of hours of work which could turn into weeks with poor guidance or lack of concrete examples.

The CT Cardiomegaly Software Description document is structured to provide a comprehensive overview of the software's features and functionality. It begins with the Purpose section, outlining the operationally significant features of the software. The Scope section specifies the software version to which the document applies. Following this, the Definitions section lists and explains key terms and abbreviations used throughout the document.

Software Operation describes the software operators, intended patient population, data-analysis methodology, and includes a high-level algorithm data flow diagram. The
Machine Learning Models section covers the slice localizer, heart segmentation, and inner chest segmentation models, including their architecture, training parameters, and hyperparameters.

Finally, Software Inputs and Outputs describes the inputs and their format, who provides the inputs, device interoperability, outputs and their format, performance testing, intended audience for outputs, data flow, network device interaction, and the use of cloud or network storage.

Each verification activity is broken down into detailed subsections:
Procedure: Steps to complete the test, with checkboxes for tracking progress.

Description: A brief overview of what the test entails.

Prerequisites: Requirements or conditions that must be met before the test can be performed.

Test Steps: Specific actions to be taken during the test.

Acceptance Criteria: Conditions that must be satisfied for the test to be considered successful.

Comments: Space for additional observations or notes.

I already wrote about how much time my team and I wasted the first time I tried to put together and execute a V&V plan. This document alone would have saved me months of FTE effort.

The CT Cardiomegaly Clinical Performance Assessment Protocol document validates the software's intended use by detailing the objectives, scope, definitions, and references. It describes the supported image acquisition devices, algorithm development plan, and data sampling methods. The document outlines inclusion/exclusion criteria, establishes reference standards, and details the measurements for evaluation. It specifies the clinical performance assessment plan, including primary and secondary endpoints, acceptance criteria, and sample size justification. The results section will compare the software's performance against human readers, focusing on key metrics like the Cardiothoracic Ratio and segmentation accuracy.

This document describes the results of the clinical performance assessment protocol. The protocol describes “how” to produce the report. Another common misconception is your device needs to meet all secondary performance metrics. In fact, the device did not meet all of its secondary metrics but passed all of its primary ones. You just need to justify why the device is still safe and effective, which is a better practice than changing our metrics to suit the output of the device.

Every FDA submission must have proof that you paid the FDA’s user fee. This document proves that. In fact, you can pay the MDUFMA fee well in advance of actually submitting the application. The price will only go up because of inflation so you may want to make a payment before the fee goes up on October 1 of almost each year.

About 3 months after the 510k is submitted, the FDA will send back a letter with a set of findings that you must address in 180 days. In this case, the primary concerns include the need for additional performance testing details, such as Bland-Altman plots and mean absolute error for accuracy assessment, histograms of Dice scores, and the inclusion of Hausdorff distance for segmentation evaluation. There are also requests for clarification on the reference standard, detailed workflow descriptions, and specific testing and validation methods. Additionally, the FDA did not buy our attempt to argue the software was not a “cyber device” so they requested more information on cybersecurity measures, software verification activities, and labeling updates to provide comprehensive user guidance and ensure regulatory compliance.

After you receive the AINN, you can request a meeting with the agency within 10 days. I highly recommend you do this because you can actually resolve quite a few deficiencies that were just due to misunderstandings or oversight. I common mistake is to assume the FDA is omniscient and has seen everything about your application. Assume they are human and humans can make mistakes, skim too fast, go down rabbit holes because of confirmation bias, etc. In this document you can see how we pushed back on FDA’s concerns and you can apply the same principles to your submission too.

We addressed all of FDA’s concerns within the 180 day period and sent back updates including the requested cybersecurity documentation. We knew about the cybersecurity documentation gap but figured we would try an experiment in the small chance that it would work and we can establish yet another way to streamline future FDA submissions—a strategy we have employed over the years.

The CT Cardiomegaly Cybersecurity Management Plan details managing cybersecurity risks throughout the software lifecycle. It covers monitoring and addressing vulnerabilities, creating a software bill of materials (SBOM), and providing updates. Using the STRIDE methodology, the plan includes threat modeling, risk verification, and monthly vulnerability reviews via GitHub’s Dependabot. Critical vulnerabilities are prioritized for resolution. User guidance includes recommended cybersecurity controls and prompt communication of significant risks. Validated software updates follow the P-0002 Development Procedure. The SBOM, in SPDX format, lists all software dependencies, ensuring comprehensive cybersecurity management.

The FDA requested additional analysis to be performed on the data so we performed the analysis and updated the report.

Congratulations! This almost certainly means you are close to the finish line. The FDA has determined that your application is close enough to clearance that they don’t need to put you on another hold. They are ok with letting their 90 day clock run instead of pushing the timer on to you. This means they will be quite demanding on your time though. They sent us emails on Friday with a response required by Monday several times during this process.