A Brief Introduction to the United States Medical Software Regulations, for Developers

by J. David Giese on July 23, 2020

This article provides an introduction to the US regulations that apply to medical software. To keep the article to the point, we omit some details that we feel are distracting and typically unimportant.

FDA Premarket Submissions 🔗

Before you can legally sell most new medical devices within the United States, you first need to make a premarket submission to the Food and Drug Administration (FDA), and they need to approve it. There are several types of premarket submissions. A Premarket Notification 510(k), which involves demonstrating your device is similar to an existing predicate device, is the most common type. De Novo submissions are for low or moderate risk devices, while PMAs are for high-risk devices.

Software may be part of a medical device, or it may itself be a medical device. This latter form is referred to as Software as a Medical Device (SaMD). At Innolitics, since we specialize in medical imaging, we often work with SaMD.

Quality System 🔗

Once your premarket submission is accepted, you are free to market the device. If you make significant changes to the device, you will have to file additional submissions. You will also need to comply with a number of post market requirements. One of the largest post-market requirements is to continue following the processes of a quality system. A quality system is a set of processes that control how products are developed, maintained, manufactured, how complaints are handled, how documents are stored and approved, etc.

Guidance Documents 🔗

The FDA provides a set of guidance documents that describes how device manufacturers are expected to follow the underlying regulations. The regulations are binding; these are the laws that were passed by Congress. The guidance documents are suggestions, but typically it is best to follow them. The Quality System regulations, FDA CFR Part 820, provides a good example of regulations (it is surprisingly short and readable). You can contrast this with the guidance documents, which often have more detail. Here are some of the most important guidance documents for software development:

Standards 🔗

In addition to regulations and guidance documents, there are also consensus standards. Standards are documents, usually developed by a third party like the International Standards Organization (ISO), that describe a standard way of doing something. A consensus standard is a standard that the FDA recognizes, and, although not usually legally binding, will facilitate the FDA’s review process. (Some standards are referenced in the regulations and are thus binding.) The most common standards we use include:

Unlike regulations and guidance documents, which are freely available online, standards typically cost a few hundred dollars. We think they are worth the money, since by following them, you will be mostly following the medical device regulations in a variety of different countries. We say mostly because often there are a few additional regulations which are unique to particular countries. If you only plan on selling in the US, it may be a bit simpler to ignore the standards and just following the regulations.

Note that standards often use different lingo than the regulations. Thus, you need to develop a mental map between the corresponding terminology. For example, the FDA uses the term off the shelf (OTS) software, while ISO 13485 uses software of unknown provenance (SOUP).


In the US, protected health information (PHI) is regulated by the Department of Health and Human Services (HHS) under the HIPAA regulations. These regulations apply to organizations, not products. In particular, they apply to covered entities, e.g., providers and health insurers, and business associates. Business associates are typically organizations that handle PHI on behalf of covered entities. When a covered entity needs a third party to access PHI, they will have them sign a business associated agreement (BAA), which usually has a lot of details about how the business associate will act.

Business associates can have their own business associates. For example, if one of Innolitics’ clients hosts medical image processing software in the cloud, their customers (the hospitals) are covered entities. Our client is a business associate. If we need to touch PHI in the production server, we would be a business associate of our client. We avoid entering BAAs with our clients since it is usually not necessary. That said, we still need to know about HIPAA since our software needs to be developed so that hospitals can be HIPAA compliant. Thus, while it doesn’t make sense to say a product is HIPAA compliant, but you can say software makes it easy for a hospital that buys it to remain HIPAA compliant.

The full HIPAA regulations are in 45 CFR Parts 160, 162, and 164.

Get Medical Imaging Software Tips

Subscribe using RSS

How frequently are they sent?

We send out tips about once a month.

What will I read?

Articles about DICOM, AI, image processing, medical regulations, and other topics of interest to professionals in the medical imaging software industry.

You may view previous articles here.

Who creates the content?

The Innolitics team, and experts we collaborate with, write all of our articles.