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:
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:
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 🙂
