Back in the stone age when I was a software developer and also learning about medical device regulation (and now I’m doing it full-time, what happened to my life), our main question was whether we could document our existing software retrospectively.
Here’s how a typical situation at a medical software startup unfolds:
- Software is developed.
- People realize it’s a medical device.
- Everyone runs around like crazy chicken.
- They talk to various crappy consultants who tell them “yes, you have to re-do everything after you’ve set up your QUALITY MANAGEMENT SYSTEM”, whatever that is. Note that none of those consultants have ever written code themselves.
- The startup people throw their hands in the air, start re-developing the software while filling out crappy Word templates they purchased for thousands of Euros.
Needless to say, don’t be like those people. Just document your software retrospectively; everyone does that.
The most important part here is that the software (or large parts of it) have already been developed. This is not because startups are stupid (some consultant dinosaurs believe so), but because technology has made it cheaper to just develop software instead of doing lengthy planning. This point is important. Nowadays, people can go off and just write some code and come back with a decent product, while in the past, you had to gather a committee of 100 people in brown suits to come up with some sort of waterfall-like software development plan which would then be distributed to another 100 people not in brown suits (the developers). Again, let me repeat: It’s cheaper to develop software than to plan it nowadays. And that’s a good thing!
However, it doesn’t line up with medical device regulations. The IEC 62304, the standard for software development and documentation, was last updated in 2006, that’s almost 20 years ago. And it’s probably fair to say that, even in 2006, it was not very innovative.
So. What to do?
One moment! Two quotes and one disclaimer first.
How Auditors And Big Corporations See Retrospective Documentation
Below, I will show you how to do retrospective documentation. If you’re now going to cry and say “but that’s not the way it was meant to be done, this is about quality management (whatever you mean by that), blablabla”, my reply is this: I’m just showing you how, in my experience, 100% of medical device software projects are being documented nowadays.
Retrospective documentation, for the first product, is pretty normal, and one auditor even openly acknowledged this to me.
Retrospective documentation is pretty normal for the first product of a company becoming a medical device manufacturer.
Auditor Dude
If you think big companies are different, I have another quote for you:
At BigCompany, many of our new products actually originate from random University research projects which are often written in MATLAB. So the challenge is to go through that crappy code and actually create documentation for it.
Big Company Dude
So.. retrospective documentation is actually pretty normal in the industry. Who would’ve thought. Maybe because developing software is cheaper than planning it.
So how do you do retrospective documentation?
How To Do Retrospective Documentation
It’s very simple. Just create all the documentation as if you’d be about to start your software development. The main documents for this are the User Needs List, its Review Checklist, the Software Requirements List and its Review Checklist. So, you’d fill out e.g. the User Needs List so what it would contain the actual user needs your software currently fulfils.
Your question now likely is: But wouldn’t the auditors check the dates of when those documents were signed, and wouldn’t that seem super weird? Also, won’t they check the dates of when your code was written, i.e. the git commits?
Let’s look at those in order.
The only important part for your first audit is that the review checklist is signed before the actual list. So, for example, you should sign your Software Requirements Review Checklist before you sign your Software Requirements List. You do that because, in your SOP for software development, you yourself already stated that you’ll perform a review of your software requirements before you actually sign them (right.. remember?). So you’re just adhering to your own process, and that itself is compliant with the IEC 62304.
Git Commits
Now, what about those git commits and their dates?
The funny thing, if you read the IEC 62304 closely without falling asleep (not easy), it doesn’t state that your code implementation has to happen after your planning activities. In other words, you’re fully 62304-compliant if you’ve already written some code before writing the documentation for it. Either the authors of the standards were surprisingly smart, or this was an oversight. In any case, auditors tend to not be very technical (crazy, right), so they likely don’t understand git anyway.
Summing Up: Retrospective Documentation Of Your First Product
So this is how you retrospectively document your first product. It’s not only possible – it’s how pretty much all companies operate nowadays.
Still not convinced? Let me ask you this: How do you do your tax return? Do you do it once at the end of the year, or do you touch it every day and change the numbers based on how much money you made just made in the last few hours? The latter approach sounds terrible inefficient, because you suddenly spend all your day’s time updating your tax return and not actually working.
The same is true for medical device documentation: If your goal is to create it “while developing your product”, this will be terribly inefficient, because your product is constantly changing; especially the first version of your product, where entire user groups and features might change! If you still think that’s what you want to do because either you have a weird concept of quality management or a consultant told you so (who himself has a weird concept of quality management), well.. good luck. Developing software is slow enough, and you just made it much slower.
Now. This works for the first version of your product, because technically you weren’t a medical device manufacturer with a certified quality management system at this stage. How does it work for subsequent versions of your product once it’s on the market as a medical device?
Documenting Subsequent Medical Device Versions
It’s simple. Before you start working on a change, you should document something called a change request (link to template) in which you, well, describe the change and evaluate whether it’s significant – if it’s significant and you’re class IIa or higher, you need to involve your auditors, but that’s a topic for another day.
Cool. Once that’s done, my recommendation would be that you let your developers do their thing and get out of their hair, because they have enough on their plate already.
Note that you don’t ship any software in the meantime – you’re developing your new version. In technical terms, you’re working on a new branch in your git repository which hasn’t been deployed yet.
Once your new version is mostly ready and its features aren’t going to change very much, only then you start documenting everything. Similar to your initial documentation, you now update the User Needs List, fill out and sign its Review Checklist again, update the Software Requirements List and fill out and sign Review Checklist again, too.
Once your documentation is again “in sync” with this newest version, you ship your new version. That’s all.
One important note though: You have to keep your old documentation around – in other words, you need to archive e.g. your User Needs List for every past product version. This is either painful or tricky in most documentation software. That’s why I’d recommend you use our eQMS software Formwork which takes care of everything for you.
This approach should still enable you to ship every 2-3 weeks (not much less than that) which is probably the fastest I’ve seen in medical device companies (it’s a slow industry).
Hope it helps. And leave a comment below if you have any further questions!
