Defining a good Scope for Critical SOPs

[moritz]

Hello everybody!

I have been reading the cove since I got involved into the development of our QMS and could already take tons of wisdom and information from it - thanks for that!
Today, I want to ask my "first" own question, since I couldn't find anything addressing that topic in the search.

Background: We are a product development service provider and want to strategically deepen our involvement with the medical devices sector. Our only "products" in that area are services. We have participated in the development of several medical products but it was never required of us to get certified. A couple of months ago, we decided to build our own medical lab for testing (development/evaluation but soon also verification). We plan to get certified for EN 13485 for testing only at first - but want to be prepared for a later extension of the certification to our product development activities.
​

Now, finally, the question in case:
I was reading through our Deviation handling SOP and read the following scope: "All deviations from GxP processes contributing to verification tests within [our company] must be reported and handled conforming to this procedure"

I dislike the explicit naming of verification tests. We want to be able to test flexibly during early development stages so that the SOP should not be applicable in those cases. On the other hand, there will be other very relevant activities that should be covered by the SOP, namely anything contributing to design history files and the like. So I was wondering if there is a widely known expression for the scope that conveys exactly that, something along the lines of "This SOP applies to all processes that contribute to an audit trail."

But that would then need a lot of interpretation by the readers and could lead to non-understandings, right?


Anyways: That's the moment when I ask around if anybody around here can help me out and shed some light . I have seen that it can work wonders.

 

[Ronen E]

Hello and welcome to posting

I would go the other way around: I would state that the procedure applies to everything except X, Y and Z.

"early development stages" = you could call it "feasibility studies" or similar, state that it relates to anything and everything that predates the issue of a design plan, a project formal kick-off (meeting?) or whatever applies to your practice.

IMO getting certified to ISO 13485 with a scope of providing D&D services to manufacturers is a bit weird, but everyone seems to ignore the original intended scope of 13485 and soon enough even the standard itself is going to change in that regard, so I'll let it go. Still, if you want to get certified for providing test services perhaps ISO 17025 is a more appropriate standard.

Cheers,
Ronen.

 

[moritz]

Hey Ronen!

Wow, that was a fast reply, thanks
And I love your suggestion of excluding areas from scope instead of including. That also makes the SOP safer against small things slipping through the scope. Will certainly try to implement that!

About the certification - yes it feels indeed weird to apply the 13485 on testing and development since it was clearly written for manufacturers (even though the foreword has the wonderful "product=service"-catchall-phrase).
And sure, for a professional test lab ISO 17025 could be better. But our customers know us from development work and the testing we do is very close to development or rather a byproduct, so they suggested 13485 to us with the long term in mind. I guess they just want to see that we are capable of thinking in quality and risk terms.

Cheers, Moritz

 

[moritz]

The current wording is planned as follows:

All deviations from documented procedures and all nonconformities within [our company] must be reported and handled conforming to this procedure.
Notable exceptions:

• [FONT=&quot][/FONT]Deviations from test protocols that will not be part of a design history file are excluded from this procedure
• [FONT=&quot][/FONT]Test samples that fail acceptance criteria are tracked according to [tracking and traceability SOP] and reported according to [test realization SOP]

Think that could work well enough? :

 

[David Baker]

Are the deviations from documented procedures subject to management review (in some capacity)? Do test failures influence the occurrence rankings of the failure mode effects analysis (FMEA)?

 

[Ronen E]

Deviations from test protocols that will not be part of a design history file are excluded from this procedure

Is it clear enough in real time to everyone involved whether a test protocol will or will not be part of a DHF?

 

[moritz]

Thanks for the good challenging questions, they make me see the interconnections much better! And you guys are answering really fast

@David Baker(1): "[Quality] will track and trend deviations. Trending or delayed deviations shall be discussed at the regular Management Review meeting."

@David Baker(2): We are just about to write our Risk Mgmt SOP for the first time, so no idea Generally speaking, if a product fails our tests, we just inform our customer and they will (probably) adjust their FMEAs. Our own FMEA would just need to be adapted if we discovered our test procedures to be risky. That's the weird part of being a test lab only - our own product is just the service we provide, not the actual product we test.

@Ronen E: (form Test realization SOP) "Test orders received from customers should state clearly if verification (for DHF) or evaluation (not for DHF) is required. If the order is not explicitly categorized as evaluation or verification, the [project leader] shall initiate clarification with the customer in cooperation with [quality/team manager] and record results of this clarification in appropriate written form. The [project leader] is responsible to inform all Test engineers about whether they perform evaluation or verification tests."

Any more thoughts we might have forgotten?

 

[Ronen E]

Hi,

"[Quality] will track and trend deviations. Trending or delayed deviations shall be discussed at the regular Management Review meeting."

IMO Management Review is not the most appropriate forum to discuss individual deviations (it is for trends). Normally product-related NCs are discussed at MRBs (Material Review Board), so you should be having something similar (maybe termed differently).

:"Test orders received from customers should state clearly if verification (for DHF) or evaluation (not for DHF) is required. If the order is not explicitly categorized as evaluation or verification, the [project leader] shall initiate clarification with the customer in cooperation with [quality/team manager] and record results of this clarification in appropriate written form. The [project leader] is responsible to inform all Test engineers about whether they perform evaluation or verification tests."

This sounds just like part of Contract Review - I recommend that this provision is included in the Contract Review SOP, and the results are documented as part of the Contract Review documentation. The result (evaluation/verification) should also be captured in the finalized order document, and that should be the test engineers reference. The process should rely as little as possible on loose / verbal instructions that "someone" is responsible for remembering to follow.

Cheers,
Ronen.