Medical Device Documentation

Working on a medical device is a large undertaking. The documentation required by the FDA is able to intimidate even the most stalwart engineer all on its own. But they require it for good reasons, and once you and your team get started, you may find they become helpful instead of intimidating. Maintaining the necessary documentation means that you are also maintaining a good development process. Here, we’ll break down what documents are involved in firmware for medical devices, how they are often managed, and how DojoFive is using EmbedOps to make sure documentation won’t hurt a bit.

What to Document

Fundamentally, you are documenting the requirements for your device, the design decisions you’ve made, your development process, and the outcome of your work. When you’re creating these documents, you can think of the FDA as your customer. They want good devices out there saving lives, and they want it to be easy to approve them! So starting early, and keeping your documents up to date throughout the process is just important as keeping your code up to date.

You’ll be gathering information and documenting decisions not only at the beginning of your project, but in every meeting, with every pull request, in every issue tracked, and every code review. It sounds like a lot, but we promise it’s not endless! While there are marketing, business, mechanical, and electrical documents needed as well, we’re going to focus on what you need to cover for the firmware.

The Documents

• Software Bill of Materials
  • This describes every piece of code that goes into the final product. Just as the bill of materials (BOM) for the physical product will list of every wire, screw, and other pieces in the device, the software BOM will list every module, driver, and config file the product needs to work.
• Released Spec
  • Where the software BOM outlines your code, this lists the compiled files that are loaded onto the product itself. If you have to send it to the manufacturer, it’s on this list.
• Software of Unknown Provenance (SOUP) list
  • You will often use software you didn’t write, and may not be able to test to the same level as your own code. If your device has an operating system, for instance, that OS goes on the SOUP list. But beyond just a list, you also need to track a few things, including:
    • The risk you estimate each SOUP holds
    • Your plan for monitoring bugs and vulnerabilities in the SOUP and updating it
    • A log indicating when you checked your SOUP, whether you decided to update it, and your reasoning for why you decided to update it or not
• Build Procedure
  • This describes how your team builds the software, including the versions of the tools used in this procedure.
• Traceability Matrix
  • This is where you tie your requirements to the design of your software and the tests that will indicate whether the requirement is fulfilled. This gets updated every time your software gets updated. Tests can be unit tests through characterization and verification tests.
• Software issues and anomalies list
  • The common term for issues and anomalies is bugs. If you have an issue tracker like JIRA or RedMine, that is your document! The most important thing is that it should NOT be blank. If your FDA reviewer sees an empty issues list, they’re going to assume you didn’t do enough testing, or you don’t know your own system! Make sure to include the following with every issue filed:
    • Issue Description
    • When/How Happens
    • Investigation
    • Risk that the issue imposes.
• Design Doc
  • Your design doc is not only the initial architecture and feature list, but the ongoing design as you write the software. It should list the maturity status of each feature, what requirements they belong to. If you’re using a project management system with tickets, you can expect to update this document for each ticket.
• Peer Review Doc
  • Your development process needs to implement regular code reviews. The easiest way to do this is to implement them with every pull request. In addition to the written review, or summary of a review meeting, these docs should also include the following:
    • Acceptance Status
      • AS IS
      • WITH CHANGES
      • DO NOT ACCEPT
  • Commit messages
  • Names of the developer and the reviewer
  • You may also implement design reviews at a higher level. This is where capturing your meeting notes is critical. What aspects were up for review as well as the comments and factors weighed should be included along with the final decisions made.
• Static Analysis
  • Your development process needs to include static analysis of your code. Static analysis checks your code for common “mistakes” or potentially risky code. Not everything the static analyzer finds has to be fixed, but every finding does need to have been reviewed and get labeled on why it’s worth fixing or not.

Where to Keep Documents

Quality Management Systems (QMS) are where all of this documentation is stored. There are several commercial systems you can purchase, both general and specific for medical devices. The other option is to maintain your own “paper based system”. If you go with the latter, you’ll have to create another document to show how you are managing your documents, who has access to them, and who is able to change them. You will often have an “official latest” read only copy and an approval system to update this copy.

How EmbedOps is Helping Teams Document

If the above list seemed like a lot to keep track of, you wouldn’t be wrong. The team at EmbedOps has had experience with developing medical device firmware and knows how it can be overwhelming. That’s why we’re working to streamline the documentation process. Much of the information needed for medical documentation is generated through tools that developers commonly use, but it’s hard to extract it into something that can be submitted to the QMS*. EmbedOps* coordinates those tools so that information is easily documented, automated whenever possible. It also strives to enable the team to complete the documentation that isn’t automated as part of their development process so no one has to become the doc cop. We’ve built EmbedOps to make our team better and happier, and if that sounds like what you need for your team, give us a call!