Ah yes, agile development of medical device software, the million dollar question and a question where every regulatory consultant seems to have a different answer. The first problem seems to be that no one can even agree on a definition of “agile” development. But let’s just assume this problem doesn’t exist and define agile development as something like “you change your software all the time with very low overhead”.
Based on this definition, you can’t do agile development for medical device software. Let me show you why by looking at an example.
Let’s Look At Some Data: Agile Development vs. Compliance Documentation
The typical data you generate during agile development is something like user stories or tickets, in whatever project management system you use (maybe Jira.. ugh). It might look like this:
User stories:
- As a user, I want to log in with Google.
- Fix the login bug.
- As a user, I want to get reminded before my subscription renews.
So far, so good. Now let’s look at what sort of documentation is required for regulatory compliance for medical device software. In this case, the closest thing resembling user stories would probably be user needs or design inputs:
Design inputs:
- Users can log in with email, Google or Facebook.
- Users can subscribe online. Subscriptions cost 100€ / month. Upon renewal, an email is sent to the user.
Do you see the problem? If not, look again (or just consider reading).
Agile user stories typically describe changes – they assume that the reader already has a good idea of what the software currently does. The target audience is your team, i.e. software developers and product managers. This makes sense, because you don’t want to re-explain the entire software to your team all the time (duh).
The problem, however, is that if you’d now go ahead and say “cool, I can just re-use all of this for my regulatory documentation”, export it to a spreadsheet and send it to an auditor, that auditor will have no freakin’ clue about what your software actually does. Like.. can you log in with Google, Facebook, email, or any combination of those? The auditor won’t know, because they have to “combine” all your fancy user stories into one coherent specification.
Instead, what they expect, is exactly that, a specification. That’s essentially a description of all the features your software has at a certain point in time.
I tend to be quite critical of the often-very-broken regulation of medical device software, but this aspect does make sense. Like, you need some way to explain to an outsider what your software does, and listing all your features and their behaviour seems like a sensible way to do that.
But that’s not what you do during agile development.
So that’s the problem.
And, if you’ve understood this aspect, you should be able to answer the next question, too: Which software should you use for agile development of medical device software? It’s a trick question.
Software For Agile Development Of Medical Software
Now that we’ve established that your outputs during agile development are very different form the required outputs for medical device documentation, it should be easy to answer the common question of “hey, which software can we use which helps us combine agile development with medical device compliance?”.
Let me rephrase the question: “hey, which software can we use which helps us combine logging into our bank account with cleaning our office toilets?”
Yeah, none. Because those things are totally separate. So why the hell would any sensible person want to fold those two activities into one software?
Somewhat surprisingly, the answer is “many people”. And, less surprisingly, those people tend to be avid fans of Jira, an overly clunky “software” tool which actually is so complex that you can combine your bank account features with cleaning your toilets in it.
Which doesn’t say that this is a great idea. It is not. Still, I wrote up my thoughts on Jira here if you’re interested.
For all other, more rational humans: Keep your agile documentation separate from your medical device documentation. Use separate software. Preserve your sanity. This is the only way.
I’ve consulted 100+ companies, and the best-performing companies (also in audits!) were those who kept those things separate. None of this means that you ship unsafe products or have bad regulatory documentation. It’s simply the most effective (and efficient!) way of staying safe and compliant.
If you have a different opinion, write a comment below! But please no abstract ramblings, I’d prefer real experience reports like “look, we combined it by doing X, it cost us Y amount of time and the audit result of Z”.
