Accelerating Medical Device Development

Featured images: doctors performing open heart surgery (source: Dojo Five), Minnesota Twins winning game 7 of the 1987 World Series (source). Compare your company developing a successful medical device to a championship sports team. Sports teams” like companies ” use culture, processes, and tools and shape their trajectory.

Joe Schneider, founder of Dojo Five, recently spoke at MedFuse 2019 with Patrick Miller, Principal Systems Engineer at Cardialen, about Accelerating Medical Device development. Together, we designed and developed a low-energy cardioversion stimulator in 5 months. This will be part of a series of posts on medical device development. To support our claims, we will be surveying The Waddell Group™s Project Managers who have completed 635 medical device projects over 17 years.

We’re sharing these insights to help you and your team. The Dojo in Dojo Five represents a place to learn from martial arts masters. Cardialen shares this value and also wants to open source their experience so your team can also make safe and innovative products faster with a combination of cultural, process, and tool changes.

Medical software has historically had longer release cycles than consumer web development (one of the fastest-moving fields) due to regulation, antiquated tools and processes, and hardware dependencies. This no longer needs to be the case. Our accelerated development with Cardialen was not an accident, and these results scale. Joe Schneider, founder of Dojo Five, spearheaded the developer efficiency initiative at John Deere with a distributed team of 800+ developers. Case studies show that John Deere saw the following improvements:

• Time to market: 42%  
• Warranty expense: 50%  
• Time to production: 20%  
• Field issue resolution time: 42%  
• Employee engagement: 9.8%

Moving fast in a highly regulated environment

Cardialen™s low-voltage heart defibrillator is a Class III medical device, the most strictly regulated. Class III medical devices support or sustain human lives, such as implanted pacemakers, heart valves, and implanted cerebral simulators. Our cultural, process, and tool recommendations follow several regulatory standards, but it’s important to highlight the following:

ISO 13485 – designed to improve quality via a Quality Management System (QMS) that documents implementation and maintenance of a medical device, such as:

• Risk management and design controls during product development.
• Traceability for Class III devices.
• Documentation and validation of medical device production processes.

ISO 14971 – designed to reduce probability and severity of harm through inherent safety by design, protective measures in the device itself or manufacturing process, and safety information, such as:

• Ensuring connectors cannot be connected to the wrong component.
• Removing features that can be mistakenly selected or eliminating an interaction when it could lead to use error.
• Improving the detectability or readability of controls, labels, and displays.
• Automating functions that are prone to manual error.

• Incorporating safety mechanisms such as physical safety guards, shielded elements, or software or hardware interlocks.
• Including warning screens to advise the user of essential conditions that should exist prior to proceeding with device use, such as specific data.
• Using device technologies that require less maintenance or are maintenance free.

• Providing written information, such as warning or caution statements in the user manual that highlight and clearly discuss the use-related hazard.
• Training users to avoid the use error.

IEC 62304 – designed to improve medical device software development lifecycle (SDLC) processes, such as:

• Planning the software development
• Preliminary risk analysis
• Figuring out the software architecture
• Assessing software safety risk class
• Developing / risk managing per risk class

These regulatory standards guide your development process, but remember a tool is not a process, a process is not a tool, and both are only as effective as your culture allows. Compare your company bringing a device to market to a championship sports team. These teams, like companies, foster a winning attitude and team culture, follow processes such as workout / rest intervals and diet regimen, and use various tools and equipment to shape their season’s trajectory. It seems more obvious in athletics that your shoes and bat are only effective as your decision making, let alone your winning attitude or how you practice, eat, and sleep (process and culture). How many championship teams have you heard talk about their superior equipment?

Minnesota Twins celebrating the 1991 World Series (Source)

In the world of software, we love to talk about tools (comparable to an athlete’s shoes – marginally important to winning a championship). However, there are no guarantees that by simply using JIRA your team will bring a quality product to market faster. Tools and processes are only as effective as your company culture allows.

Typical issues we see:

• Cultural:
  • “Design by committee” which can create unclear priority for discovered risks during development and compounds slow turnaround from stakeholders.
  • Managers stonewalling changing of requirements out of fear of scope creep or changing the original plan (sometimes based on their opinions rather than the customer learnings)
  • Development in isolation and, what we call, the Big Bang integration which typically requires fixes and pushes deadlines
  • Endless high pressure deadlines without traceability / accountability (particularly in embedded code) sometimes leads to defects being hidden or attempted to be fixed before discovered, or at least not discussed immediately
• Process and tools:
  • Manual builds with tribal knowledge of how to get things working
  • Overly complex tech stacks, setups, or mandates on certain technologies that may not be the best solution, therefore delaying timelines and decreasing developer happiness

Typical results: 3-7 years for putting devices into the field.

Typical solutions:

• Cultural:
  • Leadership delegates device design with high accountability.
  • Embrace changing requirements as part of the agile process.
  • Accept incremental defects during development, prioritized by risk.
• Processes:
  • Clearly define Intended Use, users, and user needs
  • Integrate the system(s) as early as possible.    
  • Incremental code and requirements reviews.
  • Automate firmware builds and tests and hardware simulation when necessary.
• Tools:
  • Adopt risk-based framework for requirements, testing, and issue prioritization
  • JIRA for requirements, hazard and risk analysis
  • Gitlab
  • GitHub Actions
  • BitBucket Pipelines
  • Jenkins (if restricted to on-premise automated firmware builds)

Typical results: >1 year for shipping devices. *Note: not all of these may apply to you, nor are they the “final answer”.  These timeframes are for shipping an internally verified, production-grade device. These times will vary based on complexity and which regulatory processes that apply to you.

Leadership delegates device design with high accountability

A “design by committee” environment may include stakeholders that may not fully understand the technical limitations behind their requests. Sometimes stakeholders come and go. Switching to an environment where the point person is ultimately responsible but still gets buy-in requires a high level of trust, but creates shorter decision loops with the development team. Crafting a set of requirements free from design and/or implementation is critical to enabling the design team to flourish.

We define requirements in the strictest sense. For example, if the product was made any other way, the product could not be shipped. Requirement need to be rewritten to a functional level and lead the designer to a clear, testable performance. Achieving this depends on your organization, timing, and the amount of pressure on the specific project – e.g. are you trying to change how things are done on the flagship product with a critical release window, or is it a small project that you can work out the kinks and likely be successful with?

Clearly define Intended Use, users, and user needs

Ensuring everyone on the development team clearly understands the Intended Use, user personas, and which user needs are in scope is often overlooked. This simple context drives all development and can be lost / forgotten after the kickoff session – write it down where people see it often and have people recite it back in their own words to ensure understanding.

Embrace changing requirements as part of the agile process

Most teams operate as though the code is agile yet requirements are fixed. We consider requirements part of the agile process which are reviewed after each mature release. This is a jolt for some teams, particularly management (depending on their level of trust and involvement). At best, it’s received as not following a plan. At worst, it comes off as the product straying from its initial purpose. Building off of fluid requirements requires cultural changes that imbue trust and high accountability between the management, product, and engineering teams. Consider getting air cover from your boss to work out the kinks on a pilot project that has a high chance of success.  

Accept incremental defects during development

Medical software sometimes has long development cycles with unclear accountability for whose code broke what. This can create a murky, defensive culture especially when timelines get tight. A CI pipeline with automated tests and monitoring creates visibility and accountability into each code commit, and regular demos to stakeholders highlighting defects prioritized by risk grounds backlog discussions.

Adopt a risk-based framework for requirements, testing, and issue prioritization

To extend the FDA’s risk-based framework, we prioritize incremental issues by the likelihood, frequency, and impact of their risk to the user. Tease out potential issues by reviewing requirements with the QA team ahead of time and highlight incremental issues during demos to ground the roadmap and backlog grooming discussions.

Integrate the system components as early as possible

Integrating the system early uncovers unforeseen scope and potential issues. Unforeseen scope causes delays, which reduces management’s trust and a cascade of events that result in undoing of cultural, process, and tool progress so far.

Implement incremental code and requirements reviews

We’ve attended long code reviews with endless paper printouts and notes. Those days are gone. Using junior / senior developer pairs, a CI pipeline for builds, and automated tests, we can typically identify trouble spots early. Our embedded code reviews look like this:

We also regularly reviewed requirements with each mature release because a simple design / tech stack / architecture is easier to iterate, test, and defend against security threats. Any software or requirement changes may need to be documented in the Quality Management System per regulatory standards.  

Automate firmware builds and tests in a Continuous Integration (CI) pipeline

One of the first things we do for new customers is set up an automated build and test pipeline which usually takes less than a week. Web developers have been using these processes for years and although many embedded developers have heard of them, they likely haven’t seen or used them. Failing and passing commits look like this:

Benefits:

• Improved cross-team interaction through analytics, instant visibility and accountability to the state of the system.
• Hardware + peripherals simulation that can run unit and system tests  
• Continuous deployment to flash QA devices with builds that pass unit and system tests on the hardware simulator in the cloud
• Hardware-in-the-Loop (HIL) testing can be added as, once the build passes automated tests against the simulators, a hex file can be flashed to the QA devices.

Recommended tools for an embedded CI pipeline: GitHub Actions, BitBucket Pipelines, Jenkins (if restricted to on-prem), and/or GitLab. With automated firmware builds, you can easily trigger document storage off successful builds, and add golden release tags.

…

We designed and developed a low-energy implantable defibrillator with our customer Cardialen in 5 months using these cultural, process, and tool changes. Your company can also make safe, innovative products faster.

We can help you accelerate your medical device development.

Check out our services    |    Check out our Emedded CI Platform

Or contact us at [email protected]

Established in 2008, Cardialen, Inc. is developing a low-energy implantable defibrillator designed to more gently restore normal heart rhythm compared to today’s high-energy defibrillators. The Cardialen Multipulse Therapy (MPT) therapy delivers a sequence of low-energy electrical pulses designed to stop abnormally rapid heart rates.

Sources / references:

ISO 13485:2016 requirements: https://www.iso.org/standard/59752.html

ISO 14971:2019 requirements: https://www.iso.org/standard/72704.html

IEC 62304:2006: https://webstore.iec.ch/preview/info_iec62304%7Bed1.0%7Den_d.pdf

FDASIA Health IT Report Proposed Strategy and Recommendations for a Risk-Based Framework: https://www.fda.gov/media/87886/download

Published with permission from Cardialen, a valued customer of Dojo Five. Created with love for the embedded community.