You want to document your medical device product in Formwork. Great choice! You probably don’t know this yet, but choosing Formwork will save you a gigantic number of hours down the line. That’s not because Formwork has many magic features (only a few), but rather because your alternatives are so crappy: Google Sheets or enterprise eQMS software, both suck a lot for startups.
Anyway, onwards! First off, let’s create a new product.
Creating a New Product: Product Types And IEC 62304 Safety Classification
Navigate to “Products” (top bar) and click the “+ New” button. You will be greeted by this friendly form:
You will have to come up with your product’s name and description yourself (I can’t do everything for you), but the bottom two fields are interesting. Let’s look at those:
- Type: What sort of medical device this is. You choices are “software”, “hardware” or “software and hardware”. What does this mean? If your device is software-only (e.g. Radiology ML software), select “software”. If it’s a hardware device (e.g. a scalpel), select “hardware”. If it’s a combined software + hardware device (my condolences, a regulatory nightmare), select “software and hardware”.
What difference does this make? Glad you asked. Things will be named differently: For software devices, design inputs will be named “software requirements”, whereas for devices containing hardware, they will be named, well, “design inputs”. Similar things happen to most other terms: Software System tests are named System Tests instead, etc. – none of these are huge changes, but they are in line with the various regulatory requirements for hardware and software, so that Formwork will output just the right spreadsheets which will make your auditors happy. - IEC 62304 Software Safety Classification: This is your, well, software safety classification based on the standard of medical software, the IEC 62304. If you have no clue what this means, then.. well, you probably should take a look at the standard. You choices are A, B or C. The most common choice (by far) is B.
What difference does this make? The main difference lies in choosing C, which means that your software would fall into the most risky category (chances are you’re not class C software). In that case, an additional item called “detailed design” will be displayed in the left menu later on, which means you have to create additional documentation on how you performed detailed design of your software. Generally speaking, none of this makes sense from a rational standpoint, but some regulators decided at some stage that documenting “detailed design” would sound like a great idea.
Again, in simplified terms, my experience has been that 95% of EU MDR software seems to be class B, and of the remainder, maybe 4% class A and 1% class C.
That being said, the FDA requirements for software documentation are stricter. The FDA usually requires you to always document detailed design (crazy), so if you’re targeting FDA compliance, you should select class C.
Choose wisely, Jedi, because these can’t be changed later for your product. That’s because it’s highly unlikely that any of these things will change in the real world for a product, and it would be rather messy in Formwork, because now you’d have to suddenly document additional data (A/B –> C), or data would no longer be visible (C –> A/B). Choose wisely.
Okay, that was a way too elaborate introduction on safety classes. Let’s look at the Products section next. Here’s how it looks once you’ve selected a product:
The most important stuff is all in the left menu. Some items are color-coded because some weird programmer (maybe it was me) came up with this color-coding scheme when writing the first few lines of Formwork code. Let’s look at what we’ve got:
Generic items: These things concern all aspects of your product, irrespective of its version:
- My Activity: Shows you stuff you need to review, if someone sends you something for review.
- Products: List of other products you’ve got stored in Formwork.
- Releases: List of your product releases – a product release is a specific version of your product.
- Change Requests: Changes to your product which you document and sign off on.
- Product Settings: You guessed it, your product settings.
Under those items, you find the version selector. In the screenshot above, it shows the version “v0.4.0 (draft)”. So what does this mean? Formwork allows you to document separate versions of your medical device. The main purpose for this is that an auditor might walk into your office and say “hey dudes, what did your documentation look like for version v0.2.1 of your device?”, and you need to have an answer to that.
By clicking on the version selector, you can view your product documentation of other versions of the same device.
Below that, you’ve got our Sanity Check which works like a regulatory consultant: It checks whether you’re missing anything obvious in your documentation, e.g. whether you’re missing a review or whether things are unlinked which should instead be linked. It’s like a regulatory consultant, but less annoying and much less expensive.
Below that, you’ve got the items relating to software documentation:
- Records: Rich-text records which belong to your product.
- Stakeholders: The target users of your product which lead to so-called stakeholder requirements.
- Stakeholder Requirements: Requirements by stakeholders for your product.
- Software Requirements: Requirements which your product (in this case, software) should fulfil.
- Software Detailed Designs: Detailed designs, only for class C.
- Software Tests: How you test your software.
- Software Test Runs: Actual executions of your software tests.
And that’s it for software.
Below that, items for risk management:
- Preliminary Hazards
- Failure Modes
- Risk Matrix
- Risk Table
- Hazards
- Hazardous Situations
- Harms
- Risk Controls
And finally, items for your usability evaluation documentation:
- User Tests: Which usability test you plan for testing the usability of your software (typically with humans).
- User Test Runs: Actual events where you executed your usability tests, i.e. sat down with a human and went through at least one test.
At the bottom, there’s some fancy stuff:
- Requirements Overview: A fancy, one-page overview over all your requirements and their tests. You can show this to auditors during an audit and they’ll probably think it’s the most awesome think they’ve ever seen. Besides that, it also helps you keep an overview over your requirements by e.g. making it obvious which requirements are still lacking tests.
- Risk Overview: A similarly-awesome overview, this time for risks.
- Audit Export: Probably the coolest feature of the “Products” section of Formwork. Export all your product information as spreadsheets, and those spreadsheets contain exactly the right columns and information which auditors expect, e.g. a “software requirements specification”.
- Batch Exports: This is a one-click export for your rich-text records, those are not part of the audit export.
So this was a very lengthy overview. Now, what to do next and where to start? Bear with me while I’ll spend the next few weeks writing up detailed guides for all sections mentioned above. I’ll also write something like a “this is what you should do next” guide which shows you a typical real-world use case of Formwork, showing you which section you’d use in which order. Stay tuned!
