How ISO 13485, IEC 62304 and ISO 14971 fit together for SaMD

This is the final post in our short series on medical device software. We have covered what Software as a Medical Device is, the IEC 62304 software safety classes and risk management under ISO 14971.

If you have followed along, you might be picturing three large, separate projects. The good news is that they are not separate at all. The standards were written to work together, and each one openly relies on the others. Once you see how they connect, the whole thing gets smaller.

Laws set the goal, standards show the way

First, a distinction that makes everything else clearer.

Regulations are the law. In the EU that is the Medical Device Regulation (EU) 2017/745. In the US it is the Federal Food, Drug, and Cosmetic Act and the FDA's regulations, including the Quality Management System Regulation in 21 CFR Part 820.

Standards describe how. They are detailed, practical descriptions of good practice that regulators accept as a way of meeting the law. In the EU, following a harmonised standard published in the Official Journal gives a presumption of conformity with the requirements it covers (MDR Article 8). In the US, the FDA recognises consensus standards, including IEC 62304 and ISO 14971, and the QMSR (21 CFR Part 820) incorporates ISO 13485:2016 by reference, alongside some FDA-specific requirements.

So when you build to these standards, you are using a shared international language that regulators on both sides of the Atlantic understand. That is a real advantage for a small team. You learn one way of working and it travels with you. We explored this in why the world runs on the same standards for medical software.

The three core standards, and how they lean on each other

A helpful way to picture it: ISO 13485 is the house, ISO 14971 runs through each room, and IEC 62304 is the workshop where the software is built.

ISO 13485:2016, the quality management system. This is the framework for how your company works: how documents are controlled, how records are kept, how people are trained, how suppliers are chosen, how problems are corrected and how the product is designed and changed (clause 7.3). It is the structure everything else sits inside. Our post on what ISO 13485 asks your tools to do goes into the practical detail.

ISO 14971:2019, risk management. ISO 13485 requires you to document one or more processes for risk management in product realisation (clause 7.1). ISO 14971 is the standard that describes that process. Risk is not a separate department. It informs design, testing, release and what you do with feedback.

IEC 62304, the software lifecycle. IEC 62304 expects you to demonstrate the ability to deliver software that consistently meets requirements, and names a quality management system complying with ISO 13485 as one way to do it (clause 4.1). It also requires a risk management process complying with ISO 14971 (clause 4.2). In other words, it assumes the other two are already in place, and adds the software engineering detail on top.

Each standard points to the others. That is by design, and it is why doing them together is easier than doing them one at a time.

The companion standards, in brief

A few other standards often join the core three for software products. You will not need all of them on day one, but it helps to know what they are for.

• IEC 62366-1, usability engineering. How people actually use your product, and how use errors could lead to harm. Its findings feed straight into your ISO 14971 risk analysis.
• IEC 82304-1, health software products. Product-level requirements for standalone health software, including validation and the information you supply with it. It relies on IEC 62304 for the software lifecycle.
• IEC 81001-5-1, security for health software. Security activities across the software lifecycle. The MDR asks for software to be developed taking account of risk management, including information security (Annex I, section 17.2), and in the US, section 524B of the Federal Food, Drug, and Cosmetic Act sets cybersecurity requirements for devices that meet its definition of a "cyber device" (section 524B(c)).

Again, these plug into the same system. Usability risks and security risks go into the same risk file. Security activities happen in the same lifecycle. Nothing needs its own separate world.

One change, followed through the system

The clearest way to see the connections is to follow one ordinary product change.

Say your team wants to add a warning to the insulin dose calculator from earlier in the series, shown when a recommended dose is unusually high.

1. The change is proposed and recorded. ISO 13485 asks you to control design and development changes, including reviewing their effect (clause 7.3.9). The change gets a record and a reason.
2. Risk is reassessed. Does the warning reduce an existing risk? Could it create a new one, such as users dismissing it out of habit? ISO 14971 asks you to check that controls do not introduce new risks (clause 7.5).
3. Usability is considered. Is the warning clear, and does it appear at the right moment? IEC 62366-1 helps you check that real users understand it.
4. Requirements are updated. The warning becomes a software requirement under IEC 62304 (clause 5.2), traced to the risk it controls.
5. It is built and tested. The software is changed under your configuration management, and system tests show the warning appears when it should (clause 5.7).
6. It is released. The release record identifies the version and its known anomalies (IEC 62304, clause 5.8), and your release review confirms the risk review took place.
7. You keep listening. After release, feedback and complaints tell you whether the warning works in practice, and that information goes back into the risk file (ISO 14971, clause 10).

Seven steps, four standards, one change. And in practice it feels like a single, sensible workflow, because it is one. The standards give each step a clear place, which makes the important things much harder to miss.

Where to begin

If you are just starting out, here is a calm order of play:

1. Confirm whether your product is a medical device, and what class it is. Our medical device check and classifier help you reason it through.
2. Set up the core of your quality system: document control, records, training, and how you handle problems and changes.
3. Start your risk file with the hazardous situations you can already see.
4. Choose your software safety class and plan your development to match.
5. Connect them as you go, so requirements, risks, tests and releases tell one story.

You do not have to build all of it before you write another line of code. For a sense of pace, see our realistic compliance timeline and the QMS a medtech startup needs in year one. Small teams do this successfully, a piece at a time, and the system grows with the product.

We are in this with you

Medical device software has a reputation for being complicated. In truth it is mostly careful, well organised engineering with a good memory. The standards are public, the path is well trodden, and you do not have to walk it alone.

That is what QualiHQ is for. We bring your quality system, requirements, tests, risk register and releases into one place, with document approvals, change control and release checks built into the way you already work.

Thank you for following the series. If you would like to talk through where your product stands, we would love to hear from you.

Book a demo and we will help you see how the pieces fit for your product.