Velentium Blog

Who's in Charge Here, Anyway?: The World of Medical Standards

When it comes to standards governing the design and manufacture of medical devices, the sheer number of applicable standards can be dizzying to the software developer. Numbers and letters seem to hover over everything: ISO 13485, ISO 14971, 21 CFR Part 820, 93/42/EED, etc. While it might be understandable that a software development company would want to ignore all of the standards as inapplicable to their work of designing software, a working knowledge of these standards is important for the successful integration of software into a medical device.

To begin, why so many standards? In short, there are two reasons: 1) medical devices are usually meant for the international market, which means there are a lot of governing bodies in play; and 2) the stakes are very high when you are talking about medical devices, which means that there need to be safeguards in place. So which of these standards is really important to the software developer, and how can a company begin to implement them?

It is helpful to have a starting point from which to launch. For a software developer working on medical devices in the United States, that starting point is 21 CFR Part 820. This regulation outlines the FDA requirements for a quality system to govern medical device design and manufacture. This regulation is binding on medical device manufacturers, which means that inspectors will look for any noncompliances to this document; if any are found, the FDA has the power to stop manufacture, pull the device from the market, and/or issue fines.

Compliance with Part 820, then, is a big deal. So how can a company know that they are doing okay in this area? While the FDA conducts inspections to discover points of noncompliance with Part 820, you don't know that there is a problem with your system until it's too late—until the FDA finds a problem that might put device marketability in jeopardy. To use an analogy, a cop isn't going to pull you over to let you know how really excellent your driving is. Neither is the FDA going to make courtesy calls to give your quality system a check-up.

The "check-up" comes in the form of ISO standards. As it relates to medical devices, ISO standards are completely voluntary. You are not required by any regulatory bodies to comply with ISO standards; BUT, the standards are written such that if you are in compliance with them, you will also be in compliance with regulatory standards. ISO 13485 is based on 21 CRF Part 820. ISO 14971, on risk management, explains how to meet the risk requirements in ISO 13485, which makes sure you are compliant with risk requirements in Part 820.

It is also possible to be "certified" in ISO standards. ISO certification again has nothing to do with the FDA. The FDA does not require, or accept, any ISO certification. But certifying bodies offer the "check-up" we were talking about before. They come in, assess how you are doing things, tell you where you need to change to be compliant, certify that your system is eventually compliant, teach you how to do self-assessments, and provide an annual audit that lets you know if things are going ok BEFORE the FDA comes in.

Other ISO standards and FDA guidances are all meant to tell you how to be compliant with 21 CFR Part 820. These include ISO 24971, IEC 62304, IEC 62366, ISO 19011, and CDRH guidances. They are a "deeper dig" into Part 820 to ensure that it is accurately understood and implemented.

The roadmap we have created here is based on device design and manufacture in the United States, but in other countries 21 CFR Part 820 has no applicability. Each country, or identified group of countries such as the EU, has its own regulatory standards, which in turn may have their own guidance documents.
Regulatory compliance and the quality system that ensures it are of utmost importance to medical device manufacturers. Software developers who intend for their software to be a part of medical devices cannot ignore this aspect that is so important to their customer, leaving it up to the manufacturer to "figure out" how to integrate the software system into regulatory and quality systems. Medical device software developers should have a working knowledge of 21 CFR Part 820, ISO 13485, and the guidance documents that accompany them.