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.

10 thoughts on “Agile Software Development in Regulated Environments Example: Medical Devices

  1. Great post.

    Do you plan on drawing any comparisons between Kanban, Lean, and Agile methodologies. The former approaches have long been adopted by industry as fitting within GMP. Drawing the comparison could be helpful push in adoptiing Agile for software projects.

    -bernie

    • Thanks Bernie,
      I generally view agile as a software instance of lean (limit WIP, actively manage queues, cadence and synchronization, exploiting (rather than eliminating,) variability, decentralize control and planning) . I “lean” towards Reinertsen’s lean product development flow principles, as opposed to the Toyota “lean is mostly about the elimination of waste” approach. So I don’t think I’ll be describing lean so much in this series, other than by the application of these principles in agile. Kanban is mostly a method of sequencing work, plus making WIP visible, etc. As such, it can play a role in agile, but I’m not sure it will really affect a teams agile, high assurance practices.

      Lean thinking is an underpinning to my new agile requirements book. but I’m guessing much of that will simply be “assumed” in this series. But time will tell how the content flows in this series, as I still have to write it………..

  2. Dean,

    looking forward to your next post getting more into the actual life-cycle and do hope you will specifically address the typically phase-based approach of Design Controls and the challenges of that for Agile.

    Another aspect that would be valuable to get your thoughts on is the use of agile tools, whether it is RALLY or any other, and the gaps in Part 11 compliance. Those gaps make it somewhat cumbersome and essentially requires exporting a state to be able to document Design Inputs, Design Outputs, Traceability, Verification, Validation, etc. and even then it is still not without issues, e.g. holding different versions of requirements, test cases, etc.

    ciao,
    -mm

    • Michael,
      Indeed I do plan to cover all these issues, starting with an agile lifecycle model for design input, design output and design verification in the next few posts.

      Tooling will come later in the series, as you can’t automate traceability without effective tooling.

      –Dean

    • Great question Michael, I will add onto Dean’s comment that we are working on cross pollenating the Agile solution with the Rally solution as we work with industry experts like yourself. I look forward to meeting with you soon to review how you are using tooling currently. We are also excited to get there as well but we need to lay the ground work first as we do not have the day-to-day knowledge.

  3. Hi Dean,
    I can hardly wait for the next installment to this series. I have been looking for a way to adopt Agile methods in Medical Device Software Development for quite a while. I will also order a copy of the book. Thanks.

    Ron

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s