I’m going to give an overview of the different regulations, guidances, and standards that you need to understand if you are going to develop software for a medical device.

Get ready for a bunch of links, with just a bit of explanation.

As far as regulations go, I’m going to be US-centric for now, and focus on the FDA. At some point in the future, I may revisit the European market and other international regulatory bodies.

FDA Regulations

Like every other department in the federal government of the United States, the FDA is governed by the Code of Federal Regulations (CFR). You can actually go online and read all these regulations in their entirety! No, please don’t do that.

However, there are some sub-sub-sub-sections that you should read. Let’s break down the organization of the CFR so you know what you’re looking at.

• Code of Federal Regulations
• Title 21 — Food and Drug
• Chapter 1 — FDA, Department of Health and Human Services
  This regulates the whole of the FDA.
• Subchapter H — Medical Devices
  This subchapter details the FDA regulation of the medical device industry. It consists of parts 800 - 899. You should read through the part headings, and quickly skim any section that looks interesting.
• Part 820 — Quality System Regulation
  You should read this part carefully, particularly the sub-parts below.
• 820.20-820.25 Quality System Requirements
• 820.30 Design Controls

You’ll hear people say “21 CFR 820 dot 30”. This is referring to the Design Controls section of the CFR.

21 CFR 820.30 is the most important section to read carefully. It spells out “Design Controls”, which govern the process you use to design and develop a medical device. As you’ll see, it’s extremely short and vague.

However, there are FDA guidance documents that give more detailed explanation of how the FDA applies the regulations, and standards that give even more detailed instructions on what to do. The FDA has made efforts to “harmonize” to the standards — that is, if you follow the latest versions of the standards that I mention below, you will meet FDA requirements. This hasn’t been the case in the past, and it’s especially annoying when regulatory bodies for different markets (the EU, Canada, Japan, etc.) have differing requirements.

FDA Guidance Documents for Medical Device Software

Because the regulations are so vague, the FDA has released Guidance Documents over the years that give more, well, guidance to medical device developers and manufacturers.

Here are links to all the FDA Guidance documents that are relevant to software development for medical devices. I’ve listed them in rough order of priority — start at the top of the list and work your way down.

As with the CFR text, these are all available for free! Lucky you!

• Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (2005)
• General Principles of Software Validation (2002)
• Off-The-Shelf Software Use in Medical Devices (2019)
• Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (2014)
• Postmarket Management of Cybersecurity in Medical Devices (2016)
• Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software (2005)
• Software as a Medical Device (SAMD): Clinical Evaluation (2017)

Standards

Even the FDA guidances aren’t very specific, so many fine people at some standards organizations have developed standards documents that go into much greater detail about how to develop devices that are safe.

Unfortunately, unlike documents from the FDA, ISO and IEC standards are not available for free. In fact, they are quite expensive by the standards of a private individual. Buy them anyway. Get your company to buy them so your whole engineering team can read them. It’s definitely worth scheduling several workshops, lunch ‘n learns, or training sessions so that everyone on the team knows what’s in them and what’s expected.

IEC 62304:2016 Medical Device Software — Software life cycle processes

If you’re at all involved in software development for a medical device, read this standard in its entirety, multiple times. This is the most important standard for you to understand and follow. Remember 21 CFR 820.30 — Design Controls? This details how to apply Design Control principles and practices to the software development process.

ISO 14971:2019 Medical devices — Application of risk management to medical devices

Software engineers often get away with not knowing this standard, but they shouldn’t. It details the how to apply risk analysis to medical device development.

ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes

Software engineers should be aware of this standard, and at least skim it. Anyone setting up or administering a Quality Management System should know this one like the back of their hands.

Wrapping up

Hopefully this has given you a good overview of what documents are important to read and understand before developing software for a medical device. I’ll go into more detail about each of these documents in the future.