Early access registrations are open for Headstart, a predictable, fixed-price program for becoming compliant.

Updated October 25, 2020

Writing Technical Documentation

Dr. Oliver Eidel

What the Hell is Technical Documentation?

The Technical Documentation (or Technical File) is what you hand in to your Notified Body to get your product certified. It’s a collection of (pdf) documents which you send them. Any time you make a significant change to your product (more on that later), you send an updated Technical Documentation to your Notified Body for approval.

This applies to each of your products. So if you want to get more than one software certified as a Medical Device, you have to submit a separate Technical Documentation for each.

This differs from your Quality Management System which is valid company-wide. This typically gets audited on-site by your Notified Body with yearly follow-up audits (fun!).

What Does Technical Documentation Include?

That’s where the chaos begins. There is no common standardized structure for Technical Documentation. But at least the content is somewhat clear. The common requirements are:

  • Software Documentation resulting from an IEC 62304 - compliant development process
  • Risk Analysis based on ISO 14971
  • Usability Documentation (and tests) based on IEC 62366
  • Some random documentation from your ISO 13485 - compliant Quality Management System

Let’s go through these briefly and see how we can fulfil them.

Software Documentation (IEC 62304)

You need to establish an IEC 62304 - compliant software development process in your company. This process has certain requirements with respect to documentation. Examples would be that you have to document your software requirements (which answer the question “what does your software do?”) and maintain a list of third-party libraries you’re using (Software of Unknown Provenance, SOUP).

I did a separate write-up about what you need to become 62304-compliant, have a look:

Article

IEC 62304 Walkthrough

Read

Risk Analysis (ISO 14971)

Risk Analysis means that you ask yourself “What could go wrong with my software?” and “What would subsequently happen to its users?”. Simple, right? Until you encounter the ISO 14971 which puts that into regulatory language and confuses the hell out of you. But that’s pretty much what it means.

The whole package is called Risk Analysis and is an important part of your Technical Documentation.

Article

ISO 14971 Walkthrough

Read

Usability Documentation (IEC 62366)

You need to be compliant with IEC 62366 which states that you implement some sort of Usability Engineering process. The main part if this is that you conduct user testing on your final product (called Summative Usability Evaluation).

Coming soon: IEC 62366 Walkthrough

Congratulations! You read this far.

Get notified when I post something new.

Sign up for my free newsletter.

I work as a regulatory consultant for Healthcare software startups. I try to publish all my knowledge here so that startups can certify their medical devices themselves in the future.

If you're still lost and have further questions, just send me an email and I'll be happy to answer them for free. More about me

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.