There’s a lot of magical things that can be done with software today, accelerated by cloud services and use of AI coding tools. Taking advantage of them may appear to conflict with what the FDA expects.
Perhaps one might take advantage of such capabilities to address some healthcare challenges? Move fast, break things – doing it the agile way, it can be done. But what about that pesky patient safety thing? FDA has an opinion on that.
According to the aforementioned agency, software that deals with the diagnosis, prevention, monitoring, treatment or alleviation of a disease or injury may be considered a medical device. Can you, or perhaps more importantly should you continue to move fast and break things in an agile manner?
That’s where things get a bit complicated.
One could easily argue that creating software for use as a regulated Class II medical device necessitates use of a more traditional software development process than agile. Having been through it a few times now, I could be convinced of the accuracy of that statement.
When following FDA’s guidelines, one must do the following, during the lifecycle of defining, developing and deploying that shiny new world changing medical device that’s going to save lives:
- Quality management system
- Software Requirements
- Risk Management
- Verification and Validation
- Deployment
- Maintenance
How does all that fit into two week sprints and continuous deployment? There’s no version of software that we can identify as verified, validated and released. Doing all that every time you release something is not possible, right?
That’s the complicated bit. Get some coffee, it might help.
If I were to get on my soap box, as those that know me can attest that occasionally I am wont to do, I’d suggest that regardless of whether you’re building a medical device or not, there’s a lot we can learn from this. The Agile Manifesto says, among other things, that one should value “individuals and interactions over processes and tools” whereas the FDA expect a Quality Management System that adheres to ISO 13485 that is all about clearly defined processes that are strictly adhered to for safety reasons.
Rock, hard place.
Let’s set this regulated medical device business aside for a moment and consider the world of continuously delivered software that works…kind of, most of the time. Is it ok to break stuff? It shouldn’t happen, when all those unit tests say it’s good and your code coverage is high enough, but it still does. In my experience, the issues might be due to the misalignment of teams, the not-always-smooth relationship between product management and engineering, the impact of new staff ramping up, and that technical debt thing. Valuing individuals and interactions over processes and tools is great, but when the team gets larger, they start to really want clear processes and tools.
Perhaps Agile methodology and ISO 13485 can get along? Yes, that’s what I’m suggesting and what I’ve experienced directly and the result was impressive.
The manifesto says value individuals and interactions over processes and tools not instead of. I know I’m stating the obvious, but its become clear to me that this has been used as an excuse, and that we’ve collectively ended up with more breaking things than we’d care to admit in our effort to move fast. I’m an advocate of move fast, with intention and a belief that documenting what you’re doing as you go along is what we should be embodying. It’s clearly not as catchy, I’ll work on that, but hopefully my point is clear.
Here’s what I suggest as a starting point:
- Establish the expectation that documentation is just as vital as the software
- Refine your tools to accommodate documentation assets in the same way you manage user stories and tasks (in Jira, or similar)
- Automate the creation of traceability documents that link requirement, to design, to verification and validation, to delivery
- Incorporate risk analysis into the discovery and design processes
My goal is to point out that it is feasible to generate assets required by a QMS for regulatory purposes as you go along, but more importantly don’t just do so because the FDA expects it, do it because it will result in better software and a business better equipped to execute.