|
< 1 min reading time
When you update your procedures for ISO 13485:2016 compliance this year, will you also be updating your template for procedures? My current procedure template has the following sections: Most companies include definitions, but I find that there are inconsistencies between procedures for the same term. Therefore, I place definitions in a glossary that is a standalone controlled document. The risk management section was added to facilitate a risk-based approach to all procedures, and the monitoring and measurement section helps to identify quality objectives for each process. However, many of my clients want to make changes to flow charts and have trouble maintaining them. Therefore, I’m thinking of removing them from procedures altogether. What do you think? I was thinking of including flow charts that are helpful in explaining a process in training documentation only. The biggest advantage of removing the flowcharts from the procedures is that it simplifies the procedure. Procedures will be shorter and require fewer updates to prevent inconsistencies. This change reduced the length of my training procedure by 3 pages. Other revisions shortened the overall procedure down to a final length of 4 pages, and the original version was 8 pages long. Do you have any procedure enhancements to suggest? If you are interested in reading more about the changes I made, please visit my blog: http://www.medicaldeviceacademy.com/blog. Please visit my new website this Thursday to see another blog posting: https://www.fdaecopy.com/. source: https://www.linkedin.com/groups/2070960/2070960-6229888878619164676 Marked as spam
 Posted by Asked on January 25, 2017 12:00 am
109 views
|
Meet your next client here. Join our medical devices group community.
Private answer
Personally, as an FDA regulatory consultant, I frequently find errors in SOPs when companies have a "Responsibilities..." section. When revising SOPs, sometimes , 'who' does 'what' often changes within the text. The possibility exists that the "Responsibilities" does NOT get changed accordingly, especially when you go through multiple revisions. A well-written SOP always tells the reader 'who' does 'what', making the 'responsibilities' section superfluous. If a "Responsibilities" section exists within your template, and you have a fairly mature system (multiple revisions within your documents), I'd do a sample of SOPs looking specifically for disconnects between the 'responsibilities' section and the text. In my experience, you will find disconnects, causing confusion within your procedures, and a "gotcha" for any audit process.
Marked as spam
|
|
Private answer
Eckhard Jokisch
From the systems engineering view it would be really good to separate the flow charts from the procedure document. Flows are done very easily in a formalized way and can be put into executable SYSML-models. By this you will be able to find dead ends and options for improvement nearly automatic. You then can also add the textual description into SYSML and export this as the documentation.
This also enable creating traceability linkage so you always can see which document is based on what flow and in what version. And you can even see if the document is outdated as the link will signal that the flow model (and chart) have been changed. Marked as spam
|
|
Private answer
Ivan Liljegren
We have process descriptions for each main business process to explain the overall workflow within the process. This way the SOP can focus on the specifics of a particular procedure / subprocess.
Marked as spam
|
|
Private answer
I have run across a number of clients that have opted for making the procedures 90% flow chart and very little text. This was somewhat new to me but the more I work with it, the more I like it. You can say what you need to say in the flow chart so you do not have to repeat it in text. I suppose it takes all kinds!!
Regarding changes for 2016, I like adding the section on Risk Management. Marked as spam
|
|
Private answer
Sonja Holten
I like sharepoint for my flow charts. Putting them there as a clickable PDF and linking them to the appropriate procedures, lower level flows and templates, training materials etc. They are maintained as seperate controlled docs. It also provides for an easy access to the QMS system for my users. Works better than dumping everything in a long incomprehensible list with several layers and sections.
Marked as spam
|
|
Private answer
Markus Angst
Some like flow charts, some don't. Romans said "De gustibus non est disputandum".
Marked as spam
|
|
Private answer
Kiran SM
Robert Packard, the table of contents looks complete. I would retain the flowchart. While its maintenance is tough, I always find that a visual representation of the flowchart provides a simple way of summarising the process. It is also useful in training.
Marked as spam
|
|
Private answer
Mark Swanson
I really think this misses the implementation of the risk-based approach. It is not necessary to establish a formal risk management of each procedure or process. Rather, you should be considering at all points where the process fails to meet a requirement (internal or external) and provides some level of risk (product safety & performance or regulatory compliance). You SHOULD NOT be doing a process risk analysis for your QMS processes. To identify risk within a section of a procedure seems to do this.
Furthermore, we need to progress beyond the concept of training requirements and toward the need to establish competency for procedures and processes (meeting requirements). Again, having a 'training' section seems not to fit within a procedure, but should be with the individual (and their managers) to understand any gaps to establish their competency. Much more discussion is likely required for industry to understand the intent that was behind what we wrote within the standard. Marked as spam
|
|
Private answer
Gordon Skiba
I agree with most of those items you captured, but I try to avoid effective date and author, approval and revision history
Marked as spam
|
|
|
Private answer
Gordon Skiba
I agree with all other items but:
1) Header - Leave off Author and Release Date (these are on your document control form (ECO, DCO, EN, CO, etc.), 2) Revision History - Leave off, found on you Doc. Cntrl. frm, 3) Monitoring & Measurement - Optional, not required on all SOP's/WI, 4) Training & Retraining - Optional, typical application for Mfg. WI's, while QMS SOP's are denoted by Job Description (i.e., Training Matrix). Preference is a stand-alone SOP specific to Employee Training. Putting all training, certification, questionnaire's etc. results in cumbersome Mfg. WI, 5) Records - Forms/templates list associated SOP in the footer; SOP/WI lists Records created in Ref. Doc's section (or in proximity to it), 6) Flow-charts, well accepted, takes time to create; reflects input/outputs and can be easily comprehended by employees - Leave In. 7) No-one reads glossaries, and if your procedures requires a separate doc. to understand what you're reading, you'll have comprehension issues... Marked as spam
|
|
Private answer
Marked as spam
|
|
|
Private answer
Gordon Skiba
Most of your content I agree with, but I don't like having approval date, revision, author, or release date.
These items can be obtained from your document change approval form (i.e., eco, dco, en, etc.). I see no purpose in including these items on all documents and records; they take up space and become confusing when you try to locate the actual revision of the form or document number. As for flowcharts, I try to incorporate them in my procedures (SOP/Work Instructions) as they help clarify the intent of the document. They'll provide both inputs and outputs, and are ready means of enforcing your reference documents. Depending on the document, you may not need training, and that should be an option. If you include all of your training and certification requirements within a document, instead of having a process which is easily comprehensive , you know are stuck with a 20-year 30-page document which most people are both to pick up and read, let alone come for him. Keep the training documents separate where you can, that way they're applicable to the people being trained versus staff who just have to read and understand. Marked as spam
|
|
Private answer
Karen Boyd, ASQ CQA
Great ideas, Rob! Incorporating risk management and monitoring / measurement sections puts these requirements in the forefront for all procedures (and key processes) -eliminating risk of forgetting them.
Marked as spam
|
|
|
Private answer
Ee Bin Liew
None - no changes needed based on the current (no longer new) revision. As a note: anything risk management or applicable regulatory requirements based should be embedded with the relevant procedures if they are not already included originally (as many companies would have figured out it makes good sense)
be it words, flowcharts, tables, images, videos, Braille ... whatever works for the organisation to communicate effectlvely, works. Cheers, Ee Bin Marked as spam
|
|
Private answer
Gabriel Adusei, MSc, PhD
Thanks Rob. For many of our colleagues, the adoption and full appreciation of the risk-based approach to QMS is trickling into the systems they use. Please can you elaborate on how the sectionsare to be handled? :
9. Monitoring & Measurement 10. Training / Retraining 11. Risk Management 12. Records Thus, what and the level of detail of information that go into those sections. This is also in support of your approach in shortening the pages of any given procedure. Thanks. Marked as spam
|
|
|
Private answer
Thanks Rob, great question to get discussion going. I would agree with many of the reviewers , training requirements to be covered in a separate matrix where possible, in line with MDD requirements have 'competency ' matrix for key roles re experience , skills, education (mainly those related to design and risk management activities ) . High level flow charts are great for readers getting a top level overview, therefore little work in updates for minor changes. Also agree that risk management is not needed for every QMS procedure , as it should be process based. Again the template looks ok , just depends on the level of detail you put in each section. Some header sections may just be a one liner referring to the governing procedure e.g. Training or DCN
Marked as spam
|
|
Private answer
Yi Grace Lin
This is indeed a great topic and thanks for everyone's thought and input. I would also be very interested to learn what would be included in the section 11 Risk Management.
Marked as spam
|
|
Private answer
Rob Packard
In response to Kathleen's questions, I was referring to top-level SOPs. When detailed work instructions are needed I create those separately. The detailed work instructions are typically used for things like: calibration instructions, assembly instructions, how to complete a computer form, etc. In general I try to use forms that are self-explanatory or have guidance directly on the form or in a training curriculum. When this isn't practical, then I use a work instruction.
Marked as spam
|
|
|
Private answer
Rob Packard
In response to Gabriel's question there was a comment by one of the authors of ISO 13485:2016 that suggested a performing a process risk analysis of the procedure is not what we should be doing. I think we have people on both sides of the opinion for that, but my personal preference is to identify a metric for each process that indicates the effectiveness of the process. Your metric can change over time. I like to select a metric that helps me identify where there is a risk of the process being out of compliance or helps me identify areas for improvement. Anywhere there is a manual process that relies upon people following the procedure I like to incorporate a metric. The basic concept is "what gets measured gets done." For training / retraining I just identify what kind of training different roles should be getting and if the procedure is revised, then I indicate the retraining requirements.
Marked as spam
|
|
|
Private answer
Rob Packard
To continue...The records section just lists the quality system records from the process. Ideally it says who is responsible for the review of the records and where the records are kept.
Marked as spam
|
|
Private answer
Malcolm Applewhite
I find that an appendix to the Control of records procedure indicating each process and their respective records as well as the responsibility, location and how long the documents should be retained for is a fantastic summary of all company records.
Marked as spam
|
