Ahh yes, I get this question quite often, especially from the Jira / Confluence crowd. Those people tend to already have an overly clunky development process with all sorts of sprint planning committee meetings, so it’s only logical to assume that those same people would be interested in making their Jira setup even more complex by bolting some regulatory automation on it.
The idea behind it is this: They continue to work in their clunky Jira, and while they do their thing (sprint planning meetings etc.), some sort of regulatory automation runs in the background and, tada, perfect technical documentation comes out on the other side which can be handed in to their auditors.
If you haven’t noticed by now, I’m very skeptical of this approach, and now let me tell you why.
The overarching goal of these people, understandably, is to create their technical documentation as fast as possible. That makes sense, because no one (only weird people) enjoy writing technical documentation. The problem, however, is that automation is not the activity with the most leverage when it comes to creating your technical documentation fast.
Time Savings Of Automating Technical Documentation
If you’d attempt to automate the creation of your technical documentation, you have an upfront time cost, and also an ongoing maintenance time cost – regardless of the tools you choose (this includes ChatGPT etc.). So.. even if you craft a perfect LLM prompt or the perfect Jira API integration with your regulatory tool, you still have to spend a significant time on actually creating that and maintaining it (this stuff breaks often).
How much time savings will you get out of this? Mayyybe 20%, give or take. Probably less than 30%. Maybe even less than 0% if you spend too much time fiddling with your tech setup!
Okay. What else can you do? And this is the really important point.
Speeding Up Technical Documentation By 10x (Without Tech)
You could just document less. Yup. Auditors will hate what comes next.
See, typical medical device manufacturers tend to over-engineer their documentation, especially when it comes to Design Inputs (or Software Requirements, depending on how you name them). Design Inputs typically looks like this:
- Doctors can log in with Google.
- Doctors can view radiology images, pan and zoom, etc.
- Doctors can write patient reports and save them.
- Etc.
So Design Inputs essentially boil down to “a list of features” (software dinosaurs call this a “specification”), and it’s a regulatory requirement that you have such a list. Okay.
But now my point is this: Some companies choose to write 200 Design Inputs, while others write 20. Both pass audits. The level of granularity is up to you.
And just right there, you have an efficiency leverage of 10x! Much more than anything you’d ever achieve with automation.
And this thinking can be applied to many other aspects, too – User Needs, Post-Market-Surveillance, Literature Research, etc. Just focus on what’s necessary.
Remember, your goal is to bring a safe product to market, not to write the world’s nicest and lengthiest regulatory documentation.
Reduce scope before you even consider automation.
