Procedures

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.

When I was first introduced to FMEA many years ago, I loved it. I loved the systematic approach and particularly appreciated using a Process FMEA to explain to those involved with a production process why certain controls had been put in place. 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, there 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, risks in product and process design were 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, even though we pass 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 that requires us to generate a full set of documentation for a QMS, compliant with both 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 provided us an opportunity 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, Stupid) 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 where records are completed on paper, then scanned as a pdf. My list won’t be the same as your list, 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 provide the opportunity to update and refine the list and test 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.”

This is part 1 in a series of blogs that leads up to our Roadmap to Iso 13485 Certification Courses