Hey, I thought I'd share some of my learnings about setting up a QMS in Jira and Confluence as many companies have asked me about this in the past. It took me quite some time to write this, so I hope it's useful for someone here!
I'm a consultant for medical device compliance and have worked with 150+ companies, quite a few have passed audits with a Confluence and/or Jira - based QMS.
So how would you go about setting up a QMS in Confluence?
Generally speaking, you actually have three options:
Let's go through those in detail!
If you're set on using Jira / Confluence for your QMS (more on that below), this is likely the cheapest option. However, it's also the one which will take the longest and carry the most risk regarding not passing your audit.
Here's how you'd do it: You'd essentially have to go through all the regulatory requirements by yourself. So, for EU MDR medical device compliance, you'd download the ISO 13485 which is a PDF listing the requirements for quality management systems.
(Quick note: There's a small "hack" here of downloading the ISO 13485 through the Estonian website which saves you a lot of money.)
And then you'd go through each section and create custom ticket types for everything. E.g. for customer complaints, the ISO 13485 requires you to classify them as serious or not, so you'd add a dropdown selector for "seriousness" to your ticket type for customer complaints.
With that, I think, you already see the main drawbacks of the approach: Firstly, it's a ton of work, and secondly, there's no guarantee that your interpretation of the ISO 13485 in your Confluence / Jira QMS setup actually matches the interpretation of your auditor. So you might run into the situation that you've actually set up a QMS which doesn't pass an audit.
And, with all the work you have to put it, I guess you have to ask yourself whether it's worth it. In the end, your company probably wants to develop a product and make money, and setting up your QMS is only a tiny part of that.
You second option is to choose to extend Jira / Confluence features with a QMS plugin. The main features you're looking for here are compliant e-signing of documents and requirements and risk management.
For e-signatures, I've had quite a few customers use Komala for that. It seems to work reasonably well. However, I've talked to one auditor who mentioned that one of the companies they audited recently lost all their signature information in Confluence which obviously was a huge problem.
So there's definitely some risk here as you're "bolting on" functionality to Confluence which doesn't exist in its core, and you're essentially at the mercy of the companies which manage the plugins you've purchased.
For requirements and risk management, I've heard of SoftComply being used, but none of our clients chose it so far so I don't have any first-hand experience.
Generally speaking, this approach of Jira / Confluence with plugins works reasonably well. The main drawbacks as mentioned by an auditor recently are these:
Your third and last option is to choose another software entirely outside of Jira and Confluence. Personally, this is my preferred option because, as mentioned above, I've recently heard many negative opinions by auditors about QMS setups in Jira and Confluence. Also. the first approach of setting up everything from scratch is simply not feasible for most startups who can't spend unlimited time tweaking their own custom QMS setup.
The most common options here are OpenRegulatory Formwork, Greenlight Guru and Qualio. Of those, Greenlight Guru and Qualio have very intransparent pricing and lock their customer in quite heavily with year-long contracts, so startups are increasingly avoiding them.
The often-preferred eQMS software for startups is OpenRegulatory Formwork because it has a free tier, unlimited users and a lot of transparency (e.g. monthly cancellation).
The benefits of a separate QMS software outside of Jira / Confluence are:
Additionally, one often-cited idea is that Jira and Confluence might be beneficial due to better integration between software development teams. Integrating regulatory compliance documentation with software development work sounds great on the surface, but in reality, I haven't seen this work out well, even after consulting 150+ companies. Here's an interesting article on the topic.
So yeah.. it's possible, but not always a great idea. Here's another article which is quite critical of Jira QMS setups.
Hope this was helpful and happy to answer any questions!
Interesting, I didn't know about Scroll Documents, thanks!
HI @Oliver Eidel ,
There are a few Apps in Confluence that do electronic signatures but admittedly not many with proper versioning. Scroll Documents is one of the few.
For our customers we initially had to create a dedicated App for Comala to report the Change History Table inside the page, with independent versioning. (see. Change History Table link).
Anyway, eventually we decided to create our own document management system, designed specifically for the MedTech sector (See Document Manager Link), with electronic signatures, versioning and everything else.
At SoftComply we also have Risk Management tools for Jira, while for requirements we heard good feedback on R4J, and Xray for test management.
Your recommendation about the Estonian standardization website is great, we always do the same with our customers and we purchased several standards ourselves there. The fact that you can buy single licenses rather than the whole thing saves a good bit of money.
Disclaimer: yes I'm with SoftComply!
Hello @Oliver Eidel ,
Your article is really interesting and well argumented, thank you very much for that.
I simply regret that you forgot to mention your relation with OpenRegulatory. This disclaimer would have make your article even more transparent.
(I recently came across a new app designed specifically for medical industry - Document Control for Confluence).
Hello @Oliver Eidel,
Thank you for your opinion on Jira and Confluence. Your article does show some elements of guerrilla marketing 😃, since it’s largely about promoting your own solution, but the pitfalls you mention regarding the use of Jira and Confluence for QMS are still valid.
Speaking of guerrilla marketing, I am also the founder of a QMS consulting company, QMLogic, that helps clients in the Medical Device Industry with a focus on compliance and QMS automation.
Here’s my experience with Jira and Confluence.
I’ve undergone audits and CE certification for class IIa medical device software several times. Confluence tool can be used, and it hold up during audits. Using additional modules is essential; without them, I believe it’s unmanageable. For smaller companies with 50–100 employees, I think this stack is sufficient. There are quite a few manual steps involved, but if you update your SOP documents 2–3 times a year, it’s manageable, and Comala, K15t, and for example Digital Rose, will more than suffice.
The case is a bit different with Tech Doc and requirement engineering in Jira. Versioning and clustering requirements for individual releases can be tedious and product change is error-prone. And neither R4J nor Xray really help much with that. However, if you’re dealing with a small dev team of 5–6 people, you can set up a semi-manual process where you export the requirements, check them for consistency, save them as a PDF, electronically sign them, and that’s it.
One aspect that is even more important in any team than regulatory requirements is user experience and project management. Jira excels in how it enables people to collaborate on product development—it’s not just about writing down structured requirements and assigning them to individual releases. People work in teams, applying agile management methodologies from Kanban to SCRUM, sending tickets to one another, having QA transitions and linking automated tests to requirements that trigger during deployment to Bitbucket.
BUT
Teams won’t switch to another tool just because Jira lacks a digital signature; in fact, they’re not even concerned about whether the company passes an external audit 😅
So, you have three options: either you hack Jira and develop the missing modules, you change the team’s work habits and force them to work differently than they’re used to, or you connect Jira & Confluence with another software solutions enabling easy regulatory work.
The thing is that we're just criticising Jira or Confluence for things it wasn't originally developed for. I believe more in modular solutions and interoperability between various tools than in a one-stop solution that solves all of an organization's problems with a single software.