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 controls how products are developed, maintained, manufactured, how complaints are handled, how documents are stored and approved, and so on.
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:
- Design Control Guidance For Medical Device Manufacturers
- Content of Premarket Submissions for Software in Medical Devices
- General Principles of Software Validation
- Off-The-Shelf Software Use in Medical Devices
- Policy for Device Software Functions and Mobile Medical Applications
- Content of Premarket Submissions for Management of Cybersecurity
- Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software
- Postmarket Management of Cybersecurity in Medical Devices
- Multiple Function Device Products: Policy and Considerations
- Applying Human Factors and Usability Engineering to Medical Devices
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 is recognized by the FDA and, although not usually legally binding, will facilitate the FDA’s review process. (Some standards can be referenced in the regulations. When this is the case, the standards become legally binding.) The most common standards we use, that apply to medical software, are:
- ISO 13485 - Quality management for medical devices
- ISO 14971 - Application of risk management to medical devices
- IEC 62304 - Medical device software life cycle processes
- IEC 62366 - Application of usability engineering to medical devices
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).
HIPAA 🔗
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, 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.
