Customer Related Processes and Requirements - ISO 13485 Clauses 7.2.1 and 7.2.2

[yodon]

I could use some help understanding sections 7.2.1 (Determination of Requirements Related to the Product) and 7.2.2 (Review of Requirements Related to the Product). I tried several searches but came up empty.

My question is how do folks handle these sections in their Quality Systems? We are a small contract R&D company and generally get, at best, some high-level requirements (e.g., "we want a widget") when discussing new contracts. We perform enough due diligence to give a rough order of magnitude estimate. We generally elaborate a little (e.g., "the widget will have a graphical user interface and will meet UL EMI standards") but still keep things at a high level. As a contract shop, we can't invest too much in pre-award time.

Is this high-level 'review' sufficient to meet the standard (from 7.2.2 "...review the requirements... prior to commitment to supply a product...")? After contract award, we generally create a more traditional Requirements Specification in line with Design Inputs (7.3.2). Any feedback appreciated.

 

[qualitygoddess - 2010]

Re: Customer-related processes - Requirements

You have asked my second favorite question about compliance to ISO requirements. I think you have to be careful with how you define compliance with the statement in the standard: ... review requirements related to the product. This review shall be conducted prior to (your) the commitment to supply a product to the customer .... As an R&D lab, you often take the customer's initial inputs and create something for them to try. As you go along, requirements can get added and subtracted. The product gets fine-tuned. The product gets tested. The product gets validated. The processes to create it get validated. Eventually, the end product is done and then highly specified, so it can be done again.

If you define the commitment to supply the product as the outcome of the R&D process itself, then your company, in theory, can accept any request for any widget. The contract becomes the use of the R&D process to create what the customer wants. You must absolutely commit to excellent record keeping for the duration of the project -- in all aspects. Initial product needs, testing plans, validation plans, changes, approvals. You may benfit from a stage gate R&D process. That will create the tool needed to have a culture within the organization of excellent record keeping. Development cannot proceed until the 'gate' can be opened to the next stage of R&D.

I hope this makes sense. I've seen it work at a software development company this way. There, the customer says something like "I want the software to help my engineers be more productive.". The software development process is followed, and the result becomes a highly specified product that is developed with the customer involved at every stage. When done, the software program is made available, and that's the product.

 

[yodon]

Re: Customer-related processes - Requirements

Thanks for the response. Let me be sure I follow by echoing what I think you're suggesting.

Indicate up front that the process is iterative. We perform due diligence on the whatever initial high-level requirements are available and the contract becomes our initial record of compliance to this clause. As we move through the life of the project, we refine the requirements. We review these and maintain good records of these reviews. These efforts also show compliance (some cross-over here with desing inputs / reviews, I suppose). Is this in the ballpark?

Ok, I have to ask, what is your first favorite question about compliance to ISO requirements?

 

[qualitygoddess - 2010]

Re: Customer-related processes - Requirements

Ok, I have to ask, what is your first favorite question about compliance to ISO requirements?

Sorry, Yodon, for the delay in my response. Days and weeks just seem to fly by! My first favorite question is: What will I get for this ISO 9001 thing? Isn't it just a bunch of paperwork? I often hear that from company presidents of small companies.

--QG

 

[qualitygoddess - 2010]

Re: Customer-related processes - Requirements

Thanks for the response. Let me be sure I follow by echoing what I think you're suggesting.

Indicate up front that the process is iterative. We perform due diligence on the whatever initial high-level requirements are available and the contract becomes our initial record of compliance to this clause. As we move through the life of the project, we refine the requirements. We review these and maintain good records of these reviews. These efforts also show compliance (some cross-over here with desing inputs / reviews, I suppose). Is this in the ballpark?

Yes -- I think iterative is a good term. Be sure you have a good system to track changes from the customer as the product demands change over time.

 

[orangeisenergy]

My company is a "buy it out of our catalog" type of company - for the most part. What sort of activities fulfills 7.2.2 in this situation? Is the Production Manager reviewing the SO and verifying product is in stock or estimating lead times appropriately enough? And is the SO enough documentation ("Records of the results of the review and actions arising from the review shall be maintained")?

 

[somashekar]

The NOTE within 7.2.2 of the ISO 13485 answers you ~~~~~

 

[Avraham Harris]

I have been confused with understanding the relationship between 7.2.1 and 7.2.2, on the one hand, and the defining of customer requirements that normally (?- at least by us) takes place as an early design input, on the other.

In different terms - I was unsure whether 7.2.1/7.2.2 is all about contract review, or is it about requirement management (defining, verification, traceability)?

I found the answer within the following post's attachment: Comparison of ISO 13485, FDA and JGMP
Which states:
The closest the QSR gets to determine customer requirements related to the product in 820.30(c) design inputs. The customer requirements referred to in clause 7.2 of ISO/DIS 13485:2003 and article 27 of the JGMP refer to those requirements associated with getting the product to the customer. This includes items associated with order handling and what were referred to in early versions of ISO 9001 as contract review. These are not focuses of the QS Reg.

 

[sandra2014]

Hello,
I have a question related to 13485:2016 clause 7.2.1 d) any user training needed to ensure specified performance and safe use of the medical device. We are a contract mfg company, and are transitioning from 13485:2003 to 13485:2016. This is a new requirement, and I wanted to know if someone can help in clarifying this req. Can we as a contract mfg co. take an exclusion from this clause. (the product design is our client's responsibility) so shouldn'
t they be the ones to determine any user training to ensure the specified performance and safe use of the medical device? Any help/advice would be greatly appreciated!

 

[somashekar]

Hello,
I have a question related to 13485:2016 clause 7.2.1 d) any user training needed to ensure specified performance and safe use of the medical device. We are a contract mfg company, and are transitioning from 13485:2003 to 13485:2016. This is a new requirement, and I wanted to know if someone can help in clarifying this req. Can we as a contract mfg co. take an exclusion from this clause. (the product design is our client's responsibility) so shouldn'
t they be the ones to determine any user training to ensure the specified performance and safe use of the medical device? Any help/advice would be greatly appreciated!

Hi.
The 7.2.1 applies to you to the extent. About the (d) you are right.
Just address what applies as the clause in whole cannot be excluded.
When you maintain records, you are good to state your reason for not addressing the (d)