Medical-Device Software Regulations: Best Practices, FAQs, and Examples

 December 08, 2023


Introduction 🔗

If you’re bringing new medical-device software to the United States market, then this guide is for you. We begin with best practices that are useful early in your journey. Then we provide succinct answers to questions we’re commonly asked by our clients. Finally, we list some detailed examples.

The focus is big-picture—costs, timelines, overall process, and project risks. Our answers target Software as a Medical Device (SaMD), although much will apply to devices generally.

If you have other questions, please ask using the chat button in the bottom right corner.

Best Practices 🔗

Here are best-practices that we’ve observed by working with our clients over the years:

  • Establish a regulatory strategy early. Once you can describe your device’s functionality and intended use, you should establish and document a regulatory strategy (see FAQs for more about this topic). This is especially true for SaMD, since software is, well “softer” than hardware and easier to modify, thus opening more strategic options than with hardware devices.
  • If your product is SaMD, pick a regulatory team that knows software and cybersecurity. This is especially true if you plan to make significant changes to the software after the first release, or have flexibility with regards to what features are included in the initial release. SaMD is significantly different than hardware devices.
  • Take regulatory risks that align with business needs. The FDA does its best to be consistent and predictable, but sometimes there are unavoidable regulatory risks. For example, if we feel our validation dataset is sufficient to make the device safe and effective, but we’re worried FDA will require more, then what do we do? The goal isn’t always to make a submission that flies past the FDA without any pushback (i.e., no requests for additional information); if it does, it may mean you went overboard with documentation or clinical-evidence gathering and lost valuable time getting your device to market.
  • Raise enough money. Plan for the costs of clinical performance validation, non-clinical performance testing, software documentation, and cybersecurity. Not all devices need all of these, but if yours does, each by itself can add $100,000s of cost and months or years of delays to your projects. It’s best to identify them as early as possible in a regulatory strategy.
  • Hire software engineers who have worked on medical devices before. If they haven’t, it will be difficult to write the documentation needed for regulatory submissions.
  • Plan your cybersecurity controls early in the development process. FDA is ramping up it’s focus on cybersecurity. You will need to implement a security risk management process and a number of cybersecurity controls, and it’s easiest to do so if you plan for them instead of trying to insert them into the software after the fact.
  • Don’t document too much before the design is settled. Most medical device startups set up their Design Controls (part of a Quality Management System) process too late, causing documentation busy work and engineering rework. On the other hand, it is also possible to begin documenting too much too early. Documenting your plan and high-level needs and risks early is valuable, but much of the lower-level documentation is best done later in the process when the design has settled and the chances of re-work are lower.

Device Classification 🔗

Who regulates medical devices in the US? 🔗

The Food and Drug Administration (FDA) is the primary regulatory body that oversees medical devices in the United States.

Can software be considered a medical “device”? 🔗

Yes! The word “device” confuses people because in everyday language it implies a physical thing. In regulatory language, the term “device” includes software. Software-only devices are referred to as “Software as a Medical Device”, or SaMD. Software that is part of a medical device is called “Software in a Medical Device”, or SiMD.

The company that creates the software it’s “manufacturer”.

When is software considered a medical device? 🔗

Software that is “intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease” is considered a medical device. Some devices are considered “general wellness” devices and aren’t actively regulated.

Note that what makes a product a medical device is not just its technical capabilities, but also its intended use. The intended use is determined from it’s labeling, including the instructions for use and the marketing claims you make about the device (e.g., on your website).

Usually, it is clear if software is a device. If it’s not clear, FDA’s How to Determine if Your Product is a Medical Device page is a good starting place. If you’re still not sure, contact us or another regulatory consulting agency for help.

What regulatory controls do medical-device manufacturers need to follow? 🔗

In the United States, medical devices fall into three classes according to their risk level:

Class Risk Level Regulatory Controls
1 Lowest General Controls
2 Moderate General Controls and Special Controls
3 Highest General Controls and Premarket Approval (PMA)

All devices must follow general controls unless exempted by regulations. If a device is exempted from one of the general controls, such exemption is stated in the classification regulation for that device. Class II devices often will have special controls that apply to just that category of product. Class III devices must undergo Premarket Approval (PMA), the most rigorous market pathway.

How do you determine a device’s safety class? 🔗

The FDA classifies and tracks types of devices using three-letter product codes. E.g., "LLZ" is the product code for "Medical image management and processing systems.” (See the examples section below for many more.)

Each product code traces back to a Regulation Number. (Some regulation numbers may have many product codes, but some have a single product code.)

Once you’ve looked up a device’s product code, you can look up it’s regulation, and in turn its safety class and applicable special controls.

Note that some devices may have multiple product codes if there were multiple predicates.

A screenshot of the QIH product code within the FDA’s product code database (see the actual page here), showing the device class. In this case, it’s “Class II” and would thus require general controls and special controls. By looking at the 892.2050 regulation number, you can look up the relevant special controls.

How do you look up a device’s product code? 🔗

If you know of similar devices that are on the market, you may look up their product code in the FDA’s 510(k) database.

If you’re not aware of similar devices, you may also browse all of the product codes and their descriptions in our FDA database browser, which is a tool built off of the FDA’s product code database. Product codes are organized by review panel (e.g., Radiology, Cardiology, Pathology, etc.).

What if your device doesn’t have a product code? 🔗

If your low or medium risk device doesn’t fit well into any existing product codes, you may need to submit a De Novo Classification request. This is a somewhat more involved process than if you do have a product code. You can read more about it here. We can help with De Novo Classification requests.

FDA also has another method for determining the product code and regulatory requirements for a device that is novel or which does not fit well into existing product codes. This method is called a 513(g) Request for Information. With this type of request, you provide FDA with detailed information for your software and in return they provide a detailed document which includes the safety class as well as the regulatory requirements for the device. It is also possible that they will tell you that your software does not fit the definition of a medical device and therefore is not regulated in the United States at this time. 513(g) requests have an associated fee ($3264 for a small business). Unless you are really stuck, we suggest you use the other available free resources (i.e., FDA’s Web Site our FDA Browser) to determine the regulatory requirements for your software.

What are general controls? 🔗

Software devices in all three classes require you to follow these general controls before placing your device on the market in the United States. General controls include

  • Registering your organization with the FDA and list your devices (easy)
  • Avoiding misleading statements about your device’s efficacy, safety, or intended use, also known as “misbranding” (easy, but can make marketing difficult)
  • Setting up and maintaining a Quality Management System (time consuming)
  • Reporting deaths, serious injuries and malfunctions, etc. (hopefully you never have to do this, but procedurally, it’s easy to do)

There are a few additional controls that are more relevant for hardware devices.

Note also that 510(k) premarket notifications are technically a general control, however most class I devices are “exempt” from this general control. We’ll discuss 510(k) submissions later.

What are special controls? 🔗

Special controls are additional regulatory requirements for specific groups of class II devices. You can see some examples of special controls at the bottom of this article. Typical special controls include:

  • Performance standards
  • Postmarket surveillance
  • Patient registries
  • Special labeling requirements
  • Premarket data requirements
  • Guidelines

How do you look up the special controls that apply to a particular device? 🔗

Once you’ve identified the product code for your device, you can find what regulation number applies to it. When you open the regulation within the Code of Federal Regulations (CFR), you will see if there are any special controls for that device. Please note that there may be multiple product codes for a particular regulation number.

For example, the 892.2050 regulation has 11 product codes. When you open up the 892.2050 regulation you will see that the special controls are; voluntary standards - Digital Imaging and Communications in Medicine (DICOM) Std., Joint Photographic Experts Group (JPEG) Std., Society of Motion Picture and Television Engineers (SMPTE) Test Pattern).

You can also see the regulation text in our FDA database browser.

What is a premarket submission? 🔗

A premarket submission is a set of documents that you send to the FDA, which they use to evaluate whether your device is safe and effective prior to allowing you to market the device in the United States.

Class Risk Level Premarket Submission
1 Lowest risk Typically not needed
2 Moderate risk Typically a 510(k) or De Novo
3 Highest risk PMA

Most SaMD is Class 2. You can read about the difference between these premarket submissions in the later sections of this document.

Note that most Class 1 and some Class 2 devices are exempt from requiring a 510(k) submission.

What is a the difference between a 510(k) and a De Novo? 🔗

A 510(k) submission aims to show your device is substantially equivalent to an existing device, called the predicate device. Substantially equivalent means that your device and the predicate device(s) have the same intended use, and technological characteristics. Your device may have some differences relating to technological characteristics but they must not raise different questions regarding safety and/or effectiveness. At times, you may compare your device to more than one device (multiple predicates). A De Novo request is a request for FDA to classify your device, because you believe that there are no suitable predicates and that it is not Class 3 (highest risk).

Do I need to submit a 510(k)? 🔗

You typically need to make a 510(k) submission if all of the following are true:

  1. You want to sell your product in the United States.
  2. Your product is considered a medical device by the FDA.
  3. Your product is classified by the FDA as a non-exempt class 2 device. Rarely, a class 1 device may require a 510(k).
  4. Your product is “substantially equivalent” to an existing medical device (or devices).

This is somewhat oversimplified, and there are many exceptions to this process. To truly determine if you need a 510(k), we suggest having a regulatory consultant create a regulatory strategy for your product idea.

What is a regulatory strategy? 🔗

The specific content of a regulatory strategy can vary, but the fundamental questions we try to answer for our clients in a regulatory strategy are as follows:

  • Business goals (short term and long term)
  • Is it a medical device based on it’s device description and intended use?
  • How is it classified in particular jurisdictions (i.e., United States, EU)?
  • What are the available regulatory pathways (e.g., 510(k) or De Novo)?
  • What are the expected regulatory expenses and timelines for the selected regulatory pathway?
  • What clinical validation or performance testing will be necessary?
  • Should we engage with FDA in a pre-sub?
  • What are the largest regulatory risks?
  • If there’s flexibility, which software features should we include in our device first?
  • How will certain features affect the regulatory strategy?
  • What are the overall costs and timelines we can expect?

You can read more about our regulatory strategy service here.

When do I need to follow all of these controls? 🔗

Startups who are starting from nothing will interact with FDA following a timeline that looks like this:

An example timeline showing how startups interact with FDA.

Note that there are two “swim lanes”. The top swim lane is the premarket submission (usually a 510(k)). The bottom swim lane is the quality management system. The two swim lanes interact; many of the documents in the design history file will be part of the 510(k) but are also controlled documents in your QMS. Many startups don’t begin fully executing their QMS until they’ve received 510(k) clearance, however, it’s a good idea to begin implementing it sooner.

510(k) Premarket Notification 🔗

What is a 510(k)? 🔗

A 510(k) is the most widely used pathway for putting medium-risk medical-device software onto the US market. As previously mentioned, it involves showing that your device is substantially equivalent to an existing medical device that has been ‘cleared’ through the 510(k) or DeNovo pathway. This existing device is called the predicate device.

In a 510(k), you’re showing your device is like (equivalent) to previously cleared device and is thus as safe, secure and effective. In a De Novo request or a PMA, you’re showing that the device is safe, secure, and effective on its own merits.

What does substantial equivalence mean? 🔗

Substantial equivalence means that the new device is as safe, secure, and effective as the predicate device.

A device is substantially equivalent if, in comparison to a predicate, it

  • has the same intended use as the predicate, and it
  • has the same technological characteristics as the predicate.

Alternatively, if there are differing technological characteristics, substantial equivalence can be shown if it

  • has the same intended use as the predicate, and it
  • has different technological characteristics that do not raise different questions of safety and effectiveness, and
  • the information submitted to FDA demonstrates that the device is as safe and effective as the legally marketed device.

A claim of substantial equivalence does not mean the new and predicate devices need to be identical.

This can be visualized in the flow-chart from the FDA guidance (which absolutely should be consulted in detail when making these decisions—the flow chart is not intended to be used “stand-alone”.

High-level flow chart for deciding if two medical devices are substantially equivalent, taken from the 2014 FDA guidance. SE stands for “Substantially Equivalent,” which is good, and “NSE” stands for “Not Substantially Equivalent.”

As you can imagine, substantial equivalence is a bit of a gray area. Often, medical device startups have something new they want to bring to market, yet they also want to use the less burdensome 510(k) regulatory pathway. As a result, it is not uncommon to stretch the concept of substantial equivalence. If you’re doing this, you’ll want to think through the comparison carefully, since if FDA disagrees, they will reject your 510(k) and issue a ‘Not Substantially Equivalent (NSE) decision. If you receive and NSE determination, you may not market your device in the United States and will need to create and submit another 510(k).

What is the process for submitting a 510(k)? 🔗

At a very high level you need to:

  1. Creating a lot of documentation following a specific format
  2. Pay the submission fee
  3. Submit the documentation to FDA
  4. Wait (usually 60 days)
  5. Receive an additional information request from FDA
  6. Answer FDA’s request for additional information
  7. FDA decides if your device is “Substantially Equivalent” or “Not Substantially Equivalent”
  8. If the device is Substantially Equivalent, you can begin marketing the device.

You still need to fulfill the other general regulatory requirements, as spelled out in the “Post Market” section of this article. In general, it is a good idea to understand and begin preparing for the general controls while your 510(k) submission is under review.

What documentation goes into a 510(k)? 🔗

At a high level, the documentation in a 510(k) includes

  • The indications for use and intended use of your software
  • A detailed description of how your software is “substantially equivalent” to a previously cleared medical device software (also known as your “predicate device”)
  • A detailed description of how your software works (including architectural diagram(s))
  • A detailed description of your cybersecurity risks and controls
  • A detailed description of how your software can directly or indirectly harm patients
  • A detailed description of how you’ve mitigated these risks
  • A detailed description of how you’ve ensured your software works properly (verification and validation).

You then format the documents in a specific way that makes it easy for the FDA to review, send it to them, respond to their questions, and then hopefully get a letter stating that you can now sell your software in the US.

You may want to check out our Ultimate 510(k) Checklist to see a granular list of what goes into a 510(k) for SaMD devices.

It’s not uncommon for the submissions to run over 1,000 pages in length.

What do we do if there aren’t any existing medical devices like ours? 🔗

First of all, the concept of “substantial equivalence” can be tricky. Unless your device is truly unique it’s likely there are existing devices on the market that are similar. In some cases you can even have multiple predicate devices. That said, you don’t want to guess here. Many 510(k)s are rejected, and years of people’s lives wasted, along with millions of dollars, because the FDA disagrees with your assessment of what is equivalent.

If it is determined that there are no equivalent devices on the market in the United States, you will not be able to use the 510(k) pathway and will need to consider the other available options. As most software medical devices are class 2 (medium-risk), the De Novo request process may be applicable. A De Novo is similar to a 510(k) but the device must stand on its own in terms of safety, security and effectiveness. De Novo requests often require some level of clinical validation testing. If your software happens to be class 3 (high-risk), you will need to create and submit a PMA. This is the most stringent type of submission. We can help with all types of regulatory submissions.

How long does it take to put together a 510(k) Submission? 🔗

This is a complicated question and depends on several factors. A full regulatory strategy, as described in a previous question, would be able to provide a more nuanced answer.

You may want to check out our Ultimate 510(k) Checklist to see a very granular list of what goes into a 510(k).

Here are some general observations:

  • Software teams that haven’t put together documentation for a 510(k) can take 6 - 12 months writing all of the documents needed.
  • If you don’t plan ahead, clinical validation and performance testing can easily become bottle necks. In general, clinical validation and performance testing may take several months (or more) depending on the level of testing needed.
  • Cybersecurity work, including both necessary software updates and documentation, can easily add months to the timeline.
  • Putting together the bare minimum needed to submit is one thing, but if you miss key issues or documents, FDA will issue a hold letter and you’ll end up waiting anyway.

Once submitted, how long does it take to get clearance? 🔗

In theory, FDA has 90 calendar days to make a decision. However, if there are questions they need you to resolve, they’ll issue a hold letter. When FDA sends the request for additional information, their 90 day clock stops and your submission is placed on hold for up to 180 days. If you do not submit a formal response to FDA within the 180 days, FDA will delete your submission. The time it takes you to respond to a hold letter will further delay the submission. When you provide the response to the request for additional information, the 90 day FDA clock resumes. Also, while FDA tries to meet the 90 day review goal, they may not meet their goal.

You may want to look up how long it has taken for recent devices to be cleared within your device’s product code. This can give you some feeling for how long it may take you. You can use our FDA browser to look up this information. Keep in mind that even looking at recent devices isn’t always the best gauge of how long it will take, since it can also depend on the experience-level of the other submitters.

Also, keep in mind that FDA reviews tend to slow down during the holidays.

How much does it cost to submit a 510(k)? 🔗

The biggest cost to submitting a 510(k) is preparing the software documentation and/or running the performance or clinical studies necessary for the submission. These can easily cost into the $100,000s.

The FDA also charges a few fees.

  • Standard 510(k) Fee: $21,760
  • Small Business 510(k) Fee: $5,440
  • Annual Establishment Registration Fee: $7,653

These numbers are valid from October 1, 2023 through September 30, 2024. For the latest fees, please visit FDA’s Medical Device User Fee Amendments (MDUFA) website.

To get the Small Business 510(k) fee you’ll need to submit a Small Business Certification Request. Read here for more details about the process. We can also help with your small business application

What is the difference between a Traditional, Special, and Abbreviated 510(k)? 🔗

There are three types of 510(k) submissions:

  • Traditional
  • Special
  • Abbreviated

The Traditional 510(k) is almost always used for new SaMD devices. For modifications to previously cleared devices, the Special 510(k) is worth considering because it has a 30 day review goal rather than the 90 day goal for traditional and abbreviated 510(k)s.

The Abbreviated 510(k) pathway is less common. In 2022 there were only 48 Abbreviated 510(k)s that received clearance, as compared to 1000s of Traditional 510(k)s. Also, many of the Abbreviated 510(k)s were for latex gloves and other types of devices where there are clear performance standards that can be used for well-characterized devices. If your device is complex or relatively new, it’s unlikely an abbreviated 510(k) is appropriate. Furthermore, the FDA’s costs and review timelines are not shorter.

We sell our device in the EU already. Will that save us time on our 510(k)? 🔗

Yes. It will save a significant amount of time, since most of the software documentation you’ll have already. There are still significant differences and documentation between an EU Technical File and a 510(k) but it will get you about 60% there.

De Novo Requests 🔗

What is a De Novo request? 🔗

A De Novo request is a request to classify a low to medium risk (class 1 or 2) medical device that doesn’t have any suitable predicate devices on the market.

A lot of the software documentation required for a De Novo is similar to a 510(k), however, there are also many differences. You likely will also need clinical evidence. Traditional 510(k)s often do not require clinical evidence.

One benefit of doing a De Novo is you can suggest the special controls for the new product code that is created, which can (in certain cases) act as a competitive moat.

See this section of the regulations for more details.

How common are De Novo classifications? 🔗

They’re much less common than 510(k)s.

How different is a De Novo compared to a 510(k)? 🔗

While much of the information is the same (administrative information, device description), De Novos require the following information which is not required for a 510(k):

  • The classification being recommended under section 513 of the Federal Food, Drug, and Cosmetic Act (FD&C Act)
  • A complete discussion of why general controls or general and special controls provide reasonable assurance of the safety and effectiveness of the device, and what special controls, if proposing a class II designation, would allow the Agency to conclude there is reasonable assurance the device is safe and effective for its intended use
  • Clinical data (if applicable) that are relevant to support reasonable assurance of the safety and effectiveness of the device
  • A description of the probable benefits of the device when compared to the probable or anticipated risks when the device is used as intended

How long does it take to put together a De Novo Classification Request? 🔗

Due to the additional information and likely need to perform clinical testing, it may easily take more than 12 months. Additionally, if you think that the De Novo pathway is applicable for your software device, we strongly suggest to have a presubmission meeting with FDA.

Clinical Investigations 🔗

What is a clinical investigation? 🔗

A clinical investigation is a broad term that refers to medical research studies involving people. It can have specific meanings in particular regulatory contexts. Generally it is used interchangeably with the term “clinical study”. Some medical devices require clinical studies to assess the performance of the device in a clinical setting.

Note that the term “clinical investigation” is the one that’s most often used in the regulations, however, because “clinical study” is shorter and more widely used, it is the term we typically use.

What is a clinical trial? 🔗

The terms clinical study, clinical investigation, and clinical trial are sometimes used interchangeably, but there’s a useful distinction to be made.

In most contexts, a clinical trial is a type of clinical study that

  1. involves human participants
  2. prospectively assigns participants to an intervention
  3. is designed to evaluate the effect of the intervention on the participants
  4. is evaluating a health-related biomedical or behavioral outcome.

Clinical trials are the primary way that researchers determine if a new form of treatment or prevention, such as a new drug, diet, or medical device (for example, a pacemaker), is safe and effective in people.

Unless exempted, clinical trials require the sponsor to submit an Investigational Device Exemption (IDE) application to FDA before initiating the trial. FDA will review the Institutional Review Board (IRB) approved study protocol and approve or deny the application.

Do all medical devices require a clinical studies or trials? 🔗

No. Most class 1 and many class 2 devices do not require clinical studies. According to FDA’s 2014 guidance, which is of course out-dated, “FDA requests clinical data for less than 10 percent of 510(k) submissions.”

Some class 2 devices do require clinical studies. For example, Computer Aided Diagnostic devices, “CADe”, typically require a type of clinical investigation called a Multi-Reader Multi-Case (MRMC) study wherein readers try to diagnose a number of cases with and without the assistance of the CADe device being studied. This is not a clinical trial, but it is a clinical study.

Many digital therapeutic devices (see here for our article on this topic) require clinical trials.

It is likely that a De Novo request would include some degree of clinical information.

Non Compliance 🔗

How would FDA identify regulatory violations? 🔗

FDA has a few mechanisms of identifying regulatory violations.

If you are marketing a product that FDA believes is a medical device, yet you haven’t registered with FDA or completed the appropriate premarket submissions, then FDA will contact you. FDA may see marketing claims on your website, or other sales and marketing materials. Also, competitors can report allegations of regulatory misconduct on this website.

The form that FDA uses to contact you varies but may include informal phone calls, untitled letters and warning letters. Warning letters are placed on a public-facing FDA website and are sometimes used by your competition to dissuade potential customers from purchasing your device.

How often does FDA inspect medical device manufacturers? 🔗

Once you register with FDA and list your products they will periodically inspect you. Class 2 and 3 devices are inspected every two years or according to audit staff availability. FDA will also occasionally audit establishments who market class 1 devices (albeit less frequently than class 2 and 3 establishments).

What happens if FDA finds problems during the inspection? 🔗

FDA will issue an FDA Form 483 at the conclusion of an inspection if investigator(s) have observed anything they believe to be a violation. Often, the manufacturer is given an opportunity to correct the identified problems.

Depending on the severity and nature of the findings, FDA may also do any of the following:

  1. Issue a public warning letter
  2. Issue product recalls
  3. Seize products
  4. Issue court orders to stop certain activities
  5. Initiate criminal prosecutions

What happens if we sell a product but FDA believes it is a device? 🔗

Once it comes to FDA’s attention that you’re marketing a medical device without having followed the appropriate regulatory controls, such as a 510(k), FDA would notify you of the objectionable activities. They’d typically require that you stop marketing the device. If the device is already in use, you likely would need to issue a recall and pull the device off the market. Finally, you’d have to comply with all of the regulatory controls for your device type before placing your device on the market again.

Clearly this would be a big problem, because you may lose most (or all) of your customers, your reputation would be ruined, and you’d have to complete a lot of regulatory work before you could resume marketing your device.

See the section below for examples.

What happens if we add new features to our 510(k) cleared software which change the intended use or classification but don’t submit a new 510(k)? 🔗

The next steps would be similar to the question above: FDA would notify you of the objectionable activities which may include pulling your device off the market (recall) or roll back the software version to the cleared version.

What if we make marketing or performance claims about our device which FDA believes are unsubstantiated? 🔗

In the case where you’re making marketing claims about your device which you can’t support with evidence, then FDA may notify you that you need to change the marketing material inline with your cleared intended use.

When developing a regulatory strategy, it’s important to consider the regulatory claims you’d like to be able to make. Often we suggest declaring the most important ones to FDA to de-risk their use and to ensure FDA agrees they’re substantiated by the evidence.

Regulatory Help 🔗

I’ve never submitted a 510(k) before. How do I get help? 🔗

You should probably hire a regulatory affairs consultant. Consultants can be expensive, but figuring out how to do everything on your own will likely cost even more, and mistakes can be time-consuming to correct.

What do regulatory affairs (RA) consultants do? 🔗

  • Classification and Jurisdiction: Analyze a software function to determine if FDA, or other regulatory bodies, would consider it a medical device.
  • Strategy: Put together a strategy for bringing a medical device onto the market in a way that maximally achieves the business goals (see previous questions about this).
  • Gap Assessments: Compare devices and documentation against applicable regulations and standards to see if anything is missing.
  • Prepare Submissions: Guide the team as they write documentation for regulatory submissions, and may write portions of the submissions.
  • Regulatory Communication: Interfaces with regulatory agencies on your behalf.
  • Quality Systems: Set up and maintain your quality system.

How do we find good regulatory consultants? 🔗

Innolitics is a great choice for Software as a Medical Device (SaMD) products. We offer several services, including our “Fast 510(k)” service for companies who have relatively little documentation, but nearly finished software and who are in a hurry. Our “Guided 510(k)” is a good fit for companies earlier in the process who would like guidance on regulatory strategy and putting together the submission.

Here are some other groups we can recommend:

  • MDC Associates is a great group for In-Vitro Diagnostic Devices.
  • MCRA is another group that has deep experience and many ex-FDA reviewers on their team.
  • Medical Device Academy is an affordable group with fixed-fee pricing that has a focus on training.
  • Lean RAQA is an affordable group who do great quality work.

You may also want to look through the FDA’s database to see who has submitted 510(k)s in your product code or similar product codes.

Is it a good idea to hire someone internally to handle both regulatory affairs and quality systems for your company? 🔗

  • We recommend to distinguish between regulatory affairs and quality systems.
    • Regulatory tends to be more involved early in the process as you classify your device, come up with a regulatory strategy, and then make your premarket submission (e.g., a 510(k), De Novo).
    • Quality systems often starts coming into play a little later, but once your device is on the market, the volume of work for them tends to be steadier. As mentioned previously, we recommend starting work on your Quality Management System (QMS) after you have submitted your 510(k) and you are waiting for the review. In some cases, it makes sense to outsource most of your quality systems activities. We know a few groups we could recommend.
    • Sometimes people try to combine the roles, however, we don’t suggest doing this as its often more expensive to find someone sufficiently qualified to handle both areas.
  • Generally, once your device is on the market, the quality systems work tends to increase in volume more quickly than regulatory work, so we’ve found that it can make sense to either hire a full-time quality systems person or potentially outsource most of the quality work to a consultant.

Is it better to hire a full-time regulatory affairs person, or a consultant? 🔗

For most small or medium-sized companies who are making few regulatory submissions, it will be more cost effective to hire a consultant. As is always the case when working with consultants, there are downsides like limited availability, yet it will be difficult and expensive to hire a full-time person with the level of experience you’ll want as a full-time staff.

Also, your needs for a regulatory consultant will vary throughout the project life-cycle. Typically, you will need help early on when developing a regulatory strategy. Then there will be a long lull as the development is completed. Then you will need help with performance studies, making the regulatory submission, and responding to hold letters. Thus, it can save significant costs by using a consultant who you’re not paying during the long lull during development.

Is it feasible to develop a regulatory strategy by yourself? 🔗

We occasionally see early stage founders trying to develop a regulatory strategy on their own. We wouldn’t say it’s impossible, but it’s a risky approach. It’s easy to misinterpret the FDA guidance and regulations, and small misinterpretations can lead to large consequences. For example, if you believe you’re a class 1device when you’re actually class 2, you’ll be in trouble when FDA comes knocking. Or, if you think your predicate can be device A, but FDA thinks it should be device B and furthermore you need additional clinical testing and evidence.

How do you pick a regulatory consultants to work with to help you submit a 510(k)? 🔗

You want a firm that has relevant and recent experience. In particular, you’d like a firm who has submitted a number of 510(k)s for devices somewhat similar to yours.

In the least, if your device is SaMD, then you want to work with a firm that has submitted SaMD before. SaMD is very different than hardware-only devices and is also somewhat different from software and hardware devices too.

You’ll want to understand how busy the consultants are, and how many other clients they may be working with at the same time.

You’ll want to know if they’ll be able to help you to produce the documentation.

Why do different firms have such different prices? 🔗

The scope of service provided can vary a lot, and along with this variance, there is a large variance in cost. Thus, when comparing quotes from different firms, be sure you understand what is in scope or out of scope.

For example, we can just provide companies high-level guidance and templates, or we can help write most of the documentation for you. There is more than an order-of-magnitude difference between these services and their associated costs.

Engineering Help 🔗

Can we out-source our medical-device software development? 🔗

Yes, although you—the medical-device manufacturer—are legally responsible for their work. You’ll still need a Quality Management System (QMS), and as part of that QMS, you’ll need to have a purchasing process (section 820.50 of FDA Quality System Regulation, section 7.4.1, 7.4.2, and 7.4.3 of ISO 13485) where you keep records of the criteria and used to evaluate and select suppliers.

You’ll also still need to provide software validation documentation to FDA as part of your submission. Thus, you’ll want to be sure the software development team that produced the software will also be able to provide all of the necessary documents. Typically these details are arranged as part of a quality agreement.

What is a quality agreement? 🔗

A quality agreement is a signed document that states what parts of the Quality System regulation will be fulfilled by the software development firm (i.e., the supplier) and you the manufacturer.

How should we evaluate our software developers? 🔗

Since the software developers will need to provide documentation for your regulatory submissions, you’ll want to know they’ve done this before. You can ask them questions such as the following:

  • What software documentation will you provide along with the source code? (Then cross check what they tell you with the 2023 software guidance.)
  • Do you have a quality management system? Is it certified against ISO 13485?
  • Do your software development processes comply with IEC 62304?
  • Will you provide cybersecurity documentation? Does your security risk management comply with AAMI TIR 57 or ANSI/A AMI SW96:2023?

Is it reasonable to expect our software developers to provide the necessary regulatory documentation? 🔗

If it was part of what you agreed to up front, it would be reasonable. If you hired a software development firm that doesn’t work on medical devices, they won’t know what regulatory documentation they would be expected to provide. Not only that, it will be difficult for them to provide good documentation and it would be more than would typically be expected from an out-sourced development firm. For example, part of the software documentation is the software risk management assessment. This document requires input from clinical specialists who know how the device will be used in the clinic. A general purpose software engineering firm won’t be able to help with this.

Post Market 🔗

What do we have to do once we’ve gotten regulatory clearance? 🔗

NOTE: This response is incomplete and will be updated in a future revision.

Once you’ve gotten regulatory clearance for your SaMD product, you still need to:

  1. Obtain and maintain your annual Establishment Registration
  2. List your device(s)
  3. Implement and maintain your Quality Management System (QMS) processes, including:
    1. Design Control/Design History Files
    2. Management Review
    3. Device History Record
    4. Device Master Record
    5. Document Controls
    6. Purchasing Control
    7. Internal QMS Audit
    8. Collect Feedback from Customers
    9. Complaint Files
    10. Document, Investigate, and Report Safety Incidents
    11. Corrective and Preventative Action (CAPA)
  4. Document changes to your software and assess regulatory impact
  5. Be prepared for FDA Audits of your QMS
  6. Run Postmarket Cybersecurity Processes
    1. Periodic Penetration Tests
    2. Periodic Vulnerability Scans
    3. Assess, Remediate and Report Vulnerabilities
  7. Postmarket Surveillance
  8. Produce Unique Device Identifiers for New Versions
  9. Review marketing materials and Web site to assure alignment with clearance

What is Establishment Registration? 🔗

Companies that produce and sell medical devices in the U.S. must register annually with the FDA. This process is known as establishment registration. There’s an annual fee. In 2024, it’s $7,653 for businesses of all sizes.

You can read more about the process on the FDA website.

How do Unique Device Identifiers work for SaMD? 🔗

FDA requires manufacturers to assign a unique device identifier (UDI) to each device. Each build of the software must have a new UDI. UDIs must be issued by FDA or an FDA-accredited issuing agency (i.e., GS1, HIBC). The UDI consists of two parts, a device identifier (DI) and a production identifier(PI). This applies to both hardware and software devices. Please see the GS1 example below for an explanation.


The #s in parentheses are called Application Identifiers (AIs)and are assigned meanings. In this example (01) designates the Device Identifier (DI). This is created using GS1 software. (8018) designates the software version and (11) designates the date of manufacture (software release date). The Production Identifier is the software version (1.0.0) and the release date (2024-01-25)

The UDI can be either be a barcode with human readable characters below the barcode or can be the human readable characters without the barcode.

Once you have the UDI(s), you will need to create an account to FDA’s Global Unique Identification Database (GUDID). You will enter the UDI information in the database. There is no fee for this.

For a software medical device (SaMD) that has a user interface, it’s typical to show the UDI as a part of the device label in an about page or help box. The device label (with UDI) must not be on a transient screen like the software startup screen. For SaMD that does not have a user interface (e.g., software that automatically processes data and produces a report), we typically show the UDI somewhere in the generated reports.

The only external cost will be for the subscription to the Accredited Issuing Agency (i.e., GS1). If you only have one device the current GS1 initial fee is $30 USD. The initial fee for up to 10 UDI’s is $250 with a $50 annual fee. The other Accredited Issuing Agencies fees should be comparable. You should be able to create each UDI and enter it in the GUDID database in just a few hours.

How does Medical Device Tracking work for SaMD? 🔗

We’re not aware of any SaMD that must comply with the Medical Device Tracking regulations.

Medical device tracking is meant to make it easier to inform patients and clinicians when there is a device recall. Only certain types of devices are tracked—these are referred to as “tracked devices” in 21 CFR 821. In FDA’s 2014 guidance Medical Device Tracking, they list the product codes which require tracking. Most of them are implanted devices (e.g., pacemakers, heart valves, or prosthesis) or devices that sustain patient health (e.g., infusion pumps, ventilators, or breathing monitors). If your device does require medical device tracking, FDA will notify you of this when you receive clearance or approval to market your device.

Once we get our software cleared by the FDA, can we keep updating it? 🔗

Yes, you can keep updating the software. In fact, FDA expects that you will continue providing cybersecurity updates. That said, if the changes to the software are significant, you may need to submit a new 510(k), including possibly collecting new clinical or performance data.

Here is the flow chart from FDA’s 2017 Guidance, Deciding When to Submit a 510(k) for a Software Change to an Existing Device:

Flow diagram showing when software changes require a new 510(k) submission.

In addition to the software change guidance you will also need to work through the various flowcharts in FDA’s general change guidance.

There is some strategy surrounding the order that features are developed. For example, it is often a good idea to create key features that FDA needs to evaluate in v1.0, but then to have the software engineering team work on the v1.1 features while you’re waiting for FDA to review your submission.

Checkout our article, How Frequently Can you Release Medical Device Software for additional information on this topic.

Examples 🔗

You can see all of the product-codes in the FDA’s Product Classification database or our FDA Browser tool (which is a user-friendly portal that sync’s with FDA’s database.)

Here is a list of product codes:

Panel Regulation Product Code Name Class
Clinical Chemistry 862.1055 NQL System, Test, Amino Acids, Free Carnitines And Acylcarnitines Tandem Mass Spectrometry 2
Clinical Chemistry 862.1356 QJI Interoperable Automated Glycemic Controller 2
Clinical Chemistry 862.1356 QJS Interoperable Automated Glycemic Controller, Insulin Suspend 2
Toxicology 862.2265 PFF High Throughput Dna Sequence Analyzer 2
Radiology 892.2050 LLZ System, Image Processing, Radiological 2
Ophthalmic 892.2050 NFJ System, Image Management, Ophthalmic 2
Radiology 892.2050 NWE Colon Computed Tomography System, Computer Aided Detection 2
Radiology 892.2050 OEB Lung Computed Tomography System, Computer-Aided Detection 2
Radiology 892.2050 OMJ Chest X-Ray Computer Aided Detection 2
Radiology 892.2050 PGY Display, Diagnostic Radiology 2
Cardiovascular 892.2050 PZO Software For Visualization Of Vascular Anatomy And Intravascular Devices 2
Radiology 892.2050 QIH Automated Radiological Image Processing Software 2
Radiology 892.2050 QKB Radiological Image Processing Software For Radiation Therapy 2
Ear Nose & Throat 892.2050 QQE Image Management Software For Planning Of Otologic And Neurotologic Procedures 2
Radiology 892.2050 QTZ Radiological Image Processing Software For Ablation Therapy Planning And Evaluation 2
  892.2265 PFF High Throughput DNA Sequence Analyzer 2
Pathology 864.3750 QPN Software Algorithm Device To Assist Users In Digital Pathology 2
Pathology 864.3700 PSY Whole Slide Imaging System 2
Pathology 864.3700 PZZ Digital Pathology Display 2
Pathology 864.3700 QKQ Digital Pathology Image Viewing And Management Software 2
Hematology 864.9165 MMH Blood Establishment Computer Software And Accessories 2
Microbiology 866.2190 PPU Microbial Colony Image Assessment System 2
Microbiology 866.2190 QQY Culture Plate Imaging System For Qualitative Assessment Of Resistant Organisms 2
Cardiovascular 870.1405 QQI Interventional Cardiovascular Implant Simulation Software Device 2
Cardiovascular 870.1415 PJA Coronary Vascular Physiologic Simulation Software 2
Cardiovascular 870.1415 QEK Angiographic Coronary Vascular Physiologic Simulation Software 2
Dental 872.3661 KZN Scanner, Color 2
Dental 872.3661 NOF System, Optical Impression, Computer Assisted Design And Manufacturing (Cad/Cam) Of Dental Restorations 2
Dental 872.3661 QJK Intraoral Camera 2
Ear Nose & Throat 874.3315 PLK Tympanic Membrane Direct Contact Hearing Aid 2
Ear Nose & Throat 874.3325 QDD Self-Fitting Air-Conduction Hearing Aid, Prescription 2
Ear Nose & Throat 874.3325 QUH Self-Fitting Air-Conduction Hearing Aid, Over The Counter 2
Ear Nose & Throat 874.3340 PFO Active Implantable Bone Conduction Hearing System 2
Gastroenterology/Urology 876.1300 NEZ System, Imaging, Gastrointestinal, Wireless, Capsule 2
Gastroenterology/Urology 876.1300 NSI System, Imaging, Esophageal, Wireless, Capsule 2
Gastroenterology/Urology 876.1310 QKZ Magnetically Maneuvered Capsule Endoscopy System 2
Gastroenterology/Urology 876.1330 PGD Colon Capsule Imaging System 2
Gastroenterology/Urology 876.1450 QIS Esophageal, Mucosal, Electrical Characterization 2
Gastroenterology/Urology 876.1520 QNP Gastrointesinal Lesion Software Detection System 2
Gastroenterology/Urology 876.1735 MYE System, Electrogastrography (Egg) 2
Gastroenterology/Urology 876.2050 OQT Prostate Lesion, Documentation, System 2
Gastroenterology/Urology 876.4340 PLP High Intensity Ultrasound System For Prostate Tissue Ablation 2
Gastroenterology/Urology 876.4350 PZP Fluid Jet Removal System 2
Gastroenterology/Urology 876.5026 QRC Non-Implanted Electrical Stimulation Device For Management Of Premature Ejaculation 2
Gastroenterology/Urology 876.5330 QAJ Cutaneous Electrode Stimulator For Urinary Incontinence 2
Neurology 876.5340 QHH Non-Implanted Nerve Stimulator For Pain Associated With Irritable Bowel Syndrome (Ibs) 2
Gastroenterology/Urology 876.5960 QMY Computerized Behavioral Therapy Device For Treating Symptoms 2
Gastroenterology/Urology 876.5981 ONY Oral Removable Retainer For Weight Management 2
General & Plastic Surgery 878.3510 PQN Carbon Dioxide Gas Controlled Tissue Expander 2
General & Plastic Surgery 878.4360 PMC Scalp Cooling System 2
General & Plastic Surgery 878.4420 PAY Over-The-Counter Radiofrequency Coagulation Device For Wrinkle Reduction 2
General & Plastic Surgery 878.4430 QAI Powered Microneedle Device 2
General & Plastic Surgery 878.4550 QDF Parathyroid Autofluorescence Detection Device 2
General & Plastic Surgery 878.4550 QDG Parathyroid Autofluorescence Imaging Device 2
General & Plastic Surgery 878.4550 QJF Autofluorescence Imaging Adjunct Tool For Wounds 2
General & Plastic Surgery 878.4635 LEJ Booth, Sun Tan 2
General & Plastic Surgery 878.4635 RAB Sunlamp Products (Pre-Standard) 2
General & Plastic Surgery 878.4635 REF Suntan Bed 2
General & Plastic Surgery 878.4635 REG Suntan Lamp 2
General & Plastic Surgery 878.4635 REH Tabletop Sunlamp System 2
General & Plastic Surgery 878.4685 PZL Extracorporeal Shock Wave Device For Treatment Of Diabetic Foot Ulcers 2
General & Plastic Surgery 878.4740 GAG Stapler, Surgical 2
General & Plastic Surgery 878.4740 QQS Stapler, Skin 1
General & Plastic Surgery 878.4783 QFC Negative Pressure Wound Therapy Device For Reduction Of Wound Complications 2
General & Plastic Surgery 878.4961 QNM Mountable Electromechanical Surgical System For Transluminal Approaches 2
General Hospital 878.5050 PQM Surgical Smoke Precipitator 2
General & Plastic Surgery 880.2750 PBZ Image Processing Device For Estimation Of External Blood Loss 2
General Hospital 880.5445 OKL Intravascular Administration Set, Automated Air Removal System 2
General Hospital 880.6210 MTV Sharps Needle Destruction Device 2
General Hospital 880.6315 NZH Medication Management System, Remote 2
General Hospital 880.6600 OSZ Antimicrobial Keyboard 2
Neurology 882.1440 NCG Neuropsychiatric Interpretative Electroencephalograph Assessment Aid 2
Neurology 882.1450 PIW Brain Injury Adjunctive Interpretive Electroencephalograph Assessment Aid 2
Neurology 882.1455 QEA Brain Injury Adjunctive Interpretive Oculomotor Assessment Aid 2
Neurology 882.1470 PKQ Computerized Cognitive Assessment Aid 2
Neurology 882.1470 PTY Computerized Cognitive Assessment Aid, Exempt 2
Neurology 882.1471 POM Computerized Cognitive Assessment Aid For Concussion 2
Neurology 882.1491 QPF Pediatric Autism Spectrum Disorder Diagnosis Aid 2
Neurology 882.1580 POS Physiological Signal Based Seizure Monitoring System 2
Neurology 882.1630 POP Cranial Motion Measurement Device 2
Neurology 882.1935 OPT Infrared Hematoma Detector 2
Neurology 882.5700 PLU Thermal System For Insomnia 2
Neurology 882.5705 QMZ Digital Therapy Device To Reduce Sleep Disturbance For Psychiatric Conditions 2
Neurology 882.5800 JXK Cranial Electrotherapy Stimulator To Treat Depression 3
Neurology 882.5800 QJQ Cranial Electrotherapy Stimulator To Treat Insomnia And/Or Anxiety 2
Neurology 882.5801 PWE Computerized Behavioral Therapy Device For Substance Use Disorders 2
Neurology 882.5801 QVO Computerized Behavioral Therapy Device For Insomnia 2
Neurology 882.5802 QCI Transcranial Magnetic Stimulation System For Obsessive-Compulsive Disorder 2
Neurology 882.5802 QMD Transcranial Magnetic Stimulation System For Smoking Cessation 2
Neurology 882.5808 OKP Transcranial Magnetic Stimulator For The Treatment Of Migraine Headache 2
Neurology 882.5855 QQC Brain Stimulation Programming Planning Software. 2
Neurology 882.5891 PCC Stimulator, Nerve, Electrical, Transcutaneous, For Migraine 2
Neurology 882.5892 PKR Non-Invasive Vagus Nerve Stimulator - Headache 2
Neurology 882.5892 QAK Non-Invasive Vagus Nerve Stimulator For Migraine Headache 2
Neurology 882.5893 QAR Thermal Vestibular Stimulator For Headache 2
Neurology 882.5895 OVP Vibratory Counter-Stimulation 2
Neurology 882.5896 PZR Percutaneous Nerve Stimulator For Opioid Withdrawal 2
Neurology 882.5897 QBC External Upper Limb Tremor Stimulator 2
Neurology 882.5898 QGL Transcutaneous Nerve Stimulator For Adhd 2
Neurology 882.5940 GXC Device, Electroconvulsive Therapy 3
Neurology 882.5940 QGH Electroconvulsive Therapy Device For Catatonia, Major Depressive Disorder, And Bipolar Disorder 2
Obstetrics/Gynecology 884.1630 HEX Colposcope (And Colpomicroscope) 2
Obstetrics/Gynecology 884.1630 MOK Vaginoscope And Accessories 2
Obstetrics/Gynecology 884.1630 OHE Forensic Evidence Sexual Assault Kit 2
Obstetrics/Gynecology 884.1630 PTZ Colposcope (And Colpomicroscope), Exempt 2
Obstetrics/Gynecology 884.1710 PGT Insufflator, Hysteroscopic, Fluid, Closed-Loop Recirculation With Cutter-Coagulator, Endoscopic, Bipolar 2
Obstetrics/Gynecology 884.5370 PYT Device, Fertility Diagnostic, Contraceptive, Software Application 2
Obstetrics/Gynecology 884.6195 PBH Embryo Image Assessment System, Assisted Reproduction 2
Ophthalmic 886.1100 PIB Diabetic Retinopathy Detection Device 2
Ophthalmic 886.1342 PMW Strabismus Detection Device 2
Ophthalmic 886.1450 HJB Instrument, Measuring, Corneal Radius 1
Ophthalmic 886.1925 PLZ Ocular Pattern Recorder 2
Ophthalmic 886.5201 QIU Intense Pulsed Light Device For Managing Dry Eye 2
Ophthalmic 886.5300 PQJ Intranasal Electrostimulation Device 2
Ophthalmic 886.5305 QKV Electromechanical Tear Stimulator 2
Ophthalmic 886.5310 QBR Intranasal Electrostimulation Device For Dry Eye Symptoms 2
Ophthalmic 886.5905 PIC Oral Electronic Vision Aid 2
Orthopedic 888.1600 QGQ Bone Indentation Device 2
Orthopedic 888.3090 QFP Intraoperative Orthopedic Strain Sensor 2
Orthopedic 888.3600 QPP Implantable Post-Surgical Kinematic Measurement Knee Device 2
Physical Medicine 890.3110 INO Chair, Positioning, Electric 2
Physical Medicine 890.3450 PAE Upper Extremity Prosthesis With Multiple Simultaneous Degrees Of Freedom And Controlled Via Cutaneous Electromyography 2
Neurology 890.3480 PHL Powered Exoskeleton 2
Physical Medicine 890.3690 INK Stretcher, Wheeled, Powered 2
Physical Medicine 890.3890 IMK Wheelchair, Stair Climbing 2
Physical Medicine 890.5420 QOL Electroencephalography (Eeg)-Driven Upper Extremity Powered Exerciser 2
Physical Medicine 890.5525 EGJ Device, Iontophoresis, Other Uses 2
Physical Medicine 890.5525 KTB Device, Iontophoresis, Specific Uses 2
Physical Medicine 890.5670 OSD Massager, Therapeutic, To Internally Massage Trigger Points In The Pelvic Floor Musculature 2
Physical Medicine 890.5670 QKD Massager, Therapeutic, To Internally Massage Trigger Points In The Pelvic Floor Musculature, Prescription Use 2
Physical Medicine 890.5800 QRA Virtual Reality Behavioral Therapy Device For Pain Relief 2

Special Controls 🔗

QME - Software For Optical Camera-Based Measurement Of Pulse Rate, Heart Rate, etc. 🔗

The QME product code (“Software For Optical Camera-Based Measurement Of Pulse Rate, Heart Rate, Breathing Rate, And/Or Respiratory Rate”) is Class 2. Manufacturers of these devices thus must comply with general controls and also special controls. The regulation number for the QME product code is 21 CFR 870.2785. All of this can be seen with Innolitics’ FDA browser or in the FDA’s product code database. Within the regulation, it states that the following special controls apply:

Classification. Class II (special controls). The special controls for this device are:

  1. A software description and the results of verification and validation testing based on a comprehensive hazard analysis and risk assessment must include:
    1. A full characterization of the software technical parameters, including algorithms;
    2. If required image acquisition hardware is not included with the device, full specifications of the hardware requirements and testing to demonstrate the specified hardware ensures adequate data for validated and accurate measurements;
    3. A description of the expected impact of all applicable sensor acquisition hardware characteristics and associated hardware specifications;
    4. A description of all mitigations for user error or failure of any subsystem components (including signal detection, signal analysis, data display, and storage) on output accuracy; and
    5. Software documentation must include a cybersecurity vulnerability and management process to assure software functionality.
  2. Clinical data must be provided. This assessment must fulfill the following:
    1. The clinical data must be representative of the intended use population for the device. Any selection criteria or sample limitations must be fully described and justified.
    2. The assessment must demonstrate output consistency using the expected range of data sources and data quality encountered in the intended use population and environment.
    3. The assessment must compare device output with a clinically accurate patient-contacting relevant comparator device in an accurate and reproducible manner.
  3. A human factors and usability engineering assessment must be provided that evaluates the risk of improper measurement.
  4. Labeling must include:
    1. A description of what the device measures and outputs to the user;
    2. Warnings identifying sensor acquisition factors or subject conditions or characteristics (garment types/textures, motion, etc.) that may impact measurement results;
    3. Guidance for interpretation of the measurements, including a statement that the output is adjunctive to other physical vital sign parameters and patient information;
    4. The expected performance of the device for all intended use populations and environments; and
    5. Robust instructions to ensure correct system setup.

QPN - Software Algorithm Device To Assist Users In Digital Pathology 🔗

The QPN product code (“Software Algorithm Device To Assist Users In Digital Pathology”) is Class 2. Manufacturers of these devices thus must comply with general controls and also special controls. The regulation number for the QPN product code is 21 CFR 864.3750. This product code was created in 2020 due to a De Novo request for the Paige Prostate software (here’s their Decision summary). Within the regulation, it states that the following description of the type of device:

A software algorithm device to assist users in digital pathology is an in vitro diagnostic device intended to evaluate acquired scanned pathology whole slide images. The device uses software algorithms to provide information to the user about presence, location, and characteristics of areas of the image with clinical implications. Information from this device is intended to assist the user in determining a pathology diagnosis.

It then states that the following special controls apply:

Classification. Class II (special controls). The special controls for this device are:

  1. The intended use on the device's label and labeling required under § 809.10 of this chapter must include:
    1. Specimen type;
    2. Information on the device input(s) (e.g., scanned whole slide images (WSI), etc.);
    3. Information on the device output(s) (e.g., format of the information provided by the device to the user that can be used to evaluate the WSI, etc.);
    4. Intended users;
    5. Necessary input/output devices (e.g., WSI scanners, viewing software, etc.);
    6. A limiting statement that addresses use of the device as an adjunct; and
    7. A limiting statement that users should use the device in conjunction with complete standard of care evaluation of the WSI.
  2. The labeling required under § 809.10(b) of this chapter must include:
    1. A detailed description of the device, including the following:
      1. Detailed descriptions of the software device, including the detection/analysis algorithm, software design architecture, interaction with input/output devices, and necessary third-party software;
      2. Detailed descriptions of the intended user(s) and recommended training for safe use of the device; and
      3. Clear instructions about how to resolve device-related issues (e.g., cybersecurity or device malfunction issues).
    2. A detailed summary of the performance testing, including test methods, dataset characteristics, results, and a summary of sub-analyses on case distributions stratified by relevant confounders, such as anatomical characteristics, patient demographics, medical history, user experience, and scanning equipment, as applicable.
    3. Limiting statements that indicate:
      1. A description of situations in which the device may fail or may not operate at its expected performance level (e.g., poor image quality or for certain subpopulations), including any limitations in the dataset used to train, test, and tune the algorithm during device development;
      2. The data acquired using the device should only be interpreted by the types of users indicated in the intended use statement; and
      3. Qualified users should employ appropriate procedures and safeguards (e.g., quality control measures, etc.) to assure the validity of the interpretation of images obtained using this device.
    4. Design verification and validation must include:
      1. A detailed description of the device software, including its algorithm and its development, that includes a description of any datasets used to train, tune, or test the software algorithm. This detailed description of the device software must include:
        1. A detailed description of the technical performance assessment study protocols (e.g., regions of interest (ROI) localization study) and results used to assess the device output(s) (e.g., image overlays, image heatmaps, etc.);
        2. The training dataset must include cases representing different pre-analytical variables representative of the conditions likely to be encountered when used as intended (e.g., fixation type and time, histology slide processing techniques, challenging diagnostic cases, multiple sites, patient demographics, etc.);
        3. The number of WSI in an independent validation dataset must be appropriate to demonstrate device accuracy in detecting and localizing ROIs on scanned WSI, and must include subsets clinically relevant to the intended use of the device;
        4. Emergency recovery/backup functions, which must be included in the device design;
        5. System level architecture diagram with a matrix to depict the communication endpoints, communication protocols, and security protections for the device and its supportive systems, including any products or services that are included in the communication pathway; and
        6. A risk management plan, including a justification of how the cybersecurity vulnerabilities of third-party software and services are reduced by the device's risk management mitigations in order to address cybersecurity risks associated with key device functionality (such as loss of image, altered metadata, corrupted image data, degraded image quality, etc.). The risk management plan must also include how the device will be maintained on its intended platform (e.g. a general purpose computing platform, virtual machine, middleware, cloud-based computing services, medical device hardware, etc.), which includes how the software integrity will be maintained, how the software will be authenticated on the platform, how any reliance on the platform will be managed in order to facilitate implementation of cybersecurity controls (such as user authentication, communication encryption and authentication, etc.), and how the device will be protected when the underlying platform is not updated, such that the specific risks of the device are addressed (such as loss of image, altered metadata, corrupted image data, degraded image quality, etc.).
      2. Data demonstrating acceptable, as determined by FDA, analytical device performance, by conducting analytical studies. For each analytical study, relevant details must be documented (e.g., the origin of the study slides and images, reader/annotator qualifications, method of annotation, location of the study site(s), challenging diagnoses, etc.). The analytical studies must include:
        1. Bench testing or technical testing to assess device output, such as localization of ROIs within a pre-specified threshold. Samples must be representative of the entire spectrum of challenging cases likely to be encountered when the device is used as intended; and
        2. Data from a precision study that demonstrates device performance when used with multiple input devices (e.g., WSI scanners) to assess total variability across operators, within-scanner, between-scanner and between-site, using clinical specimens with defined, clinically relevant, and challenging characteristics likely to be encountered when the device is used as intended. Samples must be representative of the entire spectrum of challenging cases likely to be encountered when the device is used as intended. Precision, including performance of the device and reproducibility, must be assessed by agreement between replicates.
      3. Data demonstrating acceptable, as determined by FDA, clinical validation must be demonstrated by conducting studies with clinical specimens. For each clinical study, relevant details must be documented (e.g., the origin of the study slides and images, reader/annotator qualifications, method of annotation, location of the study site(s) (on-site/remote), challenging diagnoses, etc.). The studies must include:
        1. A study demonstrating the performance by the intended users with and without the software device (e.g., unassisted and device-assisted reading of scanned WSI of pathology slides). The study dataset must contain sufficient numbers of cases from relevant cohorts that are representative of the scope of patients likely to be encountered given the intended use of the device (e.g., subsets defined by clinically relevant confounders, challenging diagnoses, subsets with potential biopsy appearance modifiers, concomitant diseases, and subsets defined by image scanning characteristics, etc.) such that the performance estimates and confidence intervals for these individual subsets can be characterized. The performance assessment must be based on appropriate diagnostic accuracy measures (e.g., sensitivity, specificity, predictive value, diagnostic likelihood ratio, etc.).
        2. [Reserved]

When reviewing the Paige Prostate Decision summary, you can see the Intended Use follows the special controls closely:

Paige Prostate is a software only device intended to assist pathologists in the detection of foci that are suspicious for cancer during the review of scanned whole slide images (WSI) from prostate needle biopsies prepared from hematoxylin & eosin (H&E) stained formalin-fixed paraffin embedded (FFPE) tissue. After initial diagnostic review of the WSI by the pathologist, if Paige Prostate detects tissue morphology suspicious for cancer, it provides coordinates (X,Y) on a single location on the image with the highest likelihood of having cancer for further review by the pathologist.

Paige Prostate is intended to be used with slide images digitized with Philips Ultra Fast
Scanner and visualized with Paige FullFocus WSI viewing software.

Paige Prostate is an adjunctive computer-assisted methodology and its output should not be used as the primary diagnosis. Pathologists should only use Paige Prostate in conjunction with their complete standard of care evaluation of the slide image.

Note that the special controls require a clinical study.

Warning Letters 🔗

Owlet Baby Care - Smart Sock Plus 🔗

This example shows what happens if a company markets (i.e., advertises a product for sale) that FDA believes is a medical device, without complying with the regulations.

Owlet sold the “Owlet Smart Sock” product, and made marketing claims such as:

  • “Track the most important indicators of your baby’s health–like oxygen level, heart rate, and total hours slept”
  • “If your baby’s readings leave preset “safe” zones, the Smart Sock will immediately notify you that your baby needs your attention.”
  • “Rest easy knowing you’ll receive proactive notifications via lights and sounds if your baby’s oxygen level or heart rate leave preset zones”

FDA in their Warning Letter CMS 616354 on October 5, 2021, stated the following:

The United States Food and Drug Administration (FDA) has learned that your firm is marketing Owlet Smart Socks in the United States without marketing clearance or approval, in violation of the Federal Food, Drug, and Cosmetic Act (the Act) … these products are devices because they are intended for use in the diagnosis of disease or other conditions or in the cure, mitigation, treatment, or prevention of disease, or to affect the structure or any function of the body. Products that measure blood oxygen saturation and pulse rate are devices when they are intended to identify (diagnose) desaturation and bradycardia and provide an alarm to notify users that measurements are outside preset values.

Our office requests that Owlet Baby Care, Inc. cease any activities that result in the adulteration of the Owlet Smart Sock (All versions and co-branded products), such as the commercial distribution of the device for the uses discussed above.

In May 25th, 2023, Owlet was able to get 510(k) clearance for the following intended use:

The BabySat 3 pulse oximeter is indicated for use in measuring and displaying functional oxygen saturation of arterial hemoglobin (SpO2) and Pulse rate. It is indicated for spot-checking and/or continuous monitoring of well-perfused patients greater than one month old up to 18 months old and weighing between 6 and 30 lbs., in the home environment.

As part of their 510(k), they completed:

  • Electrical Safety, EMC, RFID, and Wireless Co-existing testing per various international standards
  • Software verification and validation
  • Desaturation studies across the full Fitzpatrick Scale score
  • Signal Quality Studies and At Home Studies
  • Observational studies for skin irritation and signal quality data
  • Human factors and usability studies.

As you can imagine, this was a lot of work.

You can read the full 510(k) summary letter online.

Revision History 🔗

Date Summary of Change
8 December 2023 Initial Version; It’s still rough around the edges, but useful enough to publish.
6 January 2023 Extend the section about post-market activities. Add more details about working with software engineering groups.
29 January 2023 Jim Luker, our VP of Regulatory Affairs, did a thorough review of the document and made several clarifications and a few small corrections.

Get To Market Faster

Monthly Medtech Insider Insights

Our monthly Medtech tips will help you get safe and effective Medtech software on the market faster. We cover regulatory process, AI/ML, software, cybersecurity, interoperability and more.