"As appropriate" in ISO 13485:2016

[Marcelo]

For distributor who involves only storage and distribution, I think it is obviously not appropriate the following, unless otherwise required,
"e) implementation of defined operations for labelling and packaging;".

Even this case, is it required to document a justification?

As I mentioned, although the "document" was removed due to other reasons, the expectation was to have any justification documented. So yes.

The problem with the "obvious" stuff in an audit is that it's impossible to verify oif the something was not done because it was obvious or simply forgotten.

 

[TWA - not the airline]

As I mentioned, although the "document" was removed due to other reasons, the expectation was to have any justification documented. So yes.

The problem with the "obvious" stuff in an audit is that it's impossible to verify oif the something was not done because it was obvious or simply forgotten.

Marcelo, though I can understand this, I must say that from the perspective of an auditee it is really annoying to have to comply with "expectations" that have not been adequately put in writing.

 

[Marcelo]

Marcelo, though I can understand this, I must say that from the perspective of an auditee it is really annoying to have to comply with "expectations" that have not been adequately put in writing.

I understand your comment but , although I'm usually ok with the "Show me the shall" mentality, I don't think it should substitute good sense.

This is even truer in the case of ISO 13485:2016 which, due to several reasons, have SEVERAL inconsistencies - 29 the last time I counted - I 'm creating a table of those and may share it in the future.

But let's see one illustrative example - 4.2.3 says - "Medical device file - For..., the organization shall establish and maintain one or more files either containing or referencing documents generated to demonstrate conformity to the requirement of this International Standard and compliance with applicable regulatory requirements."

If you read only the requirement, what is one interpretation? "Documents generated to demonstrate conformity to the requirement of this International Standard and compliance with applicable regulatory requirements" seems to imply a kind of checklist that shows how each clause of the standard (and regulatory requirements) was implemented in which document (clause xx - document yy, clause aa - document bb).

However, fortunately in this case, the rest of the clause still shows the original expectation - this clause is the clause that was created for the DMR (we did create another similar clause in 7.3.10 for the DHF).

So, if you only look at the requirement of 4.2.3 as written, it's requiring, besides what is mentioned in the content, more stuff that does not make much sense. If you are using good sense, you would only have a DMR doe this. If not, you would have the DMR and compliance checklists. I would suggest to only have the DMR and argue about this inconsistency, if asked.

On the other hand, as I mentioned on my previous comment, even if the standard does not clearly state anymore that the justification in the case of not appropriate should be written, if you are asked during an audit, it would be impossible for the evaluator to conclude if the "obvious" stuff was really considered or only forgotten, if you don't write a justification. Please note that, for other similar cases (exclusions and non-applicabilities), the requirements for documented justifications are still there (in 4.2.2 a)), so again, I would suggest it makes sense to document the justification for the not appropriate requirements, even if the standards does not explicitly mentions so anymore (due to the inconsistency I mentioned).

 

[TWA - not the airline]

Marcelo, I am all for good sense and I agree that it is good business sense to have a system that documents what you did in such a way that you can easily retrieve the information w/o having to rely on your memory (see also one of my earlier replies to the OP regarding resources).
However in the regulated industries there is a big difference between explicit "must have" requirements and everything else. E.g. if I must document a justification then this means I have to do it in each and any instant and if I forgot it in just one case then I have a deviation even if I can argue that for this specific case it was obvious. With "as appropriate" single incidents of missing written documentation can be explained when the decision was "obvious" and such a situation would therefore not be non-conforming. Of course I cannot work without having a process that defines how to document, but an auditor would at least have to find multiple instances of missing documentation that need to be explained in order to have a finding. I am looking at this a little bit like with some requirements in the CFR where an approval with date and signature is needed for some docs like the design input: you have documented all the relevant/necessary information but still are not compliant when the formal requirements are missing. Of course I cannot develop a product w/o documented design input, but if the requirement was to document the design input "as appropriate" maybe I could just file the paper napkin where the doc scribbled the "must haves" of a new product...

 

[Marcelo]

With "as appropriate" single incidents of missing written documentation can be explained when the decision was "obvious" and such a situation would therefore not be non-conforming.

Not in the 2003 version of the standard.

I was just trying to point out that the change was due to a specific problem with the use of the "document" statement of the new version, not because it was deemed not necessary to document every justification. So, even the OP being correct in saying that the current version does not formally require documenting justifications for non appropriate, it does not mean that he should not do it. But obviously he (or anyone) can simply decide not to document because it's obvious.

Even then, I would suggest at least to think about how this "obvious" thing would be explained when someone asks how it obvious that the requirement is not required to:

- product to meet requirements;
- compliance with applicable regulatory requirements;
- the organization to carry out corrective action;
- the organization to manage risks.

Which are the other "requirements" for being or not appropriate as defined in 0.2

 

[TWA - not the airline]

Not in the 2003 version of the standard.

True, and therefore I would just stay with my old documentation system in that regard as this should already be compliant and "doing nothing" is a no brainer. But I might now start to argue in an audit when single instances of undocumented "obvious" would be declared to be a deviation.

 

[Marcelo]

True, and therefore I would just stay with my old documentation system in that regard as this should already be compliant and "doing nothing" is a no brainer. But I might now start to argue in an audit when single instances of undocumented "obvious" would be declared to be a deviation.

Sure, but is it better than to simply write a statement of why it's not appropriate?

I understand the comment of balance of resources, but I would be more worried about risks. You may find that, depending on who your arguing with, your arguments might not work, even if true.

And I still point to the fact that if you follow 0.2, all requirements are appropriate if they are needed to meet requirements, or compliance with regs, or corrective action, or to manage risks. I think it would be very difficult to justify that anything is "obvious"related to those.

 

[TWA - not the airline]

Marcelo, as I already posted I also find it easier to just write it down and be done. And I would never set up a system that tells people it is oK to not write it down; that is why I stated I would not change a compliant system in that regard, even if a regulation might now be more lenient.
However, people are people after all, and therefore in real life even in your best processes sometimes mistakes happen (and auditors somehow have this unfailing intuition and always pick this one occurrence in 10000 where there is a problem). That is why it is important for me to know what exactly the regulation requires but also what not. As an auditee I cannot bring forward the argument of the "spirit" of the regulation, so why should a standard? I agree that I may not (always) win an argument even if I was right (and I actually indeed recall some instances where this was just the case), but it is somehow part of what makes me a professional (pain in the ass ;-)) in the medical device field that I not only focus on the product but also know the regulations on a level where sometimes I can actually "throw the gauntlet" and ask "show me the shall".

 

[Marcelo]

(and auditors somehow have this unfailing intuition and always pick this one occurrence in 10000 where there is a problem).

My opinion is that the problem is not you forgetting to do 1 occurrence in 10000, but the auditor calling this a deviation. This is bad auditing (and I know we have a lot of bad auditors out there). Unfortunately, most auditors and organizations are too focused on finding this one occurrence to put in their reports and says that they work is being done, instead of focusing in the right and important stuff.

 

[Marcelo]

But as I also said before, yeah, I understand what you mean.