Documentation structure - Do I need Work Instructions?

[James]

Hi all

Just wondered if anyone thinks this approach will be an issue? The system sits in a wider corporate and divisional structure.

I'm also thinking that instead of work instructions, I'll specify Device quality indicators instead? - appropriate?

 

[Jim Wynne]

This is the traditional documentation pyramid, and if it works for you, it's fine. I don't know what the bit to the right means, though, nor do I understand the idea of "device quality indicators" as opposed to work instructions.

 

[Marc]

I have moved this discussion thread to the appropriate forum: Document Control Systems, Procedures, Forms and Templates

I highly recommend that you read through some of the many existing discussions here. Note that ISO 13485 has no required documentation structure or naming techniques.

The document pyramid is very 'standard and not an issue as Jim says. Some others: Document Pyramid Examples

 

[Randy]

In the end it doesn't really matter what you call anything or how you make it all happen as long as people that need to know, know, and you manage the process. I'm one of those "3rd party guys" and I honestly don't care what your structure looks like as long as it can be explained and proven to work as designed/defined, so go for it.

 

[James]

Great, thanks for the comments. I figured that naming conventions were just semantic. I don't want to use the term 'work instruction' as it implies detailed steps. Instead, I want to have much looser quality indicators; eg, you know how to build this product because you are a qualified technician and have seen the device technical documentation / image archive, but this is what 'quality' looks like for this device family, and we'll measure quality against these.

Quality System docs sit underneath corporate policy and alongside uncontrolled documents for each department; but if and when work activities hit the QMS scope, work is controlled and directed by the system. Only a very small amount of what we do hits the scope, so the system is nestled amongst much wider / informal systems.

Clear as mud! The Quality manual should clarify things I hope

Thanks again

James

 

[Sidney Vianna]

Quality System docs sit underneath corporate policy and alongside uncontrolled documents for each department; but if and when work activities hit the QMS scope, work is controlled and directed by the system. Only a very small amount of what we do hits the scope, so the system is nestled amongst much wider / informal systems.

Be VERY careful. One of the most typical and "deadly" mistakes when developing quality systems is to think that quality (and the quality system) lives/exists outside of the organization business processes. That is the surest way to sabotage your quality system maturity journey. Organizations who don't understand that are ALWAYS fighting a corporate dysfunction towards quality excellence. Until people understand that sustainable quality can only exist when it is seamlessly and stealthly embedded in the way business happens, it will be a Sisyphusian uphill battle.

If you REALLY want to delve into this, you could find direction from ISO/TR 10013:2001 - Guidelines for quality management system documentation, a document that is being revised and will become ISO/DIS 10013 Quality management systems — Guidance for documented information.

But the key thing to remember is that documentation (IN ANY FORM/MEDIA) serves the purpose of controlling processes and activities and have to fit the context of the organization and it's inherent risks. The pyramid approach is very archaic.

Good luck.

 

[James]

One of the most typical and "deadly" mistakes when developing quality systems is to think that quality (and the quality system) lives/exists outside of the organization business processes. That is the surest way to sabotage your quality system maturity journey. Organizations who don't understand that are ALWAYS fighting a corporate dysfunction towards quality excellence. Until people understand that sustainable quality can only exist when it is seamlessly and stealthly embedded in the way business happens, it will be a Sisyphusian uphill battle.

The reason for designing our approach in the way I've described is essentially to make it work and be a meaningful quality management system. We are a huge organisation; making medical devices is a tiny bit of the work that we do, but when we do it, we want to do it to a high standard and provide assurance to our customers that this is the case. We cannot expect or demand that the organisation flexes around our QMS policy and documentation requirements in that regard; it just needs to be concordant with it. Quite frankly, making medical devices does sit outside of many of our other organisational policies and procedures, but where this activity needs to, it will interface with relevant business processes. I understand the sentiment of your point, but National Health Systems are complex beasts. I'm describing a system that sits within and alongside other systems.

 

[John Broomfield]

Indeed.

Quality services and products are delivered by management of the organization as a system that is the business management system.

Best for the QMS to integrate with and leverage this system instead of it being seen as separate.

 

[Jim Wynne]

The reason for designing our approach in the way I've described is essentially to make it work and be a meaningful quality management system. We are a huge organisation; making medical devices is a tiny bit of the work that we do, but when we do it, we want to do it to a high standard and provide assurance to our customers that this is the case. We cannot expect or demand that the organisation flexes around our QMS policy and documentation requirements in that regard; it just needs to be concordant with it. Quite frankly, making medical devices does sit outside of many of our other organisational policies and procedures, but where this activity needs to, it will interface with relevant business processes. I understand the sentiment of your point, but National Health Systems are complex beasts. I'm describing a system that sits within and alongside other systems.

While I tend to agree with Sidney when it comes to the archaic nature of the pyramid, I still say that if it works, it's OK. We're not in a position to see what you see. I will say, however that with regard to "quality indicators," it's almost always a mistake to believe that if you change the name of a thing, the nature of it will change. They're still instructions.

 

[Marc]

The pyramid approach is very archaic.

As a typical hierarchy representation, it is quite common and easy for people to understand, in my opinion. That the pyramid representation is old isn't significant. In most companies a person can walk in and will find that the company's documentation is well represented by the pyramid.

But please - Seriously - Do explain how it is 'archaic' and it's negative aspects. And, what is a better way to show in a simple graphic the relationship of documents in a company.