Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

ISO 17025:2017 Format for Procedure and Records

fahimk

Starting to get Involved
#1
Hello.

ISO 17025:2017 demands various procedures and records. Apart from the footer and header, which need to be customized, what is the recommended format for 'procedure' and 'record'? Normally, procedures need to be in a standard step-by-step form. And, what about the record? Should it be like a list of date and action(s) form?

Any samples?

Thanks
 

Benjamin Weber

Involved In Discussions
#2
A procedure may be a process, standard operation procedure or similar. For process descriptions there are several different types of fomrat. You can either describe every step of the process in text one step after the other. Or you can use a flow chart type. In a process it should be clear what is the input and what are the steps to reach the output. Additionally the responsibilities should be clearly described. This starts wiht the responsible person who takes care that the process is being followed and ends with a clear description, who is repsonsible for each process step. It might also be helpful to add other stakeholders, for example who is informed about certain process steps. I personally like the swimlane diagram a lot, because you can easily see, who has to do what and how the relations between different process are.

A process might reference more detailled descriptions, often called standard operation procedure. This may be the description how a certain test or calibration procedure is actually performed. You could look at this like some kind of operation manual for specific tasks. Sometime these can be quite straight forward, sometimes they can be very complicated, depending on the complexity of the procedure they are describing.

The format of records should be individually adapted to the application. I don't think it is possible to prepare such a generic report template. A record may be a checklist that is filled in always before a certain test or calibration is performed. But also a management system review report or an internal audit report is such a record. A signed NDA may be such a record. A calibration certificate of your test equipment may be a record. The records should enable you to show the auditor, that you work according to your procedures.
 

Marc

Captain Nice
Staff member
Admin
#3
Just to add... There is a difference between a requirement for a "documented procedure" and a "procedure" when a requirement is stated in a standard. There are "undocumented procedures".

This is old (circa 1999), but things haven't changed. See: Marc Timothy Smith - Accolades
--> help. You're advice was extremely important. Especially important,
--> at least in my opinion, was your help in determining where we did
--> not need to document every last thing (by using training, etc.). I
--> think that without this input, we would have spent a lot more time
--> writing things that we did not need and wasted a lot of peoples'
--> time. We were able to get the audit done in a year while we are
--> achieving record sales and profits.
 

John Broomfield

Staff member
Super Moderator
#4
fahimk,

Firstly, your system documents are designed for use by competent employees and should not try to compensate for any lack of competence. Competence comes from recruiting and training; reading procedures not so much!

You need only document to the extent necessary for your system to be effective. Over documentation may lead to as much ineffectiveness as under documenting so you are seeking a balance or optimum (per the process owner’s assessment of risk).

The format of data collection devices (aka forms) and documented procedures and instructions is whatever works effectively for your lab. Please note that some forms can also be instructions.

I recommend that you take the user direct to the action by putting all the document control stuff (in a standardized place) at the bottom or on the last page.

What users find useful is to know is what to expect when their process (or task within a process) is effective. So, at the top of each documented procedure or instruction, just under its title, define the objective of the process (or task) that is specified by that procedure (or instruction).

Those tasks we do only occasionally may need documentation especially designed and posted specifically for that situation such as operating an item of rarely operated equipment or an emergency exit sign.

Best wishes,

John
 
Top Bottom