Recently Rob Packard and I started work on a project that requires us to generate a full set of documentation for a quality management system that is compliant with US and EU requirements, including ISO 13485 and ISO 14971. We each had our own ideas on how best to write a procedure but this provided us an opportunity to get some synergy going. Rob wanted to address risk management in each procedure. “Yes!” I said, thinking that here 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 do this…
The result is a simple approach of a section in each procedure document with a two-column table: one column for the hazards and consequences and one for the risk control measures.
This is further described in my guest blog on the Medical Device Academy website. This includes an example for a procedure for Control of Records.
Benefits of this approach include:
- Impresses your 13485 auditor!
- Structures your procedure writing process, as in design controls, where we include in the design inputs the risk control measures that apply to product design.
- Supports future decision making, in the same way that the Risk File for a product is considered when a design is changed.
- Provides a basis for training the procedure. Making visible the link between potential hazards and procedural controls is a lot more convincing than saying, “Do this because the procedure says so” or, “It’s in the procedure because the regs say so”.
If this approach is of interest to you, check out the full blog and share this with your colleagues.
Supplier audits and internal audits are different parts of the same system, assuring us that all our linked processes are working together and operating under control. In some companies, especially smaller ones, the two types of audit are performed by the same people. In larger companies, there may be a specialist Supplier Quality team.
While they are parts of the same effort, the approach to the two types of audit are necessarily different.
• Function. Internal audits drive internal compliance and improvement, using established internal processes and monitoring over which your company has direct control. With a supplier audit, your findings feed into a system which you do not control, much as you would like to think you do.
• Criteria. In a supplier audit, the auditor is most interested in the processes that are directly related to the supply and that pose risk to the customer organisation. There’s more to tease out of this in a later blog.
• Relationship. With an internal audit, the auditor has organisational and procedural authority. In a supplier audit, the auditor is the customer, and therefore may have some rights, but they are a guest in the supplier’s premises.
• Influence versus control. You may not have much choice but to use a particular supplier. They may know this, which then may reduce your ability to drive change at the supplier. A similarly unbalanced relationship arises when the customer is very small relative to the supplier, and is not important to the supplier. These are factors which should be considered early in the supplier evaluation process.
• Trust. Good supplier relationships are built on a high level of trust, but it is likely that this will not be as high as in an internal audit.
• Distance. In a large organisation, internal audits are occasionally distant but usually the auditor can walk there. Supplier audits can require long travel, with associated costs, more investment of time and constraints on the time available for auditing.
• Time. All audits should be planned ahead with respect for the auditees time and other commitments. However, internal audits often allow for greater flexibility.
• Familiarity. A double-edged sword. Familiarity is usually higher in internal audits. With greater familiarity with the process being audited and the adjacent and adjoining processes, an auditor may more easily see what is missing. However, that familiarity may also lead to unconscious assumptions, preventing them from seeing what is actually in front of them.
• Language. Supplier audits may have the added challenge of a foreign language. If trust is not high, then using an interpreter from the supplier may cause difficulties. I have achieved the best results in this situation by travelling with someone who could speak and read the other language well, and who was also an experienced supplier auditor. Rather than asking her to translate, I could ask her to find what I wanted to know.
• Culture. Even when we speak the same language, and national cultures are superficially similar, there can be differences in national or organisational culture which can impact on communications and perceptions during a supplier audit. Yes, if six representatives from your Chinese supplier want to take you straight out to dinner from the airport, even though you’ve been travelling for 20 hours and you need some sleep before the audit in the morning, you need to attend, and appreciatively. In some companies in Japan, it does matter were you sit at the meeting room table. In many situations, including in my own country, I have found it very useful to be able to honestly say that I don’t want to drink alcohol because I am allergic.
• Commercial Relationship. In supplier audits, the commercial relationship must be respected, while nevertheless performing an impartial audit. I preferred to visit suppliers with the Purchasing representative who had investment in the relationship. The aim should be to improve the quality of the goods delivered, while still maintaining the relationship. While sometimes an audit may result in a change of supplier, this should be because the customer chooses to make the change, not because of the way the audit was undertaken.
Some years ago I audited an overseas supplier, a printed circuit board manufacturer that specialised in shorter run work. The proprietor was immensely proud of her business, and rightly so. The plant sparkled, with a level of cleanliness and order that far exceeded any other PCB manufacturing plant I had visited. Everyone knew their job well and the place ran like clockwork. They had just successfully achieved ISO 13485 certification and were on their way to ISO 14001.
We were at the end of the audit, walking away from the production area. The audit had gone well, with a couple of areas for improvement identified but no nonconformities. I was feeling pleased with them. They were feeling pleased with themselves. I was looking forward to a straightforward exit meeting, lots of happy handshaking and getting back to my hotel for a refreshing swim.
As we walked back along the corridor to the meeting room, the proprietor made a slight comment about sending out PCBs for continuity testing.
Hold it right there! The alarm bells in my head were clanging. “What testing was that? You say the PCBs go out to another company for a final test? Uhuh… And have you audited them? No… And no quality agreement, either. Right…”
My internal dialogue was firing concurrently with that conversation. I had already picked up that an area for improvement was their supplier quality programme which had yet to mature. Could this testing have an impact on the quality of the goods we purchased? Does this testing matter to the users of the PCBs in my organisation? Am I getting nervous? (Yes to all). The body language in the group had changed by now.
Their certification body had also missed this. It wasn’t an intentional exclusion from their QMS, they just hadn’t identified the testing as an outsourced process for which they had responsibility. It was easy for an outsider to miss because it wasn’t flagged anywhere in their documented system.
This particular story had a happy ending. It was rapidly and satisfactorily resolved, with lessons learnt all round. They learnt about outsourced processes as part of their QMS. What did I learn?
When I audit, I build a model of the process in my head, based on what’s documented, what I’m told and what I see. I compare that with how I expect the process to be, based on the audit criteria and my experience and research. In this instance, the model in my head appeared to be complete and ok. I completely missed the interface to another part of the process that had been outsourced. It’s possible to fall into the same trap with an internal audit, where you think you understand the entire process and familiarity blinkers your thinking.
Since then, I’ve made it my practice to ask, “Does any part of the process happen outside of this plant/organisation/production line?”
Had I been using turtle diagrams as an audit tool back then, it’s likely that the outsourced step would have become obvious to me during the audit. Had the supplier been using the tool to map their processes, it would have been obvious to them that it needed to be included in their QMS. A turtle diagram makes you look systematically at each link in a process and consider inputs, outputs and interfaces. Robert Packard is a great fan (and teacher) of turtle diagrams and includes a description in in his blog about process auditing.
Watch the free webinar that Rob and I are running on Feb 13th (Feb 14th in NZ) to hear Rob explain process auditing and how to use turtle diagrams. After the event, register here and the download will still be available.
Does your audit programme cover all your audit requirements?
Anyone who has audited with me knows I’m not a checklist fan. I find they bog me down and take my focus away from analysing the process in front of me. I far prefer the process approach to auditing.
But if you’re not using checklists, then how does the Audit Programme Manager know that everything has been covered off? How do you demonstrate coverage to an external auditor auditing the internal audit system?
In his blog, “How many hours does your company spend auditing?” Rob Packard presents an audit schedule based on the process approach to auditing. This blog suggests another element for that model.
Let’s take Record Control as a simple example. During every internal audit, I check records, that they are correctly completed, that the form matches company protocol, that they are correctly referenced, stored, retrievable. I don’t need a checklist to ensure that I cover that – it’s an automatic part of my auditing. But if I’m auditing production, I’m not going to check that record disposition is appropriately managed, and probably not that retention times are related to the life of the product, as required by ISO 13485 and maybe by customer requirements. I want to audit these aspects at least once a year, so I make sure I cover them in the QMS audit.
So then, how to capture this systematically?
Let’s start with the scheduling matrix that Rob developed in his blog. The format is months listed along the top, topics down the side. Blocks in the matrix shaded to show the audit, with the auditor’s name written in. This type of matrix is a commonly-used, useful tool for scheduling. For convenience, I change it slightly by putting an audit number in the box, with a short, separate table showing audit number and auditor.
Next, I create another matrix that has my audit criteria down the side and the audit numbers across the top. Blocks are shaded as before, with dark shading for the audit that covers all aspects of a topic, light for the ones that cover implementation. For our Record Control example, QMS (audit 13-7) has dark shading, the other audits have light shading. For Training, I will check training in all audits, but in one audit of production (13-6), and in the R&D audit (13-3), I will check training needs analysis, make sure I look at the records of a new person and check other aspects of the Training procedure. Next year, I might rotate that to other process audits.
This table can be kept very simple, or it can be further developed to be quite sophisticated. The left hand column with topics can be expanded with more columns to show your high level procedures and clauses of Part 820, ISO 13485 and any similar management system regs and standards, e.g. ISO 14001. Rows can be added to cover particular regulatory requirements extra to those, or particular customer requirements, e.g. the example below for complaint management, including the EU and US regulations. This approach is quite flexible, as broad or as detailed as you wish, and can be modified over time to suit your particular situation.
The table allows you to easily give a set of criteria to an internal auditor so that they can use it to develop their plan for that audit. If you include the references, as above, this will make it easier for the auditor to flick to the source during the audit.
If this has been of interest to you, please share your comments, and sign up (top right of the sidebar) to receive my blogs by email.
Have you performed a gap analysis on your Risk Matrix against the MDD requirements?
No you don’t need to buy EN ISO14971:2012, but if you have an EU certificate and must comply with the EU Medical Devices Directive, then you must apply the EU requirements for risk management, spelled out in the new annexes. This version of 14971 was accepted as an EU harmonised standard in August 2012 and therefore applies now. The EU requirements aren’t new, but it has been common for companies to apply 14971 without noticing that there are some subtle differences in the Essential Requirements. The EN standard spells them out for us.
A copy of the annexes is available here from the Danish Standards website. We are grateful to them for acknowledging that this is more about regulation than it is about standards.
While none of the requirements are new, they will impact on how your Notified Body audits your file (or make more explicable to you how they have been auditing).
Annex ZA outlines seven areas where the MDD requirements differ from ISO 14971. Once you have read my list below, look together at 14971, the Essential Requirements 1 and 2 (MDD Annex 1) and Annex ZA, especially the Content Deviations section after Table ZA.1. Each item in that section is laid out in this way:
a) The 14971 requirement;
b) The MDD requirement (the first and second of the Essential Requirements, Annex I);
c) What the manufacturer must do differently from 14971 in order to meet the Essential Requirements.
My take on the seven areas of difference:
1) No risk may be discarded because it is negligible. They must be covered in your matrix.
2) Your overall assessment of the risk of a device must weigh up ALL of the risks against the benefits, not just those that are unacceptable.
3) ALARP is dead. While the requirement is to not apply economic considerations, I think it’s safer to stay away from ALARP, which has never added much value to the process.
4) You must ALWAYS undertake the analysis in (2) above.
5) Risk control must be applied in the following order: inherent in design, protective measures, information to users. You mustn’t stop mitigating the risk once it gets in the acceptable region; keep applying through those three control options unless it doesn’t improve safety.
6) Risk mitigation must eliminate risks as far as possible through safe design and construction.
7) A warning or other information to users does not reduce risk further. Information to users is regarded as meeting your obligation to advise users of residual risk. You therefore can’t use information to reduce your residual risk (likelihood and severity post-mitigation).
Remember through all of this that if you are using a standard such as the IEC60601 family as risk control, the standard is essentially best practice and compliance provides a presumption of conformity.
From the seven areas, you can develop your own set of questions for your gap analysis of your risk files. Remember also to perform this analysis on your risk management procedure and to include the MDD, as well as 14971, in the References section of your procedure.
Tip: put this on the agenda of your next management review under changes to regulatory requirements. If you are having these reviews at intervals that are useful, then this is where you discuss and document the plan to fill any gaps you find and the resource requirements required. Alternatively, raise a CAPA and manage it that way.