Procedure template for ISO ISO 13485:2016 quality systems

5 Comments / ISO Certification / By Robert Packard / documentation, procedure, QMS, Quality Management System, template

This 12-part procedure template for your medical device QMS can result in writing shorter, more effective documents that facilitate training.

Procedure Template

We all have a standard template for our quality system procedures. Typically, we begin with purpose, scope, and definitions. This 12-part procedure template for your medical device QMS can result in shorter, more effective documents that are easier to train personnel on.

1. Purpose. Often I read something like, “This purpose of this document is to describe the CAPA procedure.” That necessary information is the reason why we title procedures. A better statement of purpose would be, “The purpose of this procedure is to provide a process for identifying, preventing and eliminating the causes of an actual or potential nonconformity, and using risk management principles.” The second version gives readers a better indication of the purpose of the procedure.

2. Scope. This section should identify functions or situations that the procedure applies to, but it is even more critical to identify which situations the procedure does not apply to.

3. References and Relationships. Reference documents that apply to the entire quality management system (e.g., – ISO 13485 and 21 CFR 820) only need to be listed in the Quality Manual. This reduces the need for future revisions to the procedures. I list here any procedure-specific external standard (e.g., – ISO 14971) in the applicable procedure. The relationship between procedures is more important than the references. Therefore, I prefer to use a simple flow diagram, with inputs and outputs, similar to the one below for a document control process.

4. Document Approval. Who must sign off on the procedure? Keep this list short. Ideally, just the primary process owner and Quality Manager (to ensure consistency and integrity across the quality management system).

5. Revision History. A brief listing of each revision and a brief description of what was changed in the procedure.

6. Responsibilities and Authorities. A listing of the main areas of responsibility for each role. Remember to include the title of managers who may be required to approve forms, or make key decisions.

7. Procedure. I prefer to create a detailed flowchart outlining each step of a process before writing the procedure. Each task box in the flowchart will include a reference number. If you organize the reference numbers in an outline format, then you can write the text of your procedure to match the flowchart—including the numbering of the flowchart task boxes.

8. Monitoring and Measurement. An explanation of how the process is monitored and measured, who does it, how often, format, method of communicating the analysis, and what process that analysis will be input into, e.g., Management Review.

9. Training/Retraining. Tabulated, which roles need to be trained in this procedure, and to what level? The example below is also from a Document Control procedure.

10. Risk Management. This section identifies risks associated with each procedure and how the procedure controls those risks. As well as complying with the requirement to apply risk management throughout product realization (i.e., Clause 7 of ISO 13485), including a section specific to risk management forces the author of the procedure to think of ways the process can fail and to develop ways to avoid failure. Risks can also be a starting point for training people on the procedure.

11. Records. Tabulated, form number and names, a brief description of its purpose, and a column for retention and location. This column also allows for reference to compilations if the record becomes part of, e.g., the Design History File, Device Master Record, or the Risk Management File.

12. Flowcharts. Step-by-step through the process, saying who performs the step when it isn’t apparent. I keep task shapes simple: rectangles for tasks, rounded rectangles for beginnings and endings, diamonds for decision boxes, and off-page reference symbols.

When the task needs supporting text, e.g., guidance or examples, put a number in the box and a corresponding number in the table in (7) above. Ideally, the flowcharts are placed in the document with the Notes table on the same page or the opposite page. In practice, I often put them at the end to simplify the layout. One of my clients loves her flowcharts and puts them on the front page.

Benefits of this Approach

Information is well structured and presented consistently across procedures, more so than can be achieved through narrative.

The flowchart is the primary means of documenting the procedure.
Tables provide details that are not clear in the flowchart.

The procedure structure described above facilitates a consistent training approach built around the document. Purpose and scope are presented first, and then the Risk section is presented to explain what is essential in the procedure and why. The flowchart, the table, and the formwork together describe each step of the procedure. Finally, a PowerPoint template can be used to guide process owners in developing their training.

And to make it even easier, you have already spelled out who needs to be trained and to what level.

Procedure template for ISO ISO 13485:2016 quality systems Read More »

Benefits of Incorporating Risk Management into Procedure Documents

By Guest Blogger, Brigid Glass
The author discusses the benefits of incorporating risk management into procedure documents. An example procedure for Record Control is included.

I loved it when I was first introduced to FMEA many years ago. I loved the systematic approach and particularly appreciated using a Process FMEA to explain to those involved in a production process why specific controls had been implemented. I enthusiastically taught FMEA to our engineers. At the time, our bubbly, buoyant, outcomes-focused Training Manager said to me, “You Quality people have such a negative outlook. You’re always looking for what can go wrong!” Well, yes, but it’s our role to prevent things from going wrong! I’d found a tool to help me with that.

Next was EN 1441, a risk analysis standard that never satisfied and always felt incomplete. ISO 14971 followed, covering the entire lifecycle of a product with closed feedback loops. So now, product and process design risks are well covered, but ISO 13485 section 7.1 asks us to “establish documented requirements for risk management throughout product realization.” Many of us would acknowledge that we could do better despite passing audits. And what about the rest of the quality management system? I know that when we document a procedure, we already apply risk management principles in our heads, but we usually don’t apply them systematically or write down the results.

The Idea

Recently, Rob Packard and I started work on a project requiring us to generate a complete set of documentation for a QMS compliant with U.S. and EU requirements, including ISO 13485 and ISO 14971. We each had our ideas on how best to write a procedure, but this project allowed us to get some synergy going. Rob wanted to address risk management in each procedure. “Yes!” I said, thinking that there was a chance to fill that gap. But then, it was my job to develop the template for the procedures and work out how to accomplish this.

My first results looked very complicated, so I took the KISS (Keep It Simple, Sweetheart) approach: one column for the hazards and consequences and one for the risk control measures.

What I didn’t include:

I started with more complex hazard documentation (hazard ID, impact, trigger event, etc.). Still, I felt the benefits in the context of a procedure document was not balanced by the extra complexity and work required for analysis and training. It would be a hard sell to users within an organization who were not used to the risk management approach.
I decided not to assess risks and controls quantitatively for the same reasons as in the bullet point above.
Initially, I included references to implementation, but this would be difficult to maintain as other documents changed.
I thought about verification of the implementation of risk controls, then decided to leave that verification to reviewers.

Below is an example from a procedure for Record Control in which records are completed on paper and then scanned as a PDF. My list won’t be the same as yours, but it is illustrative.

Standards and regulations are essentially a set of risk controls, so they are the first starting point when identifying hazards. The list should include direct risks to products, risks to the integrity of the QMS, and regulatory risks. For those of us who have been in this industry for a while, experience, past mistakes, questions fielded in external audits, and observations of other systems will yield further hazards and appropriate controls. Audits allow updating and refining the list and testing the control measures.

Benefits of Incorporating Risk Management into Procedure Documents

Impresses your ISO 13485 auditor!
When first writing procedure documents, starting the writing process by reviewing the external requirements and systematically writing the risk section sharpens the mind as to what must be included in the procedure. This is the same approach as in design controls, where we include risk mitigators that apply to product design in the design inputs. This is part of planning in the PDCA cycle.

Supports future decision-making, in the same way, that the risk file for a product is considered when a design is changed. The risk control section of a procedure provides the criteria against which any improvement or change can be assessed. Will it enhance the risk controls, or might it introduce a new hazard?
Serves as the basis for training on the procedure. Making visible the link between potential hazards and procedural controls much more convincing than saying, “Do this because the procedure says so,” or, “It’s in the procedure because the regs say so.”

documentation