Agile Medical Device Development: Do or Don’t?
Content aspects
In this article we highlight two important differences between traditional organizations and agile organizations. These two content-oriented aspects demonstrate that working agile requires a different view and therefore a different approach to the same problem. These aspects are:
- “Continuish integration”
- Solution Intent
This article is the third of three articles explaining the differences between a traditional way of product development and a more agile way of product development. These articles are based on a survey conducted on agile product development with medical device companies. The previous articles on organizational aspects and process aspects can be found by following the links.
1. “Continuish integration”
When developing medical devices the typical approach is based on the FDA guidance with regards to Design Controls, mostly executed as a stage gate process.
Following the stage gates, first ALL User Needs are identified, reviewed and approved, then ALL Design Inputs are identified, reviewed and approved, etc. As a result, the entire scope of the product is moved from stage gate to stage gate. Going back to a previous gate is considered to be a change and a formal change process needs to be followed. A change control board will either approve or reject the change. As a consequence, moving this large batch from gate to gate is a slow process and can take months and sometimes even years before any result is visible.
In an Agile way of working the aim is to work in small batches that can be delivered in months, weeks or even days, called Iterations or Sprints. Each iteration adds an increment of the scope to the product.
At the end of each iteration there is an integration point, where – at least in software development – all code from the different teams is integrated. This integration point is the forcing function that verifies changes and validates assumptions across the entire system. Development teams invest in automation and infrastructure that builds, integrates, and tests every developer change and provides nearly immediate feedback on errors. This is called continuous integration.
A medical device however does not only consist of software. Typically 3 elements play an important role:
- Hardware
- Software
- Compliance (evidence to demonstrate regulatory compliance)
In Agile, the goal is to develop these aspects of a medical device in parallel, so at each integration point, hardware, software and compliance are in sync.
Systems, such as medical devices, that consist of hard- and software are far more difficult to continuously integrate because:
- Long lead-time hardware items may not be available
- Integration spans organizational boundaries
- Automation is rarely end-to-end
- The laws of physics dictate certain limits
Therefore “continuish integration” is suggested. The goal is frequent partial integration with at least one full solution integration each program increment (every quarter).
When developing medical devices, verification and validation (V&V) practices are an integral part of the quality and compliance process. V&V commonly occurs in a testing phase once the solution is completely developed. Instead of this work being performed separately following development, the Agile best practice is to integrate this work into the effort required to bring each Feature of the product to completion.
2. Solution Intent
Once people hear about the Agile value “working software over comprehensive documentation” for the first time, they seem to always remember that Agile is equal to not working with requirements. That’s a misunderstanding since it’s important to store, manage, and communicate the knowledge of current and intended behavior of the medical device. This is called Solution Intent. In Agile product development the Solution Intent includes both fixed and variable specifications and designs; reference to applicable standards, system models, and functional and nonfunctional tests; and traceability. A different approach from traditional product development where specifications need to be fixed up front.
Solution intent stores, manages, and communicates ‘what is being built’ and ‘how it will be built.’ It serves many purposes:
- Provides a single source of truth regarding the intended and actual behavior of the solution
- Records and communicates requirements, design, and system architecture decisions
- Facilitates further exploration and analysis activities
- Aligns the Customer, Agile Teams, and Suppliers to a common mission and purpose
- Supports Compliance and contractual obligations
Fixed intent represents the ‘knowns.’ They may be nonnegotiable, or they may have emerged during the course of development.
Variable intent represents the elements that allow the exploration of the economic trade-offs of requirements and design alternatives that could meet the need. Once established, these new insights will eventually become fixed requirements. Moving from variable to fixed requires gaining knowledge to make decisions.
An example of an excellent solution to store, manage and communicate the Solution Intent of a medical device is Cognition’s Guided Compliance solution called Cockpit.
An excellent framework to gain knowledge and make design decisions is the Rapid Learning Cycles framework. It implements the same iterative approach as Agile does. However where Agile focuses on delivering working product increments, Rapid Learning Cycles focuses on delivering knowledge. Closing Knowledge Gaps in short iterations – for example by doing a set of experiments – enables to make well substantiated Key Decisions with regard to alternative solutions.
Requirements and designs used for verification and validation are also captured in the Solution Intent repository.
- Verification determines that the current system increment was built according to the specifications captured in the backlog, and in alignment with the Solution Intent (i.e., we built the solution right).
- Validation determines if the increment’s backlog items meet the system’s fitness for use or Intended Use. (i.e., we built the right solution).
Traceability within the Solution Intent ensures the artifacts produced each increment (software, hardware components, etc.) address regulatory and compliance specifications, providing end-to-end traceability (evidence) that V&V requirements have been met.
Conclusion
Making the shift to “continuish integration” and implementing a Solution Intent repository is not a trivial effort. Two strategies help mitigate barriers to change.
First, many of the checks can be automated. Incorporating compliance tests into the automated build process ensures that the build does not pass unless the feature passes its compliance requirements. (And yes, even hardware-based systems can incorporate automation in the testing process.) This reduces manual verification and frees quality and compliance personnel to focus on higher-level activities.
Second, shifting to continuous V&V can be incrementally tested and refined in pilot projects—before the approach is implemented across all agency programs.
