Real 510(k) Example

A Simpler Way

A LinkedIn survey showed that most regulatory professionals would have saved 12 months off their 510(k) if they had an unredacted example.

Most respondents in a LinkedIn survey said an unredacted 510(k) example would have saved them 12 months off their first 510(k) submission.

What is Included?

Everything we submitted to FDA for K232613 including:

  • eSTAR application and attachments
  • Presubmission and interactions
  • FDA AINN letter and response
This is a AI/ML SaMD under the QIH product code built and FDA cleared by Innolitics. The project was funded by University of Alabama at Birmingham (UAB) and Body Check. Nvidia provided support, guidance, and support through the Inception program and MONAI.

Are you allowed to disclose that?

Body Check, the manufacturer, has granted Innolitics permission to share the contents of the FDA submission to help people just like you. Innolitics takes confidentiality very seriously and will never share such information without written permission and appropriate compensation. Body Check is being compensated appropriately for their generosity. Contact us if you are interested in doing the same.

eSTAR Application

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.

Clinical Performance Justification Form 3674

This may surprise you but this form was mostly blank even for a product like CT cardiomegaly which contained a clinical performance assessment. This probably saved you a day of investigation.

Product Development Plan (Software Development Environment Description)

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

Risk Management Plan

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.

System and Software Architecture Diagram

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.

Software Requirements Specification

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.

Risk Assessment

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.

User Manual

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.

Risk Management Report

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.

Substantial Equivalence Discussion

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.

Cover Letter

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.

510k Summary

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.

Software Label

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.

Device Description

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.

Documentation Level Evaluation

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.

Software Bill of Materials

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.

Software Description

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.

Verification Plan and Report

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.

Software Version History

Some people are afraid of just having one version in their initial FDA application. Well, we proved it can be done. This document was a one pager.

SOUP and OTS Report

Is your SOUP document shaping up to be hundreds of pages long? You are probably overdoing it. We got ours down to just 7.

Traceability Analysis

There is very little guidance on what this should actually look like. On my first submission I traced everything to everything, having multiple permutations of hazard to risk to risk control measure to requirement to verification etc only to be frustrated when the matrix did not fit on a landscape 8x11in paper that was needed to get it into a submittable format. The traceability analysis has the potential to be a enormous time sink. Ours’ was only 5 pages long and got cleared with no FDA pushback.

Unresolved Software Anomalies

There is a common misconception that software needs to be free of defects before FDA submission. It is not true because we had discovered a defect but decided labeling based mitigation was sufficient.

Clinical Performance Assessment Protocol

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.

Clinical Performance Assessment Report

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.

Truthful and Accuracy Statement

This is just a one pager attesting everything is truthful and accurate. It is extremely important to be completely truthful to the FDA about everything. Don’t overcomplicate this. A one pager is fine.

MDUFMA Cover Sheet

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.

Package Labeling Justification

Does not apply for software as a medical device. Just say “_____ is a Software as a Medical Device, and therefore, has no physical form that requires a package label.”

K232613 Additional Information AINN

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.

AINN Clarification Meeting Agenda

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.

AINN Sponsor Response

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.

Cybersecurity Management Plan

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.

Clinical Performance Assessment Report Rev C

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

Interactive Review

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.

FAQs

Is it really everything?

We redacted some sensitive numbers like Tax IDs but otherwise everything is there.

What if I am not satisfied?

In the unlikely event you did not get what you wanted, everything comes with a 14 day money back guarantee.

Won’t this be overly specific to the CT cardiomegaly device?

No. CT Cardiomegaly is the embodiment of 12 years of SaMD regulatory and engineering expertise. We use the same no B.S. methodologies on other applications, if we could share those other examples we would, however, it is understandably a sensitive subject.

I have a small team in a big company. Do I need to purchase a company wide license?

No. We just ask you only share to your immediate team members and don’t share with more than 25 people.

Can I share?

You may share amongst your company if you are less than 25 employees. If you have more than 25 employees, please contact us.

I am a regulatory consultant. Can I distribute this to my clients?

Your clients will need to purchase licenses separately. We can give offer you a commission. Please contact us.

Is there a free tier?

No. Innolitics does not own the IP and has licensed resale rights to the 510(k) documentation. The sponsor requested it not be given away for free.

Can you submit my 510(k)?
Why has this not been done before?

510(k)s are expensive and require a multidisciplinary team that typically only exist at for-profit companies that do not have an incentive to share. Innolitics, has the multidisciplinary team and a strong case to share

Will you have startup or open source pricing?

We will forward requests to the sponsor for approval. Please contact us explaining your situation. We will try to help.

Are there any limitations?

The terms of service will have a clause that prohibits creating a competing product. The sponsor has a patent to protect the technology.

Will there be updates?

We will periodically send updates on how to keep up with new FDA regulatory requirements.

What are you waiting for?

Save 12 months off your

  • 510(k) Submission
  • First clinical sale
  • Next funding round
  • Payroll expenses to ROI
  • “research only” label encumbrance


Let's Talk

Every great partnership starts with a conversation. Fill out the form below for a discovery call, and an Innolitics team member will contact you soon.