Agile Development in Regulated Environments Example: Medical Devices – Waterfall Lifecyle Model

In an earlier post, I noted that I would be using the FDA CFR 21 820.30 regulations as our example “stalking horse” to try to develop a reasonable and  logical way of conforming agile development to these, and similar regulatory standards that are prevalent in high assurance software development industries. By way of context and example, here’s the regulatory tree that drives the medical device industry in the US.

FDA CFR21 820.30 Regulatory Tree

The heart of the matter here is CFR21, Part 820.30 Subpart C, Design Controls, and expectations for meeting these regulations are elaborated in the much larger documents on the right. But since the document highlighted on the left is really the legal document, (and it is remarkably short), we’ll first analyze that to understand what we are legally obligated to achieve in this regulated software process.  This regulatory document can be found online here.

It’s objective is:

“a)General. (1) Each manufacturer of any ……(device), shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.”

It goes on to describe the various lifecycle activities, and the work that has to be done in each . I’ve captured the highlights in the table below.

Summary Table of CFR21 820.30 Design Controls

If we look at this pictorially, and perhaps with the implied waterfall that one tends to naturally infer, you get the following picture.

Graphical View of CFR 21 820.30

If we use the shorthand we provided in the table above for the development activities, then you get the following picture:

Software development lifecycle view as implied by CFR21 820.30

Wow, that sure looks familiar, and somehow, not very agile, does it? Does it have to be that way. NO. That’s the subject of the next post.

Advertisement

The Agile Enterprise Big Picture Graphic (revised,again).

During the course of finalizing the Agile Software Requirements book, the Agile Enterprise Big Picture graphic has undergone some minor changes and has been revised for the umpteenth time. The blog series/category on the Big Picture is here, (but the book does a better job of describing it in a more systematic and incremental way).

Update: April 25, 2011:

I’ve even decided to change the name with a bit of “co-branding” (Thanks to Chad Holdorf at http://www.scaledagiledelivery.com)
The latest version of the graphic is below:

Big Picture: Scaled Agile Delivery Model

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.

New Blog Series: High Assurance Agile Development in Regulated Environments

Well, I’ve about wrapped up the book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, at Addison-Wesley. Still working through the thousand nits and nats required to get it into print “hey, can we tighten the kerning on the handwriting font we are using to describe user stories….”  and “shouldn’t there be a serial comma in the title? Answer, umm, yeah.” (note late breaking title change!)

In any case, I’ve about done my work on that project and now its time to move onto other topics. Of course, I’ll continue to opine on agile development, agile requirements and agile at scale on this blog, simply because these newer methods work so well in increasing the big three software process attributes – quality, productivity and morale. In turn, agile software enterprises receive the ultimate beneficial result – improved economic outcomes, not to mention higher safety, value, convenience, efficiency and the resultant better standards of living for society at large – that we can derive when we improve on this strange mix, of art, science and engineering that we call software development. (Note: when we discover the next software process that further improves the above, I’ll for sure write about that, too, assuming I can still see the monitor.)

Speaking of quality, however, it comes as no surprise to agile proponents that properly implemented agile achieves much higher quality than its waterfall predecessor. The tyranny of the urgent defect triage can be largely mitigated with agile. And while we will always need to address defects, nonconformance and minor user needs misfires, we can focus more on truly understanding user needs and building software that has quality from the get-go, rather than using (insert your favorite workflow/defect management tool name here) as your ultimate end game-death march-process model for achieving eventual shipment-level quality. Boy are we thankful for that.

Given the emphasis on quality in agile, and given our improved results, it seems clear that as it continues to crosses the chasm from early adopters to mainstream development,  agile will also exit the dilbertesque phase of we-don’t-need-no-stinking-requirements-documents era and enter the IF you-really want-the-highest-quality-possible, THEN you-must-use-agile methods era. In so doing, agile will hit another mainstream, the mainstream of people developing software for medical devices, avionics, industrial controls, financial trading systems and other high assurance software applications where the presence of any material defect has an unacceptable human or economic cost. (Note: in many cases, agile is already there, but there isn’t yet a lot published about it….)

In the area of medical devices, for example, I have personally devoted almost two decades of my career to developing safe and efficacious medical equipment using traditional, waterfall methods. (That was the business of my first business, RELA, Inc., which evolved into Colorado Medtech.) It wasn’t always pretty or efficient, but we made it work (I survived that career with no software related device failures).

Since we were all using the waterfall model, it’s no surprise that the governing and regulatory bodies built their standards around it as well and that is still the case today. So now we face a dilemma:

How do we move the industry foreword to agile development in the face of waterfall-based governance that regulates the processes by which we use to develop software?

I have a number of stakeholders, peers and clients that face this dilemma, some in medical equipment, and some in other industries, so that will be the subject of my next series of posts (and much of my next few months work). Specifically, I plan to take the topic on in two new threads (categories on this blog):

1) Thread 1. High Assurance Agile Development and Regulated Environments: In this series, I’ll attempt to illustrate how agile development methods can be applied to produce higher quality software than we could with any prior methods. In addition, in order to help assure public safety, the development of much of such software is regulated by specific government and industry standards in Aeronautics, Defense, Pharmaceuticals and Medical devices industries,  so we’ll be keeping those standards in mind as we tell our tale. This series will be based in part on the enterprise backlog model and other methods described in Agile Software Requirements.

2)   Thread 2. Agile and the FDA. In this series, I’ll be mapping the High Assurance Software thread above to current regulatory guidelines in one specific industry: that is the development, manufacturing and sale of medical devices and medical equipment as regulated by the US Food and Drug Administration’s Current Good Manufacturing Practices. (see FDA CGMP Code of Federal Regulations (CFR) , Part 820, Quality System Regulation). While I’ll focus on this one industry and its regulatory standards, it’s a fairly common pattern that can hopefully applied outside of the United States and in other regulated software development contexts.

I recognize that these threads may not be of interest to a lot of people. If you can economically or morally afford to make a few mistakes, even somewhat nasty ones, in your released products, this may not be for you. But if you can’t – and due to the constantly expanding depth and range of software applications – more and more of us can’t, then this series may be for you.

In addition, to help assure quality in the work product, I’ll be working hard to get peer review from other professionals in the industry so that we can move forward together with a new body of knowledge, rather than just one author’s ideas.  If you’d like to participate, you can do so actively by pinging me or set your RSS reader to this blog and comment wherever applicable. I look forward to your contributions.

After all, since agile works so well, shouldn’t every industry and every consumer get the benefits?

–Dean

Note: portions of this work are sponsored by, and developed in collaboration with, the folks at Rally Software Development Corp. (ww.rallydev.com) makers of providers of Agile Application Lifecycle Management solutions.