What Documents are Needed to be Compliant with IEC-62304?

What Documents are Needed to be Compliant with IEC-62304? The European Standard for medical device software development life-cycle defines several activities that need to be performed and documented. How do you take the standards and define the documentation needed to create compliant medical device software?

I am going to write a series of blog posts that describe the documentation (with document templates) needed to be compliant with standards described in IEC-62304. Medical device start-up companies that have already started creating their own quality management system will find these series of posts helpful.

The standard IEC-62304 calls out several plans, protocols, reports, and processes. Several of them can be combined in to one document. The needs and goals of your organization will dictate how to best implement the standard’s requirements. For instance, your organization may decide to include the problem resolution process in the same document as the risk management process. As long as all the standard’s requirements are met, your organization can create as many or as few documents as deemed necessary.

For this implementation of IEC-62304 we will create four process document templates and eighteen implementation document templates. (As the blog posts for each template are written, I’ll update this post with links.)

Process Documents

Software Development Process – A document that describes how your organization develops software. This is a good spot to call-out how Agile development methodologies can be applied to creating the implementation documents.

Software Problem Resolution Process – How will your organization handle software defects found during development, testing, and post-production?

Software Risk Management Process – A document that describes how your organization will identify and mitigate any potential harm that your software may cause.

Software Change Control Process – Software updates will happen. How will your organization handle updates?

Implementation Document Matrix

Several activities defined in IEC-62304 are only needed based on the software safety classification you assign to your software. The standard defines the three safety classifications. Class A means that no injury or damage to health is possible. Class B means that non-serious injury is possible. And Class C means that death or serious injury is possible. Class A software has the least number of required documents and activities. Class C software has the most requirements.

You can have a medical device that has several software components with different safety classifications. But you must document how the software components are separated and why the different classifications make sense. The following table defines a title for each implementation document and marks each document with a “Y” if it is needed for Class A, Class B, and/or Class C software.

* The standard does not require a Software System Test Protocol or Report, nor a Software Release Report for Class A software. I think it’s a good idea to include those with Class A software to mitigate business risks. You don’t want to release buggy code to your customers.

The documentation requirements for Class B and Class C are very similar. Each document also has specific requirements depending on the safety classification of the software. We will get into those specific requirements as we create the document templates.

Creating a medical device software quality system is daunting. But it can be done by breaking each piece down into a manageable size. Stay tuned for more blog posts that describe each process  and implementation documents and how they cover IEC-62304’s requirements.