Don't know where to start? Watch our free starter videos and save lots of time and consultant fees

Articles QMS Software

August 28, 2022

Generate Your Technical Documentation Automatically: Formwork Audit Export

Dr. Oliver Eidel

Starting today, Formwork can automatically generate your Technical Documentation. This is really exciting and can save you a lot of time. View the video below or read on to see how it works!

So, what does that mean?

In the past, you had two ways to create your technical documentation for your medical device: Either you’d do everything manually in spreadsheets, or you’d use a fancy “ticketing tool” to create documentation in a more structured way.

Both of these approaches have their benefits and drawbacks. Let’s look at them:

1. Technical Documentation in Spreadsheets

If you create everything manually in spreadsheets, I’m probably not the first one to tell you that this will be very painful and a huge mess. You have to assign unique IDs to everything, linking items is terrible, and keeping track of changes is a catastrophe.

Let’s look at software requirements as an example. Your spreadsheet for software requirements could look like this:

ID Title Test IDs
SWR-1 Users can log in with Google TEST-1, TEST-3
SWR-2 Data is stored in the EU TEST-2, TEST-3

Every software requirements has a unique ID, a title, and references one or many software tests.

Accordingly, you have to assign unique IDs to every software requirements (in the “ID” column) - that’s cumbersome, but not a huge problem. But the larger looming issue here is the many-to-many relation to “Test IDs”. In this example, any software requirement can be covered by one or many software tests, and each software test can itself cover one or many software requirements.

This is where it gets messy fast. What if a software test gets deleted? Do you manually search the software requirements spreadsheet for references to it? And how do you know that all mentioned tests even exist?

And, of course, if you’d want to create a traceability matrix out of this (auditors love them) (also, if you don’t know what this is, just pretend you do), there’s no trivial way to do so. You’d have to manually create a table which has software requirements as columns and software tests as rows. Then you’d need to go through all requirements (again, manually) and put an “X” into each cell where a software test covers a software requirement. Nervous chuckle.. now you probably understand why so many people are employed in regulatory jobs.

But wait, back to topic - there are also legitimate benefits to spreadsheets. You and your data are not locked into shady enterprise software. Also, your data can be modified easily - you can create new columns any time, and editing spreadsheets can be done by any person without prior training. This is not true for most other tools.

And most important for us here: Spreadsheets are easily exportable in an auditor-compatible format. In other words, if you’re ready to hand in your documentation to your auditor, it’s easy to hand in spreadsheets. You can export them as PDFs, or simply send them over as-is because everyone and their dog is able to open spreadsheets nowadays.

This is one of the biggest benefits of spreadsheets over ticketing tools. Let’s look at them next.

2. Technical Documentation With “Ticketing Tools” (Jira, GitHub, GitLab, Notion)

Once humans realized that spreadsheets were ill-suited for technical documentation, some adventurous hobbits set out to search for more sophisticated tools. They found Jira, GitHub, GitLab and Notion. All of these tools have in common that they enable you to enter data in a structured way.

In our example with software requirements above, you could create a Jira ticket type with those custom fields. And that’s all I’m going to talk about Jira because I think it’s terrible software.

And this generally works well! The data is nice and structured and everyone congratulates each other on another successful journey to Middle Earth.

Yet, the big problem arises once you need to export everything for your auditor. What do you do? Jira’s export either produces a very ugly Word or PDF file, and you sort-of have to pray that it’s readable and doesn’t look like a jumbled mess. Notion’s export looks better, but has its own problems as it falls apart for large tables and attempts to export everything in one document. GitHub and GitLab are the worst of all because they don’t even have an export feature. You have to resort to manually hitting their API and generating your own PDFs from that. Pain!

So, exporting your data in an auditor-compatible format is very, very hard with these tools.

Storing your technical documentation in a structured way while making it easy to export is a hard problem.

That’s why we solved it in Formwork.

Audit Export in Formwork

Formwork enables you to easily create structured technical documentation, just like Jira (ugh!), GitHub, GitLab and Notion. I’d argue that it’s even more intuitive because it already comes pre-configured with the right fields, so you immediately notice if your documentation is incomplete:

Creating a new software requirement

But now comes the really cool feature which we’re announcing today! With Formwork, you can automatically generate spreadsheets from this structured data. And those spreadsheets have exactly the right titles and columns which auditors expect!

And there’s really a ton of spreadsheets you can generate, have a look:

Available audit exports as spreadsheets

This is really, really cool. Formwork is the only tool which can auto-generate your technical documentation in this way, saving you enormous amounts of time (and nerves).

To my knowledge, there’s no other tool out there which does that, at least in a similar zero-configuration way.

This takes us one step closer towards automating the generation of technical documentation, and I hope you enjoy it as much as I do!

Audit Export is a Formwork Pro feature. That being said, there’s also the free Formwork Community Edition to get you started :)

On a slighty different note: You want to get your medical software certified under MDR but don't know where to start? No worries! That's why we built the Wizard. It's a self-guided video course which helps you create your documentation yourself. No prior knowledge required. You should check it out.

Or, if you're looking for the most awesome (in our opinion) eQMS software to manage your documentation, look no further. We've built Formwork, and it even has a free version!

If you're looking for human help, did you know that we also provide some limited consulting? It's limited because we are not many people. We guide startups from start to finish in their medical device compliance.

Congratulations! You read this far.

Get notified when we post something new.

Sign up for our free newsletter.

Dr. Oliver Eidel

I'm a medical doctor, software engineer and regulatory dude. I'm also the founder of OpenRegulatory.

Through OpenRegulatory, I've helped 100+ companies with their medical device compliance. While it's also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)

If you're still lost and have further questions, reach out any time!


If you have any questions or would like to share your opinion publicly, feel free to comment below. If you'd like to reach out privately, send us a message.

No QMS on this planet will save you from creating crappy software.