Exploring the Intersection: Agile Methodologies in Medical Device Software Development

Have you ever wondered if the fast-paced, adaptive nature of Agile methodologies could be harnessed in the world of medical device software development? 

Well, you’re not alone. In fact, it’s a question that’s been buzzing around the industry lately as technology continues to evolve and reshape our approach to healthcare.

You’ve probably heard of the traditional waterfall development method, right? It’s like following a set path, one step at a time, until you reach your destination. That’s been the go-to strategy in the medical device realm for quite some time. But here’s the kicker – software development doesn’t quite fit that mold. It’s more like a constantly evolving beast that thrives on flexibility and quick adaptation. Enter Agile.

Agile isn’t a new concept. It’s been around since 2001, born out of a need to break free from the shackles of rigid, documentation-heavy development processes. Think of it as a breath of fresh air in a room filled with stacks of paperwork.

But here’s the million-dollar question: can Agile practices really mesh with the highly regulated world of medical device software development? If we take it one step further, can agile in medical device software development spark a revolution? That’s what we’re here to unpack. We’ll explore the challenges, the opportunities, and the bridge that connects the two worlds.

So, buckle up and get ready to explore the fascinating intersection of technology, healthcare, and innovation. Because who knows? By the end of this journey, you might just be convinced that Agile is the secret sauce for revolutionizing your medical device software development.

Understanding Traditional Development Methods

Let’s take a step back and delve into the world of traditional development methods. You see, when it comes to building medical devices, there’s been a tried-and-true approach known as the waterfall method.

Imagine a cascading waterfall, each phase flowing seamlessly into the next. That’s the essence of the waterfall development process. 

It’s all about following a linear path, ticking off boxes as you go – design, development, testing, etc. It’s systematic, it’s methodical, but here’s the catch – it’s not exactly built for speed or adaptability. Here is a familiar diagram that describes the waterfall method:

As you see in this image, the phases of design flow from one to the other in a waterfall pattern. This is the step by step phase gate process that we discussed in our previous article, Step-by-Step Guide to FDA Approval for Medical Devices.  

Now, don’t get me wrong; the waterfall method has its merits, especially in industries where precision and predictability are paramount and long lead times are tolerated. But when it comes to the fast paced world of software development it’s like fitting a square peg into a round hole.

You see, software development thrives on iteration, on quick pivots, on the ability to course-correct on the fly. That’s where Agile comes into play, but we’ll get to that in a moment.

For now, just picture the waterfall method as the old guard – reliable, steady, but perhaps a bit too rigid for the ever-changing landscape of medical device software development.

Introduction to Agile

Now that we’ve got a handle on the traditional waterfall method, it’s time to shake things up a bit with Agile.

So, what exactly is Agile? Born out of a desire to break free from the shackles of heavy documentation and rigid processes, Agile came about in 2001 when a group of developers came together to dream up a better way. What emerged was the Agile Manifesto.

At its core, Agile is all about adaptability, collaboration, and continuous improvement. It’s like a well-oiled machine that thrives on feedback and iteration, rather than sticking to a predefined plan come hell or high water.

Now, here’s the beauty of Agile – it’s not just a set of rules or methodologies. It’s a mindset, a philosophy, a way of approaching development that puts people and interactions above processes and tools. It’s about embracing change and uncertainty, rather than shying away from it.

And that’s what makes Agile so intriguing in the world of medical device software development. Sure, it might seem like an unconventional fit at first glance, but when you peel back the layers, you’ll see that Agile has the potential to revolutionize the way we build and deploy medical devices.

Let’s keep exploring the exciting world of Agile – where flexibility reigns supreme, and innovation knows no bounds.

Challenges of Implementing Agile in Medical Device Software Development

Now, let’s talk about the elephant in the room – implementing Agile in the highly regulated world of medical device development.

While Agile might sound like a breath of fresh air, it’s not without its challenges, especially when it comes to navigating the regulatory landscape.

In Your Guide to Understanding Software as a Medical Device (SaMD), we discussed several regulations and requirements that must be met when developing Software as a Medical Device (SaMD), including:

• ISO 13485
• IEC 62304
• ISO 14971

ISO 13485 outlines quality system requirements, including design controls. However, it was developed to be applicable to a wide array of medical devices, from bandaids to pacemakers, which can make it challenging for developers of SaMD to understand how to create their development processes in a way that meets these requirements.

IEC 62394 complements ISO 13485 by addressing specific considerations of software development in medical devices. However, as we can see from the typical development process depicted below, the process remains very linear, comparable to the standard medical device waterfall development process.

This linear approach often consists of writing extensive and inflexible requirement specifications, design specifications, testing, and integration plans, with little room for iteration – a stark contrast to the iterative nature of Agile.

So, where does that leave us? Are Agile practices doomed to fail in the world of medical device development? Not necessarily. In fact, there’s hope on the horizon – AAMI TIR45. But we’ll save that for later. 

For now, just know that while Agile may pose some challenges in the realm of medical device development, it also holds the promise of unlocking new levels of efficiency, collaboration, and innovation – if we’re willing to rise to the challenge.

Implementing Agile in Medical Device Development

It’s time to roll up our sleeves and dive into the nitty-gritty of implementing Agile in the world of medical device development.

At its core, Agile is all about flexibility, collaboration, and iteration. It’s like a well-choreographed dance, where developers, testers, and stakeholders come together to deliver value in small, incremental steps.

Agile adopts an evolutionary approach to software development, as seen in the figure below of the Evolutionary Life Cycle process. While some might say this is incompatible with medical device development, this theme of continual improvement is a foundational element of modern quality: obtain feedback and improve upon your product.

It is important to note that the authors of the agile manifesto clearly state that processes, documentation, and planning were still valuable, just that they should support the more valuable outcomes of functioning software, customer collaboration, and ability to change. So we can start to see how Agile might actually be compatible with Medical Device development afterall.  

But, more importantly than the processes (see what I did there?), the importance of developing high quality software is fundamental to the Agile methodology, medical device manufacturers, and regulators alike. 

So, how do we make Agile work in the highly regulated world of medical devices? Well, it starts with breaking down the process into manageable chunks – what Agile aficionados like to call “stories.”

A story is like a mini-mission, describing a specific action or set of actions that the software should perform. It’s the building block of Agile development, guiding developers through the iterative process of designing, coding, testing, and refining.

A story describes a specific action or set of actions that the software should perform based on a predefined input from the perspective of a user in the format: “As a [user or connected system], when I [perform an action], [what the software does, displays, or executes]”. 

But here’s the beauty of Acceptance Test-Driven Development (ATDD) – it allows you to define tests based on the acceptance criteria for each user story before you even start coding. This means you’re essentially setting the parameters for success before diving into the implementation phase. It’s like having a roadmap to guide you every step of the way, ensuring that your code meets the specified requirements right from the start. Since the story is both the requirement and the specification for the software, it is often fulfilling the role of both input and output.

Agile Documentation

Now, let’s talk about documentation. I know, I know – it’s not the most exciting topic. But when it comes to SaMD, documentation plays a crucial role in ensuring compliance with regulatory requirements.

From architecture diagrams to software requirements specifications, documentation helps bridge the gap between Agile practices and regulatory requirements. It’s like the glue that holds everything together, providing a map of the inner workings of the device for developers and regulators alike.

So, when you’re sprinting through user stories and crafting the perfect software design, documenting your processes and decisions is critical to the success of any development program, especially under the Agile framework. The documentation that is expected for medical devices can still be recorded while following an AGILE process that embraces change, fosters collaboration, and ultimately delivers better outcomes for patients and practitioners alike.

Bridging the Gap: AAMI TIR45

That brings us to one of my favorite standards publications (yes I’m a big enough regulatory geek to have a favorite standard 🤓) AAMI TIR45 – Guidance on the use of Agile practices in the development of medical device software.    

While not a standard per se AAMI TIR45, titled “Guidance on the use of Agile practices in the development of medical device software,” serves as a bridge between the old-school waterfall approach and the modern Agile methodologies.

Think of it as a guide that helps developers navigate the murky waters of regulatory compliance while embracing the flexibility and adaptability of Agile.

So, what does TIR45 bring to the table? Well, for starters, it provides much-needed clarity on how Agile practices can align with regulatory requirements. It’s like having a translator in a foreign land, helping you decipher the language of regulations and standards.

As AAMI TIR45:2023 wisely states, “Documentation is a means of communication. Its value is defined by the information it communicates, as determined by the people it is communicating between.” 

TIR45 isn’t just about ticking boxes and checking off requirements. It’s about fostering a culture of collaboration, innovation, and continuous improvement – all while ensuring compliance with the strict regulations governing medical devices.

One of my favorite diagrams in the TIR (see I told you, regulatory geek!) is this one visualizing how and where all of the activities of 62304 are occurring in an Agile development process.

As this diagram shows, in Agile all of the required activities are being accomplished. It’s just a matter of ensuring that you understand and are able to properly describe what these requirements look like in Agile documentation, ensuring that any particular regulatory requirements are met (i.e. 21 CFR Part 11).  

At the story level we see that besides the planning of the story itself, the rest of the development activities blend together into an indistinguishable body of documentation. These stories are often quite detailed and describe the smallest piece of work for a developer, all centered around the acceptance test that the feature will need to pass.

At the product level these activities are more distinct. 

So, at the product level, we have the ability to extract what is needed to create some of the design documents that will be needed to pass audits and regulatory approvals. These documents include architecture diagrams, software requirements specifications (SRS), and software design specifications (SDS). More on documentation in another episode.

Embracing Agile for a Healthier Future

And there you have it – a whirlwind journey through the intersection of Agile methodologies and medical device software development.

From the rigid confines of traditional waterfall methods to the dynamic landscape of Agile practices, we’ve explored the challenges, the opportunities, and the bridge that connects the two worlds.

But here’s the thing – Agile isn’t just about building better software. It’s about building a better future – one where innovation thrives, collaboration flourishes, and patients reap the benefits.

Sure, implementing Agile in the highly regulated world of medical devices isn’t without its hurdles. But with guidance from standards like AAMI TIR45 and a commitment to continuous improvement, we can pave the way for a healthier, more agile future.

As we have seen, there actually is a way to implement Agile practices in medical device development. Maybe the Medical Device software industry can’t be like Mr. Zuckerburg and “move fast and break things”, but we can move fast and build safe things – making the world a healthier place along the way.

So, whether you’re a developer, a regulator, or a healthcare provider, I challenge you to embrace the principles of Agile – to adapt, to collaborate, and to innovate.

Ready to take the next step? Contact Fission Consulting today to discuss how we can help you implement Agile practices in your medical device development process or assist with any other needs you may have. Let’s harness the power of Agile together to revolutionize medical device software development – one sprint at a time.