Agile Software Development in Regulated Environments Example: Medical Devices

In the last post, I introduced this  blog series and category wherein I’ll be describing agile approaches to developing high assurance software in regulated environments. This series is intended for those who do such development in the Avionics, Defense, Medical and Pharmaceutical industries, as well as providing some guidance for any business which can’t ethically or financially afford software failures. While many might shudder under the apparent weight of these standards, and the apparent heavy waterfall bias we perceive in them, we must also admit that they have worked fairly effectively for those industries in the past, and have kept us all a little safer in the process. So we’ll start with some respect, move to an understanding, and then see what we can do to “agilify” our practices under these standards as we move forward.

A Case in Point: Regulation of the Development of Medical Devices for Sale in the United States

In the next few posts,  I’ll focus specifically on the US Food and Drug Administrations regulation of the development and marketing of medical devices which contain software. Other comparable regulations exist for other markets, (see note below), but this one set of standards is fairly representative of many such regulatory standards. If we understand one, by extension, we might be able to understand a little something about them all.

To do so, the figure below is my attempt to to describe the chain of regulatory requirements that govern this particular software development activity as provided under the US FDA Code of Federal Regulations (CFR) 21.

[Note: while this post and thread focuses on US FDA Good Manufacturing Practices (GMP) requirements for medical devices, these requirements are generally harmonized with the International Organization for Standards (ISO) 9001:1994 and ISO DIS 13485, which are typically applicable outside the United States.]

It all starts with Code of Federal Regulations Title 21

The Code of Federal Regulations (CFR) is a “codification of the general and permanent rules published in the Federal Register by the Executive departments and agencies of the Federal Government”. In other words, the CFR is the law of the land in the US. Title 21 of the CFR is reserved for rules of the Food and Drug Administration.

CFR 21 Subchapter H – Medical Devices

Within the above code of regulations, CFR 21 Subchapter H – Medical Devices, covers the design, manufacture and marketing of medical devices, whish is under the auspices of the Center for Device and Radiological Health, or CDRH. CDRH is responsible for regulating firms who manufacture, repackage, relabel, and/or import medical devices sold in the United States. In addition, CDRH regulates radiation-emitting electronic products (medical and non-medical) such as lasers, x-ray systems, ultrasound equipment, etc.

CFR 21 Part 820 Quality System Regulation

The term “quality system” refers to the documented and controlled practices a developer/manufacturer uses to define, design, develop and manufacture a device. Regulatory requirements for the design and development of such devices is described in CFR 21 Part 820 Quality System Regulation, the scope of which is as follows:

“Current good manufacturing practice (CGMP) requirements are set forth in this quality system regulation. The requirements in this part govern the methods used in, and the facilities and controls used for, the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use. The requirements in this part are intended to ensure that finished devices will be safe and effective and otherwise in compliance with the Federal Food, Drug, and Cosmetic Act (the act).”

Quality System Regulation, CFR21 Part 820.30 Subpart C Design Controls

Within 820, Quality System regulation, CFR21 Part 820.30 Subpart C Design Controls, specifies the regulations for device design as follows:

“Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.”

Subpart 820.30 covers all devices, whether they include software or not. 820.30 makes no further discrimination for software development methods. However, as an aid to FDA staff and the industry. CDRH has published additional guidelines which add specificity to the expectations as to how these regulations will be interpreted. First, for 820.3, Design Controls in general, there is the publication Design Control Guidance for Medical Device Manufacturers, (CDRH) 1997. Paragraphs (f) and (g) describe verification and validation, respectively.

General Principles of Software Validation; Final Guidance for Industry and FDA Staff. CDRH 2002.

And finally, and more specifically to our context, CDRH has published a document which provides guidelines for the general principles of software validation, General Principles of Software Validation; Final Guidance for Industry and FDA Staff. CDRH 2002.

This final document in our chain provides the most specific, and most current guidance for software developers of medical devices. So when it comes to agile development, this document will be our “stalking horse” (exemplar) for our understanding of appropriate methods of agile software development.  This document:

“outlines general validation principles that the Food and Drug Administration (FDA) considers to be applicable to the validation of medical device software or the validation of software used to design, develop, or manufacture medical devices.”

As the document notes, its audience includes;

•   Persons responsible for the design, development, or production of medical device software

•   Persons responsible for the design, development, production, or procurement of automated tools used for the design, development, or manufacture of medical devices or software tools used to implement the quality system itself

In other words, this document is for us. Further:

“This guidance recommends an integration of software life cycle management and risk management activities. Based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle.”

As you can see, the document certainly doeesn’t specifically constrain development to stage-gated waterfall like activities, so there is room for agile methods. Since this particular document provides the specificity we need to map our agile methods into an acceptable process for medical device development, I’ll describe some of the key aspects of this document in the next post and we’ll then use that outline as guidance for our agile, high assurance activities.