Greetings everyone, and welcome to the opening article in a series of blog posts concerning Medical Device Development using AGILE techniques.  I will begin by firmly stating that I am no expert on this subject.  I am, however, a successful practitioner of the subject and someone who has successfully delivered a respectable number of medical devices (software, hardware, and combination) using traditional waterfall methods as well as using AGILE methods.  This blog series is intended to discuss those experiences, examine application of industry standards, and ultimately show that, despite their perceived contradictions, medical devices can certainly be developed by a team practicing AGILE processes.

I will begin with a little information about myself.  I earned a B. S. degree in Computer Science at the U. S. Naval Academy back when the age of object-oriented design and development were finally coming into their own (yes, I pre-date C++!).  My professional life began as a Navy helicopter pilot, flying from the small flight decks of destroyers and frigates in support of a wide range of operations.  My final assignment in my nine-year military career was at the Navy’s test and evaluation squadron for airborne anti-submarine warfare in Patuxent River, Maryland.  This is where I developed a genuine interest in the analysis of requirements and system testing which would drive my career in the ‘real world.’  I have been a software tester, lead tester, manager of testing, business analyst, systems engineer, and V&V lead for various medical device companies for over 20 years now.  The teams I have worked on have developed various innovative methods for delivering radiation to patients with cancer, a system to move pathology into the digital world, a planning system for a type of hip surgery, a pump to help patients in cardiac distress, and another radiation oncology system to bring much needed treatment to some cancers for which no treatment previously existed.  I have seen many techniques, methods, and ideas for medical device development over the years, and my hope is that this series of articles will highlight some of the reasons that I have concluded that using AGILE for medical device development is the most effective way to bring the device to market.

To begin a discussion of AGILE software development in a regulated environment, it is imperative that we understand the guiding principles of each.  Much of the information and perspective into these practices is taken from the Association for the Advancement of Medical Instrumentation (AAMI) Technical Information Report (TIR) Number 45 (TIR 45 for short).  The title of TIR 45 is Guidance on the use of AGILE practices in the development of medical device software.  I will use a tag of [TIR 45] anywhere I reference information found in the report.  It is important to note that while TIR 45 is not a recognized international standard, the intent of the report is to provide recommendations for complying with national and international standards for medical device development.  I will attempt to further clarify points and offer personal experience in this blog series.


Let us dive in now and explore the two perspectives.  It is necessary to understand the key provisions of Agile to explore our ability to use the principles in our development activities.  Like the word AGILE itself, the AGILE perspective can be succinctly summed up in what is known as the AGILE Manifesto.  The manifesto ( states:

AGILE Manifesto for Software Development

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work, we have come to value:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

That is, while there is value in the items of the right, we value the items on the left more.

Anyone with a medical device development background will cringe when they first look at the manifesto, and the natural conclusion is that AGILE simply cannot be used for medical devices.  Regulatory standards mandate planning, documented processes, and paperwork to back up all levels of development.  AGILE seems to spit in the face of those standards, or does it?  I have found that while it is possible to study AGILE practices (and all the various methodologies associated with AGILE), a true understanding of the benefits of the principles is not achieved until you take part in the AGILE workflow and witness how each aspect of AGILE contributes to improved customer satisfaction.

The AGILE working group also developed Twelve Principles of Agile Software ( which give more detail to their manifesto:

Principles behind the Agile Manifesto

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity – the art of maximizing the amount of work not done – is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Some of these principles have no impact on medical device development and will not be addressed, but the applicable principles will be examined in context when we explore how to align the perspectives of Agile and Regulated Development in the next article.

Finally, it is useful to understand the goals of Agile methods as stated in TIR 45:

Agile’s goals are to provide benefits in any of the following areas:

  • Maximize product quality. Comply with specifications.
  • Maximize productivity. Improve delivered value at minimal development cost.
  • Increase predictability. Deliver on time with a known feature set.
  • Product effectiveness. Deliver a product that

Agile was not created with a particular class of software development in mind and thus it is incumbent upon practitioners of an industry which seeks to gain the benefits of this set of methodologies to understand how to apply the principles to their work.  If the creators of the manifesto would have target medical device development, chances are the resulting methodology would have been too heavy for the flexible process they set out to create.


Believe it or not, software used in medical devices was largely uncontrolled by regulations until the early 1990s.  A series of incidents in which several cancer patients were treated with approximately 100 times the prescribed radiation dose due to a software error led to the realization that government regulation of devices was needed (search for Therac-25 for details).  The sole purpose of regulation is to ensure the safety and efficacy of the devices to the patients, operators, and associated personnel.  Today, device regulation has various levels and device manufacturers are required to comply with these regulations to gain approval to sell a device to an area, country, or region.  While each set of regulations vary by location, they all follow the same basic guidelines and requirements (some more stringent than others).

Medical device manufacturers in the United States are required to comply with the provisions of 21 CFR 820 which is commonly referred to as the Quality System Regulation (QSR).  Compliance with the QSR is managed and enforced by the U. S. Food and Drug Administration (USFDA).  Subpart C of the QSR lists the Design Control regulations which form the basis for product development.  In addition to the QSR, USFDA expects manufacturers to comply with two international standards: ISO 13485 which establishes the requirements for Quality Management Systems for medical devices and IEC 62304 which contains the provisions for Life Cycle Processes for Medical Device Software.  If the device is intended for foreign markets, the manufacturer must also comply with the provisions of any additional standards enforced in those markets.

While there is no manifesto which provides a common vision for the regulatory bodies, most have aligned on the international standards and their own local regulations only deviate from the norm in small ways.  The general goal of all of these regulations is first to establish a systematic approach to managing the overall quality of the design, development, and introduction of medical devices (ISO 13485 and 21 CFR 820) and then to provide specific guidance for a risk-based development process to help ensure a safe and effective product (IEC 62304 and Subpart C of the QSR).  The USFDA also publishes informative guidance documents on its website to explain the agency’s current thinking on a topic or to further guide manufacturers in meeting the rather general requirements.

It is quite important to understand that several representatives from the USFDA participated (and even co-chaired) the committee that developed TIR 45.  While this representation suggests that USFDA is aligned with the guidance provided by the technical information report, it certainly does not constitute that the federal government endorses the document.  I was fortunate enough to attend training on the report at AAMI headquarters which was taught by an exceptional staff of instructors.  One of these instructors was Mr. John Murray, Jr. from the USFDA, and he was an awesome source of information and stressed the importance of remaining logical in decisions concerning the regulations.

The general process for medical device development is shared among all regulations and standards.

The basic process for regulated medical device development which is shared by most regulations/standards includes (using the QSR outline as an example):

  • Design and Development Planning – defines development activities, personnel responsibilities, and interfaces with other groups or activities
  • Design Inputs – establishes requirements for the device
  • Design Outputs – defines the deliverable portions of the device which are subjected to verification and validation
  • Design Reviews – held to review progress on the overall or individual subcomponents of the device
  • Design Verification – confirms that the design outputs conform to the design inputs (did we build what we defined in our requirements?)
  • Design Validation – confirms that the device meets the defined user needs and intended use(s)
  • Design Transfer – establishes procedures for correct translation from design to production
  • Design Changes – defines the process for identification, documentation, review, and verification/validation of proposed changes prior to implementation
  • Design History – establishes a repository for all documentation and records to demonstrate that the device was developed in accordance with regulations

The principles of regulated medical device development are also similar and reflected in each of the standards/regulations discussed.

Regulatory principles for software development:

  • Controlled processes must be followed to produce high-quality software
  • The level of rigor applied to the control should be commensurate with the level of inherent risk in the product
  • No particular development philosophy or methodology is mandated by any regulation or standard
  • The performance of verification and validation activities is expected throughout a development lifecycle
  • The development process should rely on management oversight/control, professional work, and training
  • Documentation is required to demonstrate compliance to regulations and facilitate investigation into software issues
  • Documentation is also required to allow evaluation of software design for regulatory approval
  • Planning is essential to ensure effective execution of the development process
  • Risk management activities are essential and should be embedded throughout the lifecycle

While it is not the intention of regulatory agencies to place unnecessary road blocks in front of medical device manufacturers, these same agencies rely on these regulations to ensure that products introduced into their domains are both safe and effective.


Thank you for staying with me through all of that!  Laying out the background and perspectives of each side will allow us to understand how to meet the rigor of one side (regulatory) while realizing the benefits of the flexibility of the other (Agile).  In my next article, we will examine exactly that: how do we align the two sides so that we can effectively get the benefits of both.

Please download a copy of AGILE – VS – REGULATED DEVELOPMENT blog.

Author:  Doug Hull