How should you structure your documentation to meet the requirements of ISO 13485?
Medical device development is notorious for generating a huge amount of documentation. From the SOPs that define the way you work, to the design files you iterate, and the records you generate in the course of your build and testing.
As your project grows the amount of files and documents of different types and sizes that accumulate in your system will grow exponentially.
Added to that, medical device developers are constantly reminded by consultants that ‘if it isn’t documented it didn’t happen’.
Because of this, the temptation can be to hoard every single document related to everything they’ve done, making your QMS (Quality Management System) more crowded and difficult to navigate than ever.
Compiling a Design History File (DHF) for a med-tech product
But unless you’re highly methodical and organised in the way you generate and organise your documentation the potential for your filing to grow out of control is always there.
To guard against these potential problems ISO 13485 requires you to show how you will structure and control your documents and records within a Quality Management System (QMS).
ISO 13485 sees documentation as a key driver of quality throughout the product development cycle in the way it:
ISO 13485 states:
“The quality manual shall outline the structure of the documentation used in the quality management system.’
ISO doesn’t specify how this should be done, but for many businesses the best way to think about the structure of their documentation is as a pyramid or document hierarchy.
In this hierarchy each layer of documentation stored in the QMS guides the consistent production of the ones beneath:
At the top of this pyramid are the policy and quality manuals that summarise your approach and philosophy. The next layer includes your documented quality and SOPs that show your team who performs required functions; when, where and in what way. The next layer includes all the specifications, designs, drawings, and work instructions that are required to build your product. The final layer are the records you generate as you build the product, which are the evidence that you have built it as intended. These can include quality records, validation records, design history files (DHF), and device history records (DHR).
Effective control, review and distribution of documentation at every level of this hierarchy ensures that consistency and quality cascades downwards throughout the product lifecycle, even as the volume of documents you are generating increases.
In this way you can ensure you are producing documentation consistently, according to your documented procedures and in ways that exactly match the regulatory requirements.
The production of each layer of documentation is subject to required controls and checks to ensure their integrity is maintained throughout an evolving project.
These controls ensure documents and records:
They ensure the right documents are easily available to the right people at the right time throughout your process and your system does not become cluttered with obsolete documentation.
They ensure that your business is always being directed to follow procedure and your people are effectively documenting what they are doing in the right place - as they do it.
How to build your med dev eQMS: Download our free eBook
But maintaining this level of consistency and control over quality across the medical device product development cycle is a huge challenge.
Using a sophisticated eQMS will help you more easily implement the cycles of ‘plan, do, check, and act’ that protect the integrity of your documentation and your quality processes.
The right digital tools can support your team as they create new documents in different formats, helping you approve and manage them over time in a methodical and structured way.
The documents and records you generate throughout the cycle will be in all kinds of formats from Word docs, to coding and CAD files. You need an eQMS flexible enough to store them all and make their contents ‘visible’ and findable to users and auditors of your system.
Many of the quality resources that will be most useful to your team might be in the form of videos, images, flow charts and the like. You’ll need the tools to control their version history, index them and review them periodically no matter their format.
You need the flexibility to create different workflows for different kinds of documents - giving them different access rights, using approval and re-approval mechanisms (including e-signatures) as required.
Automation means required processes can happen consistently and in particular ways, reducing the risk of omissions and mistakes. Automated workflows can help you build review and approval processes that trigger new validation and development sequences, keeping your project moving between phases of planning, design, build and testing.
As you work through the products’ design stages the right eQMS will let you define the document requirements for each step of the required process. Your eQMS can show you exactly what documents you need to assemble for each stage, holding them together in draft format and publishing them together as final versions when you have all required approvals to proceed.
In this way you can visualise the structure of the documentation and see it growing and developing from ideation to design to product validation.
The way your documentation is structured and maintained can make the difference between a Lean and dynamic QMS that supports project ‘flow’; and one that is overstuffed with unnecessary documentation, hard to use and navigate.
The right eQMS will help you structure your documentation in a way that exactly meets your business needs and your regulatory obligations, without any unnecessary clutter.
Through document control and automation, it will help you systematically define your process, plan your build, execute your build against those plans, and help you demonstrate to your auditors that you have done so.