[updated MAR 2025]
If you’re new to medical device software, it can be confusing to figure out which rules you need to follow and which documents you need to write. What is the IEC 62304 standard? And what are FDA software guidances? To help clear up the confusion, I wrote this short introduction explaining the basics of the IEC 62304 software standard and the FDA software guidances and the differences between them: FDA Software Guidances and the IEC 62304 Software Standard.
Secret #1
First secret about understanding medical device software documentation: don’t start with a checklist of documents! Instead, start by understanding the processes necessary for compliance and the activities in those processes. Once you understand them, the documentation is an outcome of performing those activities and following those processes.
For example, the IEC 62304 medical software standard doesn’t define a single list of documents to comply with the standard. Instead, it defines processes and activities and the requirements associated with them. The Software Development Process in IEC 62304 is broken down into 8 activities (numbered 5.1 – 5.8 in this diagram). Each activity produces one or more documents that together show compliance to the standard. The names of those documents will vary from company to company but the processes and activities won’t. For example, some companies have a single document that defines the software architecture and detailed design whereas other companies will split this information amongst multiple documents. So memorizing document names won’t be a reliable guide to know what’s needed for compliance.
Secret #2
“That makes sense, but can’t you just show me a typical list of documentation for medical software?” Yes, and the second secret is to compile a list of software documentation customized for your particular project so everyone knows all the documentation that will need to be delivered with the software. This article includes a list of typical documentation for medical device software as well as a list of what’s required in an FDA submission: Documentation for Medical Device Software. Your team can use this generic list as a starting point for your custom list, adjusting the structure of the documentation (and the names) to best fit your company’s quality system and the medical device you’re developing.
Secret #3
Another secret about software documentation: since it’s based on managing software development, you’ll find that much of the required content of the software documents is already present in your software development tools and just needs to be exported in a suitable format. For example, exporting your open bug list from Jira (or another bug tracking tool) can form the basis of a Software Unresolved Anomalies Report. Leveraging the content of your software development tools is not only more efficient than starting with a blank page, it also helps ensure that the software documentation stays in sync with all the changes to the software.
And if you want to see what it’s like to use a system designed for documentation automation, take a look at this series of posts: Two Approaches to Developing Software-Enabled Devices