Quality System Processes without Documented Procedures

[Mark Meer]

...Also, what really control the risk is the action (or inaction) of the user to prevent the problem, not the instruction itself.

I think this is precisely @Bev D point regarding documented procedures, and why I think the comparison is apt.

Similarly, to my point, if the context of your organization demonstrates a utility in having documented instructions (such as the PCB receiving example I gave in a previous post), then it is a valuable control - much in the same way, as you say, safety information can be demonstrated to still be a legitimate risk mitigation measure through usability engineering.

 

[Marcelo]

I think this is precisely @Bev D point regarding documented procedures, and why I think the comparison is apt.

Similarly, to my point, if the context of your organization demonstrates a utility in having documented instructions (such as the PCB receiving example I gave in a previous post), then it is a valuable control - much in the same way, as you say, safety information can be demonstrated to still be a legitimate risk mitigation measure through usability engineering.

Well, it's important to understand that people are not expected to read the manual each time they encounter the risk. It's expected that the "information for safety" is used to convey the information, but the action/or inaction has to be done without (in principle) reading about the problem when it happens - which is the case of high risks. If people are dying, the time to read the manual may be enough for people to die.

In this way, the information is only expected, in general to be read once, and them people would be competent.

The fact that the information is still there after that does not control anything.

 

[Mark Meer]

...In this way, the information is only expected, in general to be read once, and them people would be competent.
The fact that the information is still there after that does not control anything.

In general I agree. However, there is still the case of labelling (e.g. safety symbols) that are applied directly to the product - an informational requirement that wouldn't make sense if we assume the above.
(aside: I have some serious reservations regarding the efficacy/rationale of many required symbols. Similar to your explanation of "The crazy EU deviation", I suspect that such requirements were put forth by "someone with no [usability] engineering background"....but a topic for another thread, I suppose. )

But back to the topic at hand...
I still think the analogy holds for certain manufacturing contexts. Whether or not the information is intended to be read once (in the case of information for safety on product labelling), or several times (e.g. in the case of an assembly work instruction), in either case once competency is achieved the documentation is no longer an active control. But to the extent that we agree that such documented information can contribute to the competency in the first place, it is a valuable tool for controlling final outcomes, no?

 

[Marcelo]

In general I agree. However, there is still the case of labelling (e.g. safety symbols) that are applied directly to the product - an informational requirement that wouldn't make sense if we assume the above.

Symbols on labelling are a little different because they behave more like alarms - meaning, they do tell that something is happening, but the person has to act or inact.

(aside: I have some serious reservations regarding the efficacy/rationale of many required symbols. Similar to your explanation of "The crazy EU deviation", I suspect that such requirements were put forth by "someone with no [usability] engineering background"....but a topic for another thread, I suppose. )

He's a lawyer.

Also, the symbols by themselves are not effective if the manufacturer does not "validate"their use in their medical device thru usability testing or the like.

But back to the topic at hand...
I still think the analogy holds for certain manufacturing contexts. Whether or not the information is intended to be read once (in the case of information for safety on product labelling), or several times (e.g. in the case of an assembly work instruction), in either case once competency is achieved the documentation is no longer an active control. But to the extent that we agree that such documented information can contribute to the competency in the first place, it is a valuable tool for controlling final outcomes, no?

It is, in particular because it has other uses (such as keeping the information for a new worker, facilitating audit, etc.).

But what seems to be the cern os this discussion is the need for documentation in general, not only for one use (such as enabling competency).

And the thing is, people in general are still too much focused on equating a quality system with a system of documents, when in reality is that que quality system is people working (I usually say, it's the worker pushing the button, not "only" the documentation the documentation that says he must push the button, if any).

I understand that this "interpretation" has several reason, being the historical focus, particularly from evaluators, in documentation, but what is important to understand is that documentation should be a defined requirement for any process, iF required, not always required per se, meaning, you should CONCLUDE if documentation is required, not presuppose that it always is.

 

[mattador78]

I think you just described the challenge of managing knowledge in your organization, so as I said before, documentation is a dynamic component of knowledge management.

An interesting story in that regard relates to my grandfather, from the age of 14 (minus his national service in Germany and Korea) he worked as a wood machinist and trained on specialist machines manufacturing bespoke work for all over the world. He moved for the last 10 years of his working life to our local government, manufacturing windows and doors for council houses. They had a machine there which only he had been trained to calibrate and because of its age there were no instructions and no manufacturer to contact anymore, he decided to take early retirement due to industrial injuries (COPD) but was kept on as a consultant to calibrate this machine when required paying him a retaining fee weekly as they were going to decommission that department. Due to poor documentation it was 5 years after they decommissioned it they realised they were still paying him a consultant fee which he was able to keep as they never told him it was removed he was just waiting for his weekly call lol.

 

[Jean_B]

Also, the symbols by themselves are not effective if the manufacturer does not "validate"their use in their medical device thru usability testing or the like.

It might be, it might not be. You should not state or claim it though as you cannot substantiate it absent of such evidence. This is where I think we're lucky people tend to use symbols/warnings in some form and place which gets some people thinking/cautious, even when the evidence for that hasn't been thoroughly tested to be as effective as the manufacturer might think. It often (though not always) leads to a reduction of risk in the sense of direction, though manufacturers might over- (or under-)estimate the effect. Good intentions are at least something.

And the thing is, people in general are still too much focused on equating a quality system with a system of documents, when in reality is that que quality system is people working (I usually say, it's the worker pushing the button, not "only" the documentation the documentation that says he must push the button, if any).

I understand that this "interpretation" has several reason, being the historical focus, particularly from evaluators, in documentation, but what is important to understand is that documentation should be a defined requirement for any process, iF required, not always required per se, meaning, you should CONCLUDE if documentation is required, not presuppose that it always is.

True, yet the interaction of processes as required is often either built from the documented procedures, or leads to a request to document that process (due to auditor). A process without a procedure (and usually just a name/description) seems hard to audit for most auditors, and they've always had sufficient wiggle room in the requirements to 'make it so'.
Perhaps a clarification to document as appropriate (conforming product; compliance; carry out corrective action; manage risks) could be embedded at (some of) the relevant points in standards that guide this thinking.
I.e. for ISO 13485:2016:

• 4.1.1 first paragraph "document" should be changed to "(establish), implement and maintain", as this can currently be used as a cover-all escape to enforce documentation of the system which encompasses everything without limitation to level.
• 4.1.2 a) clarify that identifying a process (and its place in sequence/interaction from item c)) is sufficient documentation does not mandate detailed procedural documentation describing the (detailed) how's, who's, when's and with's.
  • Example: note a high-level description/prescription in the quality manual or a referenced overall process-map, and noting that that is sufficient control to ensure conforming product, maintain compliance, carry out corrective action and manage risk (building on the competence of your resources/training system).
  • It's these last two items (carry out corrective action and manage risk) that might be scrutinized through data/records etc, or be the first option to build in further control through documentation if other information shows there is too little control this way. But auditors should refrain from that assumption until they have evidence to that effect.
• 4.1.2 b) clarify that control may include documentation (procedures, etc.) as appropriate.

We'll probably head towards it anyway (in some shape) once we align ISO 13485 to the High Level Structure come the mid 2020's.

As for how people write procedures, descriptive, prescriptive and teaching are three different styles and for the auditor's sake we most often see the first (descriptive), a lot of the second (prescriptive) due to over-policing attitude* of certain QA departments, and most miss out the teaching aspect which helps in people using that document to become and be competent on the process even in its absence. Some go too far and teach so much at once or in such a way it's as if that teacher from high-school who just droned on conveying perhaps information but losing your attention while doing so (thus not imparting lasting knowledge) came back to haunt you.

*I'm not saying the policing attitude should be removed, but a procedure used solely as a stick at best helps adherence, not competence.
**Sorry for droning on lately. Writing is also a way of thinking and I see elsmar not only as a forum for discussion but also a resource of knowledge for some future straggler happening upon our musings, not in the flow or aware of the context.
***Really stopping now.

 

[Mark Meer]

...
**Sorry for droning on lately. Writing is also a way of thinking and I see elsmar not only as a forum for discussion but also a resource of knowledge for some future straggler happening upon our musings, not in the flow or aware of the context.
***Really stopping now.

No apologies necessary! That's what the forum is for: discussion, airing ideas, and constructive criticism!
Don't apologize, and don't stop contributing to discussion - your contributions enrich everyone.

 

[Ed Panek]

The FDA will sometimes allow personnel education level to alleviate training or SOP details. For example, if an MD who studied biopsy is required to review a slide for a biopsy reason there may not need to be much detail how he is instructed to review it. On the other hand, if the person is not an MD you would need more detail in the process or exclude people without specific education from performing that step.

 

[Crusader]

Recently, a CB said to me "Training is not acceptable in lieu of a work instruction." I disagreed. I did not get an action/finding. I am really annoyed with how different auditors interpret the standard differently. We rely on training heavily due to the nature of the product and the near impossibility of any drawing or instruction to be created for someone to follow or use as training. Every order is unique. I'd be writing a work instruction for every customer order placed, every day. I'd never get anything else done.

 

[Ed Panek]

4.1.3 For each quality management system process, the organization shall:
a) determine criteria and methods needed to ensure that both the operation and control of these
processes are effective;

Work instructions are an option, so is training, or education or experience. Its up to YOU to determine how.

I used to work in a technical support role. The process of receiving a call and fixing a customers problem could never be created in instructions or flowchart; the details were endlessly possible. In the end we categorized each call into various buckets of known failure modes and worked on those.

Companies who try to force activity like this into a script like ISPs do "reboot your router" drive customers mad.