A blog follower from Jon Speer’s website, Creo Quality, recently sent me a message asking for sources of good guidance on this Quality Management System (QMS) Stuff. There are a bunch of links below for you to follow and some practical advice. Enjoy learning!
The single best guidance document on the implementation of a QMS system in accordance with ISO 13485 is “13485 Plus” (type in the words in quotes to the CSA search engine).
There are also a bunch of pocket guides you can purchase for either ISO 9001 or ISO 13485 to help you quickly look-up information you are having trouble remembering. One of my Lead Auditor students recommended one pocket guide in particular and she was kind enough to give me her copy.
There are some webinars out there that provide an overview of QMS Standards. Some are free and some have a modest fee. I’m not sure the value is there for these basic overview webinars, but if you need to train a group it’s a great solution. I know BSI has several webinars that are recorded for this purpose.
You can try to identify a local mentor–either in your won company or at your local ASQ Section.
You can join the following LinkedIn subgroup: Medical Device: QA/RA. You will need to become a member of the parent group (Medical Device Group)–if you are not already one of the 140,000+ members connected with Joe Hage. George Marcel and I manage this subgroup for Joe. George is out in the Bay Area and I’m in the Green Mountains.
You can visit the Elsmar Cove website and participate in the discussions you find there. I wrote a blog about Elsmar Cove a while back (wow almost 2 years ago now).
The best way to learn this stuff is to do all of the above.
I’m sure that there are some that disagree with my determination that the latest revision of EN 14971, revision 2012, is unnecessary (the European Commission certainly does).
And here’s another cheeky attitude from the UK…(sorry, this is not a family channel).
Therefore, I would like to clarify why I feel this way by reviewing how risk is addressed in the MDD (93/42/EEC as modified by 2007/47/EC).
The term risk is mentioned only 4 times in the Articles in the MDD
The term risk is mentioned once in Annex II and III, twice in Annex VII, and three times in Annex VIII and X—for a total of 10 times.
The other 41 times risk is mentioned are in the Essential Requirements (i.e. – Annex I).
When companies submit a Design Dossier for review by a Notified Body, an Essential Requirements Checklist is included. This references, in table format, how all the requirements of Annex I are being met—including those related to risks. Throughout Annex I, a similar phrase is repeated many times. For example, in the first Essential Requirement (ER1) it states: “…any risks which may be associated with [a device’s] intended use [shall] constitute acceptable risks when weighed against the benefits to the patient and are compatible with a high level of protection of health and safety.” In ER2 it states: “the manufacturer must…eliminate or reduce risks as far as possible…”. There is no room in the MDD for consideration of cost or economic impact when the manufacturer is designing a device with regard to risks and benefits.
If a company’s Risk Management Procedure has been found to be acceptable by a Notified Body, and the company has addressed all the Essential Requirements (ERs) with regard to risk, then there should be no impact from these 7 deviations identified in EN 14971:2012. However, if your company has not addressed each of these ERs, then you might want to consider each of these areas:
Treatment of negligible risks
Discretionary power of the manufacturer as to the acceptability of risks
Risk reduction “as low as possible” (ALAP) verses “as low as reasonably possible” (ALARP)
Information of the users influencing the residual risk
My final advice is to review Annex I and Annex X from the perspective of risk management. You may realize that you have some gaps that nobody noticed. After all, audits are just a sample.
PS – I think it’s ironic that the origins of the ALARP principle are UK case law (see link above).
If you have ever taken a lead auditor course, one of the critical handouts for the class should have been ISO 19011. The title is “Guidelines for Auditing Management Systems”. In November of last year, this standard was updated and the changes were not superficial.
The background entertainment for this week is one of my favorite modern rock songs, but it never seemed to get much air time. I hope you enjoyed the 90’s.
ISO 19011 covers the topic of quality management system auditing. This Standard provides guidance on managing audit programs, conducting both internal and external audits, and how to determine auditor competency. Improvements to the New 2011 Version of the Standard include:
Broadening the scope to all management systems
Clarifying the relationship between ISO 17021 and ISO 19011
Introduction of the remote audit methods
Introduction of risk as an auditing concept
Confidentiality is a “new” principle
Clause 5, Managing an audit program, was reorganized
Clause 6, Performing an audit, was reorganized
Clause 7, Competence and evaluation of auditors, was reorganized & strengthened
Annex B is new and the contents of the help boxes was moved to this Annex
Annex A now includes examples of discipline-specific knowledge and skills
One of the most common points of confusion in the lead auditor course is the difference between 1st, 2nd and 3rd party audits. In the previous revision of this Standard, this was just a note at the bottom of page 1 and the top of page two. The note was not very clear either. The new version of 19011, in Table 1 (reproduced below), the difference between these three types of auditing is crystal clear:
The above table is just an example of the improvements made to ISO 19011, and of course there is little value-add to clarifying a definition. Figure 1 from the new version, “Process flow for the management of an audit program, is a better example of a “value-add”. This vertical flow chart is reminiscent of Figure 1 from ISO 14971:2007. It categorizes the various stages of audit program management into the Plan-Do-Check-Act (PDCA) cycle. I highly recommend this style for presenting any process in your internal procedures as an example of best practices in writing an SOP. The flow chart even references each of the clauses in the Standard. Unfortunately Figure 2, “Typical audit activities”, does not categorize the stages of audit activities (Clauses 6.2 – 6.7 of the revised Standard) into the PDCA cycle. I guess they needed to leave some improvement for the next revision.
The new version retained the opening meeting checklist that was in the previous revision (Clause 6.4.2), and Clause 6.4.9 has a brief closing meeting checklist. Figure 3, “Overview of the process of collecting and verifying information”, is a poor example of a flow chart. Should I make a better one? (Send me an email if you think I should.)
The most valuable changes in this revision are Clause 5.3.2, “Competence of the person managing the audit program”, and all of Clause 7. Most of the audit procedures I read neglect to define the qualifications and method for determining competency of the audit program manager. Clause 5.3.2 tells you how. Put it in your own procedure. Most of the procedures I read include qualifications for a “Lead Auditor”, but I seldom see anything regarding competency. Unfortunately, this Standard only specifically addresses “Lead Auditor” competency in a two-sentence paragraph—Clause 7.2.5. When I teach people how to be a lead auditor, I spend more than an hour on this topic alone.
The Standard would be more effective by providing an example of how 3rd party auditors become qualified as a Lead Auditor. 3rd party accreditation requires the auditor to be an “acting lead” for audit preparation, opening meeting, conducting the audit, closing meeting, and final preparation/distribution of the audit report. This must be performed for 15 certification audits (i.e. – Stage 2 certification or recertification), and another qualified lead auditor must evaluate you and provide feedback.
The last big additions to this Standard were the Appendices. Annex A provides examples of discipline-specific knowledge and skills of auditors. This section is a little on the boring side. I prefer to tell a story about the internal auditor that was auditing incoming inspection—but they had no idea how to check for calibration or how to measure components. Appendix B, the finale, has a table (Table B.1) that provides some guidance on how to conduct remote audits (i.e. – desktop audits). I was pleased to see that conducting interviews is a major part of remote auditing in this table. Section B.7 provides some suggestions with regard to conducting interviews, but if you exhibit all 13 of the professional behavior traits found in Clause 7.2.2 then you really don’t need any advice on how to speak with people. For the rest of us mortals, we could use a five day course on interviewing alone.
This week I pulled another song from the movie August Rush.
Thursday, Congress voted 96 to 1 for bill to increase FDA user fees. The rationale is that the FDA needs more funding in order to be strong enough to properly regulate foods, drugs and medical devices. One of the commitments linked with this new funding is to shorten the review of 510(k) submissions. To this end, OIVD has created a new program called “Triage.” The goal of this program is to accelerate the review of certain traditional 510(k) submissions to 30 days instead of 90 days.
In theory this pilot program will help some companies get their 510(k) clearance letter faster, but simultaneously the FDA will be able to concentrate resources on high-risk 510(k) submissions. This entire strategy seems to be the opposite of triage. Triage involves sorting sick patients into three categories:
1) those who are likely to live, regardless of what care they receive;
2) those who are likely to die, regardless of what care they receive; and
3) those for whom immediate care might make a positive difference in outcome.
If we apply the triage analogy to 510(k) submissions, we see three categories:
1) 510(k) submissions that are likely to be approved, regardless of how much time the FDA spends;
2) 510(k) submissions that are likely to be rejected, regardless of how much time the FDA spends; and
3) 510(k) submissions whose approval or rejection is not clear, but the FDA’s earlier involvement in the design and development process would substantially improve the review time.
The FDA’s “triage” program is intended to demonstrate improvement in the time required to approve medical devices by sorting submissions into two groups: group #1 above and group # 2/3 from above. This will make the numbers look good, but the FDA should be spending even less time on the #2 than it spends on the #1 category of submissions. The FDA should also get involved in group #3 submissions much earlier.
The types of submissions that need more FDA reviewer time are devices that are higher in risk and where special controls guidance documents and/or ISO Standards have not already been established for performance and safety testing criteria (i.e. – Category #3 above). In these cases, when a company tries to get some feedback from the FDA the company is asked to request a pre-IDE meeting. The company will not be necessarily performing a clinical trial, but this is the only vehicle the FDA has for justifying the time it spends providing feedback on proposed verification and validation testing plans. The FDA needs to develop something new that is ideally suited for 510(k) products where guidance and Standards do not exist. This would also have the effect of reducing the number of “Not Substantially Equivalent” (NSE) letters the FDA issues.
If a company is developing a device that already has an applicable special controls document or ISO Standard, then the 510(k) pathway should be well defined without the FDA’s help. Unfortunately, there is no easy mechanism for ensuring compliance with these external standards. This type of submission would benefit from software controlled submissions and/or pre-screening of submissions by 3rd party reviewers. The Turbo 510(k) software tool could lend itself to software controlled submissions, but proliferation of the Turbo 510(k) has been limited.
If a company does not submit a 510(k) with all the required elements of a guidance document the submission should not be processed. Implementation of validated software tools for each 3-letter product code would prevent incomplete submissions. At the very least, companies should be required to provide a rationale for any sections of a submission that are not applicable.
One example of a possible software solution is currently used by 3rd party auditors at BSI. BSI uses a software tool that will not allow the auditor to generate a final report unless all the required elements have been completed. The FDA could use the existing screening checklist and convert this into a similar “SmartForm”. If the submission does not have all the required elements of the checklist, the submission form could not be generated from the software. This forces the task of pre-screening reviews back upon the submitter with the aid of a validated software tool.
Of JB’s recommended artists, the Josh Abbott Band was probably my favorite. I especially liked this one. I hope every man is lucky enough to know a girl like Texas. I’m lucky enough to have married a girl that grew up in Texas. They are something special.
We have been discussing the best ways to control design changes at work, and I thought it might present an opportunity to have more of an interactive discussion with my readers.
During my rounds as a 3rd party auditor, I have seen quite a few design control procedures. The most complex consisted of 19 procedures (NOT recommended, but there were no nonconformities). The most simple consisted of one 4-page procedure, which I wrote, but I would never recommend being this brief. I have created a couple of polls in my LinkedIn profile for you to respond to if you would like to share your own company’s “design control stats”:
The problem I see is that most projects are not new product designs. Sometimes the projects are not even major design changes. I think most changes involve supplier changes, component specification improvements, and design for manufacturability. These changes require review and approval of changes. These changes must also be recorded and retained as a Quality Record.
My own personal preference is to always open a design project—no matter how small the change is. In order to make the process flexible, I also prefer to define how many design reviews each project will have in the design plan rather than mandating that design reviews be held in a stage-gate fashion for 100% of projects.
Most companies will have a table of requirements with columns added to indicate if the requirements are mandatory for the project or optional. For example, “risk management plan needs to be updated? Yes/No.” I like this approach, because the table of requirements makes the decision making systematic.
Sometimes a change is only to a work instruction for a step in the manufacturing process. In these cases, some companies will use a document change order process to supplement the engineering change order process.
My feeling is that more complex products (i.e. – Class IIb & Class III in EU and Class III/PMA in US) will require more stringent design controls for the change. What does your company do to control design changes?
This blog website and the blogs within it are gradually being transferred over to my new website: http://www.MedicalDeviceAcademy.com. The titles may change, and there may be minor revisions to the content as the blogs are reviewed and edited. There will be a subscription list created for the new blog site. If you would like to be added to the list for the new blog site, please email me directly at: rob@13485cert.com.
I have no theme to relate this song with my posting, but you just can’t go wrong with blue jeans and a black t-shirt…
You might want to play this video twice…it’s a long posting.
I completed almost 100 audits in the past two years, and I review the Corrective Action and Preventive Action (CAPA) process during every single audit. Surprisingly, this seems to be a process with more variation from company to company than almost any other process I review. This also seems to be a major source of non-conformities. In the ISO 13485 Standard, clause 8.5.2 (Corrective Action) and clause 8.5.3 (Preventive Action) have almost identical requirements. Third-party auditors, however, emphasize that these are two separate clauses. We are purists. Although we acknowledge that companies may implement preventive actions as an extension to a corrective action, we also expect to see examples of actions that are strictly preventive in nature.
Many companies seem to be confused, but it doesn’t need to be. Just ask yourself one question. What is the source of this action?
If the answer is a complaint, audit nonconformity, or rejected components—then your actions are corrective.
If the answer is, a negative trend that is still within specifications or an “opportunity for improvement” (OFI) identified by an auditor—then your actions are preventive.
If you are investigating the root cause of a complaint, people will sample additional records to estimate the frequency of the quality issue. I describe this as investigating the depth of a problem. The FDA emphasizes the need to look to other product lines, or processes, to see if a similar problem exists. I describe this as investigating the breadth of a problem. Most companies describe actions taken on other product lines and/or processes as “preventive actions.” This is not always accurate. If a problem is found elsewhere, actions taken are corrective. If potential problems are found elsewhere, actions taken are preventive. You could have both types of actions, but most people incorrectly identify corrective actions as preventive actions.
Another common mistake is to characterize corrections as corrective actions.
The most striking difference between companies seems to be the number of CAPAs they initiate. There are many reasons, but the primary reason is failure to use a risk-based approach to CAPAs. Not every quality issue should result in the initiation of a formal CAPA. The first step is to investigate the root cause of a quality issue. The FDA requires that the root cause investigation is documented, but if you already have an open CAPA for the same root cause…
DO NOT OPEN A NEW CAPA!!!
If you do not have a CAPA open for the root cause that you identify, then what should you do?
I know this will shock everyone, but…it depends.
The image below gives you my basic philosophy.
Most investigations document the estimated probability of occurrence for a quality issue. This is only half of the necessary risk analysis I describe below. Another aspect of an investigation is to document the severity of potential harm resulting from the quality issue. If customer satisfaction, safety or efficacy are affected by a quality issue—the severity is big. Risk is the product of severity and probability of occurrence.
If the estimated risk is low and probability of occurrence is known, then alert limits and action limits can be statistically derived. These quality issues are candidates for continued trend analysis—although the alert limit or action limit may be modified in response to an investigation. If the trend analysis results in identifying events that require action, then that is the time when a formal CAPA should be opened. If the trend remains below your alert limit, then no formal CAPA is needed.
If the estimated risk is moderate or the probability of occurrence is unknown, then a formal CAPA should be considered. Ideally, you will be able to establish a base-line for occurrence and demonstrate that frequency decreases upon implementation of corrective actions. If you can demonstrate a significant drop in frequency, this verifies effectiveness of actions taken. If you need statistics to show a difference, then your actions are not effective.
If estimated risk is high or there are multiple causes that require multiple corrective actions, a quality improvement plan may be more appropriate. There are two clauses in the Standard that apply. Clause 5.4.2 addresses planning of changes to the Quality Management System. For example, if you correct problems with your incoming inspection process—this addresses 5.4.2. Clause 7.1 addresses planning of product realization. For example, if you correct problems with a component specification where the incoming inspection process is not effective—this addresses 7.1. Depending upon the number of contributing causes and the complexity of implementing solutions, the plan could be longer or shorter. If it will take more than 90 days to implement a corrective action, you might consider the following approach.
Step 1 – open a CAPA
Step 2 – identify the initiation of a quality plan as one of your corrective actions
Step 3 – close the CAPA when your quality plan is initiated (i.e. – documented and approved)
Step 4 –verify effectiveness by reviewing the progress of the quality plan in management reviews and other meeting forums…you can cross-reference the CAPA with the appropriate management review meeting minutes in your effectiveness section
If the corrective action required is installation of new equipment and validating that equipment, the CAPA can be closed as soon as a validation plan is created. The effectiveness of the CAPA is verified when the validation protocol is successfully implemented and a positive conclusion is reached. The same approach also works for implementing software solutions to better manage processes. The basic strategy is to get the long-term improvement projects started with the CAPA system, but monitor the status of these projects outside the CAPA system.
Best practices would be the implementation of Six-sigma projects with formal charters for each long-term improvement project.
NOTE: I believe in closing CAPAs when actions are implemented, and tracking the effectiveness checks for CAPAs as a separate quality system metric. If closure takes more than 90 days, the CAPA should probably be converted to a Quality Plan. This is NOT intended to be a “work around” to give companies a way to extend CAPAs that are not making progress in a timely manner.
I thought I would expand my usual musical range to include some of the music I grew up with. I hope you enjoy this fantastic performance.
I hear this question, or a question with similar wording, quite frequently when I am auditing. Typically the question is in response to a better way to do something that seems simple and efficient. Most people seem to approach regulatory requirements with the approach of…let’s bury the regulator. While it’s true that we expect a certain amount of paperwork with each regulatory requirement, we frequently are accepting of a much broader range in stack heights. For example, a design controls procedure could be a one page flow-chart that references forms and work instructions. A design controls procedure could also be twelve separate documents with a minimum length of ten pages and a maximum of forty pages per document. As long as the procedure has sufficient detail for the people performing these tasks and all the required elements are included, ISO clauses 7.3.1-7.3.7, then we have no choice but to identify the procedure as conforming.
The above example is the perspective of an auditor looking for CONFORMITY!
However, some people are inspectors that are looking for NONCONFORMITY!
In the case of inspectors, it is critical to present your information in such a way that it is easy for the inspector to see how you meet the requirements of the regulations. One of the best ways to do that is to reference the requirements directly in your procedures.
For those that prefer finesse…try to organize information in accordance with the regulations. For example, if I am writing a procedure for an ISO registration audit, I write the procedure to specifically address the ISO sub-clauses. I might even use a document control number like: SOP-73 for my “Design and Development” procedure. Alternatively, if I’m writing a procedure for a JPAL audit, I might change my document control number to SOP-3036 for my “Design and Development” procedure. This matches up with JPAL Ministerial Ordinance #169, Articles 30 through 36. In this case, the document control number suggests compliance with the Japanese regulations. A little subconscious suggestion couldn’t hurt.
In my previous blog posting, I suggested a slight change to the scheduling of internal audits. In order to make sure this meets FDA requirements, the key is to READ THE REGULATIONS AGAIN. With regard to internal auditing, the applicable FDA regulation is: 21 CFR 820.22:
“Each manufacturer shall establish procedures for quality audits and conduct such audits to assure that the quality system is in compliance with the established quality system requirements and to determine the effectiveness of the quality system. Quality audits shall be conducted by individuals who do not have direct responsibility for the matters being audited. Corrective action (s), including a reaudit of deficient matters, shall be taken when necessary. A report of the results of each quality audit, and reaudit(s) where taken, shall be made and such reports shall be reviewed by management having responsibility for the matters audited. The dates and results of quality audits and reaudits shall be documented.”
The above requirement is quite vague with regard to how many auditors and how many days must be spent auditing. These are the variables I suggested changing in my previous posting. The FDA regulations are specific, however, with regard to documenting the “reaudit” of any deficiencies found during an audit. This prescriptive requirement can be met by reviewing previous audit findings of all audits with the audit program manager during the audit preparation process. The audit program manager can facilitate the assignment of which auditor will reaudit each finding. This may require a few more minutes of audit preparation, but this should not measurably impact the overall time allocated to an audit.
Somehow the above prescriptive requirement slipped my mind. I do this out of habit when I am performing internal audits on behalf of clients, but if I am auditing the internal audit process of a client—now I’ll remember to point out this additional requirement that is specific to the FDA and not included in the ISO Standard. This is why we should always READ THE REGULATIONS AGAIN.
Hats off to Woodson and the rest of the Packers! My team was the Patriots, but I’m happy to see that the Packers showed some real heart and overcame their injuries to win the trophy. As for the half time show…I thought it was more lights than music. I included a link to the half-time show at the end of this blog, but I thought the Black Eyed Peas video called “The Time (Dirty Bit)” is much more entertaining.
For those of you familiar with the ISO 14791:2007 Risk Management Standard, you may have already figured out the topic of this blog. For the rest of you…did you really think I tried perfecting my recipe for pecan pie nearly 15,000 times?
A couple of years ago, a client of mine asked me to give them a training course on Risk Management—specifically an overview of ISO 14971:2007. In my struggle to find a fresh way of engaging the interest of my client’s employees, I developed the concept of using the principles of Risk Management in a more tasty application. Back in 2006 I developed a five-minute presentation on how to make “The Perfect Pecan Pie.” For this new three-hour presentation, I tortured my students with a homemade pecan pie that I placed in the middle of the conference room table.
This presentation included several tools to help my students remember the principles of Risk Management. First, the alliteration of the letter “P” throughout the presentation beat my message steadily into their subconscious. My second weapon was the smell of a warm, fresh, pecan pie. Third, I used analogies to the pecan pie making process for each aspect of the Risk Management Process. Fourth, I used vivid descriptions throughout my presentation to help everyone visualize the sweet, praline confection at each step of the baking process. And finally, I burned the experience into their brains forever with the taste of the Perfect Pecan Pie.
Not everyone loves Pecan Pie as much as I do, and not everyone has tried making the Perfect Pecan Pie as many times as I have. I have made gooey pies, sickeningly sweet pies, pies that crack and crumble, pies that were barely cooked, pies without a crust, and pies without a filling. If you plan to coordinate your entire presentation around the concept of a homemade pecan pie you made in your kitchen last night, you had better have a proven Risk Management process to reduce the risk of embarrassing yourself.
Please read my next several blogs as I unveil the secret to making the Perfect Pecan Pie—one slice at a time:)
Here’s some of the half time show…(assuming the link is not taken down).
Knowing that we have the “Big Game” half-time show coming soon, I thought I would share a video of the 2007 show by Prince (Thank you for the suggestion Greg).
During a CAPA course I taught earlier today, one of the attendees asked if I have a course on “How to Write Better Procedures.” Unfortunately, the only material I could offer was material from a course I taught on “Training the Trainer.” That training course focused on visual communication. There are several books related to Lean Manufacturing that explain in depth how to use visual communication to replace text (i.e. – “a picture says a thousand words”). During my ride home, however, I thought of a few other ideas that might help anyone that is in the process of writing or re-writing a procedure.
My first suggestion is to develop a standardized format for procedures. If you have a procedure for writing procedures, just make sure you allow the flexibility to deviate from the standardized format. The Standard does require that procedures have a “mandatory” format. Referring to the standardized formatting as “suggested formatting” will avoid unnecessary nonconformities.
My second suggestion is avoid making unnecessary references to other external standards. If you are writing a procedure on risk management—it makes sense to reference ISO 14971. It does not make sense to reference all the other risk analysis Standards unless you are specifically using them to perform risk analysis. Included in this category would be references to other regulatory requirements such as 21 CFR 820, the FDA QSR, or Part 1 of the Canadian MDR. Companies can claim compliance with other requirements in the Quality Manual instead. What should be referenced in a document is any related procedures or forms.
Another related suggestion is to avoid including the revision of a Standard. This is just another opportunity for unnecessary nonconformities. If you don’t specify the revision, then an auditor can only assume that the most current revision of the Standard is implied. If changes to a Standard are minor, no changes to a procedure may be warranted and a revision to the procedure can be avoided—assuming that the revision of the Standard is not specified. Some argue that you should include the revision and update the reference to document that the procedure was reviewed to see if changes were warranted. This is unnecessary. A review of procedures, where the decision is made for “no change”, can easily be documented in the Management Review under the category of “New and Revised Regulatory Requirements.”
My fourth suggestion is to indicate the process owner and training requirements associated with each procedure. By doing this, it is easier to define who is responsible for reviewing and revising procedures—as well as who is assigned CAPAs if there is finding related to the process in question. For the training requirements, the process owner should specify who needs to be trained on the process. Why? They know the procedure best. If there is a “grey area,” this should be resolved with the department manager for the job function in question. In addition, retraining requirements should be specified. By this, I mean that it is a good idea to indicate if retraining is required when a procedure has been revised. If the revision is minor, training should only be required for people that have not been trained to a previous revision.
There are a couple of great ways to identify when retraining is required for a revision and when no retraining is required, but I’ll leave those ideas for another blog…
My fifth suggestion is to adopt the Plan-Do-Check-Act (PDCA) model for the structure of procedures. For the “Plan” portion, the procedure should explain how to prepare to do something. This planning activity can apply to anything from planning to perform an audit to planning to inspect incoming raw materials. The “Do” portion is what most people refer to as the “Procedure” section. The “Check” portion of the procedure is a great place to specify the monitoring and measurement requirements for the process (see Section 8.1 of the Standard). Finally, the “Act” portion of the procedure should indicate what to do when target metrics are not met. For example, what should be done when an alert limit is reached? What should be done when an action limit is reached?
My final suggestion is to include revision history. It’s extremely helpful to know which ECO approved the document revision, why the changes were made, the nature of changes, whether there is a related corrective action, and when the change was made.
Sorry about the length of this blog…I hope this helps you Darcy.
I just wanted to thank everyone for reading my blog. It's hard to make the dry and boring worth reading about. I have also created a formal Thank You page on my personal website: http://13485cert.com/qc-is-dead/.
Blog Stats
113,240 Views All Time!
Countdown to 2-Day Course!
Best Practices in Audit Program ManagementMarch 9, 2013
13485cert
QC is Dead 