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!).
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:
Read: IEC 62304 Walkthrough
I did a separate write-up about what you need to become 62304-compliant, have a look:
Read: IEC 62304 Walkthrough
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.
Read: ISO 14971 Walkthrough
The whole package is called Risk Analysis and is an important part of your Technical Documentation.
Read: ISO 14971 Walkthrough
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
Coming soon: IEC 62366 Walkthrough
