NEU!! Entwickelt SxMDs mit einem strukturierten eQMS, einschließlich auditfähriger SxMD-Vorlagen, die an EU- und US-Standards angepasst sind. Mehr Erfahren!
Getting started with a QMS from scratch: Start to write processes...and never stop!
In this post of our series "Getting started with a QMS from scratch", we are going to focus more on writing processes that are compliant with ISO 13485.
First of all, let's be clear on the semantics
When reading ISO 13485, you frequently see "documented procedure". FDA 21 CFR Part 820 talks about standard operating procedures (SOP's) and documented instructions.
Classically, procedures or SOP's are quite extensive documents describing several activities belonging to one big topic.
For example the document control procedure can include:
Document creation
Document numbering
Document review
Document approval
Document storage
Document retention time
Document change control
...
As described before, with MatrixQMS, we aim to create a platform that allows you to have a lean and agile QMS. One of the pillars of an agile QMS is that you try to avoid monster procedures, but rather split them up into smaller, more easily manageable pieces. This is what we call processes or PROC items in MatrixQMS.
Different processes can belong to the same bigger procedure or SOP.
Which processes do I need in my QMS?
ISO 13485 describes a series of topics where it requires a "documented procedure". When complying to this standard, you need to have at least these procedures in place.
The standard tells you as well that you should create "other documents needed to ensure the effective planning, operation and control of your processes". That means that whenever further explanation is needed, you are supposed to create a procedure or instruction for it.
When creating a QMS, you should as well apply a risk-based approach. This means that you need to evaluate risks linked to your processes. To do so, you might perform risk analyses on process level and by going through this process you might discover you need some additional processes or procedures to reduce some of the risks. We will focus on that more in one of the next posts of this series.
There is no upper limit when it comes to the number of allowed procedures ;-) (but it's also not a good idea to overcomplicate things either)
In order to facilitate the review process afterwards, it's a good idea to split complex and big procedures into smaller processes.
Based on the required procedures, you can easily do this (see the example above for document control).
Which one to write first?
The number of processes to be written can be overwhelming. So where to get started with this?
Our take on it is to start where you feel most comfortable.
For people that are working on the actual development of a product, this could be the different processes belonging to the design control procedure like Product development planning, Product requirement management, Design input, Design output, Validation and Verification, etc.
For people that have more background in production, it could be the processes related to material selection, incoming inspections, production control, calibration of measurement equipment, etc.
And other people might find it easier to start with the more general processes like document and record control, risk management, management review, trainings, etc.
Creating a QMS is rarely a 1-persons' job (unless you are a consultant). When you have founded your own start-up, it's probably also not your main speciality. So try to write your first few processes in the area that you are most familiar with to get you started. Once you get the hang of it, you might take on more challenging parts (for you).
What does a process look like?
There are a few basic things you need to take into account when writing a process:
Processes are not falling from the sky: There is a reason why a certain process exists. It can be a regulatory requirement, it's one step in a cascade of different processes, it exists because you need to control certain risks, etc. It's helpful for everyone that needs to follow a process that they know why it exists, therefore it's important to document this.
Process input: For each process, the input should be defined. What is needed for this process to take place?
Clear description: In order for people to know what they need to do, they have to be able to understand the text. Therefore, spend time in writing a process in a clear way.
Don't make it too complex: A QMS should fit the organization. The last thing you want is a QMS that could be used by NASA when it's not needed. Lean and agile, remember?! Make sure your QMS answers to the regulatory requirements and fits the size and complexity of your organization. Not more, but also not less.
Process output: The basic principle behind a QMS is Plan-Do-Check-Act. This means that your processes should have a certain output which allows you to verify that the process has been implemented correctly and that it's leading to the desired end-result. Most of the time, this is done through records.
Effectiveness Check: Following the process output, you should as well define how and when you are going to check the effectiveness of your processes.
What's next?
After writing your processes, you need to review them, approve them and release them. This will be the focus of our next post.
Does it ever end?
Simple answer: No!
Once you've created a QMS, you have to maintain it and improve it. There are several reasons for this:
Your organization changes and therefore your QMS needs to be updated
You find better ways to work and this needs to be reflected in your QMS
The regulatory landscape is always moving and therefore regulatory requirements for your QMS can change as well
If you would like to see how MatrixQMS supports you in getting started with your own QMS, don't hesitate to contact us!