Question

We’re already using Confluence and Jira for our development planning. Now we need to set up a Quality Management System (QMS) for medical device compliance (e.g. ISO 13485). Can we set up that QMS in Confluence? If so, how do we do it and would you recommend it?

Short Answer

Don’t do it. Jira sucks, and Confluence sucks, too. I don’t see how any rational human could choose these tools for daily use unless being blackmailed or under the influence of probably-illegal substances.

But, for some reason, you’re already using those tools. I’ll stop my attempt of trying to understand that. Moving forward..

Yes, it’s possible to set up your QMS in Confluence and Jira. You’ll need some additional tools though, and most importantly, don’t expect a lot of automation. Most people who go down this route think that they can “automate their regulatory documentation” - that won’t work. It’ll still be a manual process. In that sense, there isn’t much benefit in using Confluence / Jira. I’d say, all factors considered, it’ll end up being a bad decision.

Long Answer

Okay, so the typical consulting client who approaches me for this has the following thoughts: “Yo, we’re already using Jira for our development planning, and, with a few minor tweaks and some magic, we can auto-generate all our regulatory documentation in Jira and Confluence, too. That’s why we want to set up our QMS in Confluence”.

So there are two different aspects at play here. Let’s try to isolate them and discuss them separately. Firstly, there’s the goal of automating regulatory documentation, secondly there’s the idea of using Confluence because you’re already using it.

1. Automating Regulatory Documentation With Confluence as QMS Software

Automating regulatory documentation is a huge topic, so I’ll just focus on a few examples.

You’ll probably be using Jira as some sort of (crappy) ticketing system already, setting up fancy Kanban boards and adding agile (under-)estimations to your tickets. And you’re using Jira for that - damn. Okay.

Now you’re wondering: If we have all these tickets in Jira, can’t we just use all of those for our IEC 62304 software requirements documentation? The answer, unfortunately, is no. Because the the IEC 62304 requires your software requirements to be more like a specification, and less like user stories.

Concretely, a simplified 62304-compatible software requirement could look like this:

“There’s a login screen which has two text fields: Email and password. Upon entry of a successful combination, the user is redirect to the dashboard”.

Now, unfortunately, the typical ticket in an agile environment is a user story and looks like this:

“Fix the login screen. Also add login with Google, if possible.”

So we have a problem. The main problem is that, if you’d export all your tickets (= user stories) from Jira, and give them to an auditor, that auditor would read all those user stories and still have no clue how your current software actually looks like. That’s because user stories describe changes, not absolute specifications for a specific version.

Of course, that’s not a Jira-specific problem! That’s an agile-specific problem. But the core of it is this: When developing software as a medical device in an IEC 62304 - compliant way, you won’t get around writing a separate software specification (= software requirements), even if you already have fancy user stories. Again: Regulatory documentation means having to create many things from scratch. That’s the way it is. You can’t re-use your user stories, and you can’t re-use your existing tickets.

So Jira and Confluence don’t provide any benefits for automating your regulatory documentation. Now, keeping that in mind, do Jira and Confluence have any benefits?

Maybe. I’d say, if you, for some obscure reason, like these tools, your main benefit would be that you continue working with tools you like. But there’s no objective benefit to using Jira / Confluence as your QMS software. None at all.

Which brings us to point #2: Using Confluence because you’re already using it, and how to set it up.

2. Using Confluence As a QMS and How To Set It Up

Now that you understand that Confluence and Jira have zero benefits and still want to use it, how would you go about setting it up? This is literally not very different from using another hyper-generic tool as your QMS software (except that most other tools don’t take 10 seconds for a page load).

Here are the most important things you need:

• A tool for signing documents.
• Some sort of process how to archive (and find) old versions of documents.
• A requirements management system.

Let’s start with the first one: A tool for signing documents. For Google Drive, there are a few good ones, for Confluence there probably are some out there, too. That’s all I’ve got to say. I’m not researching this any further because it’s just too painful for me.

Okay, on to the second one: Some sort of process how to archive old documents. So the requirement here would be that your documents could change over time, but you need to be able to retrieve specific versions of documents. Like “dude, show me the software development plan for version 0.2 of the software, even though we’re now on version 14.4”. The Confluence change history of a document will not be enough because you might have to retrieve many documents at once (like, an auditor might ask you to provide them with all documents at a certain point in time).

A typical, crappy solution to this is to export and zip-archive all your documents at fixed points in time. Yep, that creates a bunch of PDFs or Word files and it sucks, but that’s how you could do it. I don’t know of a better solution.

Or wait, I do. It’s our QMS Software, Formwork. It archives all old documents properly, no need to wade through crappy zip archives. But, from my experience talking to Jira users, it seems to be quite impossible to convince them to use better tools (then again, I shouldn’t be surprised about this, given they’re using Jira and not complaining).

62304 Requirements Management in Confluence / Jira

Okay, on to the last one! You need a requirements management system. This is a huge topic by itself, but I’ll simplify it greatly: It boils down to linking stuff like software specs to software tests in a many-to-many way. Example: You have one software specification (= IEC 62304 software requirement, design input):

1. Do COVID diagnoses based on an image taken with the camera (however that may work).

Now, you have two software tests:

1. Test image capture functionality.
2. Test COVID machine learning model output.

And now you have to link tests #1 and #2 to software requirement #1.

Most companies do this in spreadsheets (ugh), and Jira companies typically solve this by setting up a new Jira project with specific ticket types, and then linking the tickets to each other. Again, this has absolutely no benefits, because you’re not re-using your existing content (user stories etc.). Still, if you like Jira, I guess it could work.

But you still have the versioning / archiving problem here. Like, you’ll need to provide an auditor with the “old tickets” and their relations for a specific old version of your software. The auditor might ask you “please provide me with all software requirements and their tests for v0.2”. Jira doesn’t have a feature to keep track of all ticket changes and re-creating old relations (Formwork does). Instead, you’ll probably have to resort to the approach of exporting all your tickets as cluttered PDF files each time you release a new version of your medical device software.

Conclusion

Is it possible to set up a QMS in Confluence and Jira? Yes.

Does it have any objective benefits? No.

Should you do it? Hell no.

What should you do instead? Two options: Choose another hyper-generic tool which doesn’t suck as much. Consider Google Drive, it’s a solid document editor. Or, if you actually want to leverage some automation in creating you regulatory documentation, check out our tool, Formwork.