Some possible misunderstandings on the application of ISO 13485

[Marcelo]

Disclaimer: I'm a member of ISO TC 210 Wg 1, which is responsible for the development and maintenance of ISO 1384, but the opinions in my posts are always my own.

For some time I've been toying with the idea of discussing some of what I think are possible misunderstandings that I see in the application of ISO 13485.

I will use this thread to include them as I remember them, and to enable discussions.

Topic 1: ISO 13485 details how things should be done. Difference between requirements and how to fulfill them.

This is a possible misunderstanding of the definition of a requirement and the way standards are written.

A requirement is a "need or expectation that is stated, generally implied or obligatory". This is more related to an objective, an expected result.

If you think in terms of a "what" that defines the intended result, and a "how" that defines a way to achieve the results, requirements would be a "what".

The standard most of the time does not define a "how"to achieve the results.

This means that the way to achieve the result is left to the organization.

On the other hand, there's some implications of the "what"that are not totally clear, and usually missed in the implementation and evaluation of the standard.

For example, there's a requirement that "The organization shall validate any processes for production and service provision where the resulting output cannot be """or is not""" verified by subsequent monitoring or measurement "

(the """or is not""" part is new in the 2016 version).

What are the implications of this requirement to be fulfilled?

- The organization needs to identify those processes that fit the description
- Any process that the organization identify as above shall be validated

How do we fulfill the requirement?

One way to fulfill the requirement is to follow the following steps:

1 - Define a process/procedure review all the organization processes for production and service provision to verify a criteria
2 - Define the criteria as "processes where the resulting output cannot be or is not verified by subsequent monitoring or measurement"
3 - Apply the procedure and criteria
4 - Have a list of identified processes that fit the criteria
5 - Validate these processes
6 - Apply the procedure and criteria anytime a new process is added or a current process is modified.

These steps and activities would in principle fulfill the requirement.

Unfortunately, most of the organizations I know simply identify (not in a systematic way) some processes that they know are usually considered "special" (which is the term usually used for the processes that require validation) such as soldering, sterilization, etc., and validate those, and that's the way they to fulfill the requirement.

 

[Marcelo]

Topic 2: Are regulatory requirements more important than ISO 13485, and if so, how do they apply together?

This is a bit of a philosophical discussion with serious ramifications.

ISO 13485 has been, since the beginning, a standard written "for regulatory purposes". The purpose is to be used to help fulfill regulatory requirements.

One of the curious aspects of this relationship is that, in general, regulatory requirements are mandatory, whereas standards, such as ISO 13485, are voluntary (for more on this, and on the need of regulatory requirements to "recognize" standards, see the GHTF document "Role Of Standard in the Assessment of Medical Devices").

This is made even more clear on the 2016 version, where regulatory requirements takes center stage.

So, how to think and use them together?

Well, one of the ways to think about this is that ISO 13485 is more of a "placeholder" for requirements. If there's specific QMS requirements in the the jurisdiction you are selling your product, those take precedence over ISO 13485 requirements.

For example, in Brazil we have a GMP regulation, which details QMS requirements, RDC 16/13. If you are organization that sells in Brazil, RDC 16/13 is mandatory. If you apply ISO 13485 in this organization (and let's suppose this organization sells only to Brazil) then you would have to mix the requirements of RDC 16/13 with ISO 13485. One way to do that is to use ISO 13485 requirements when there's no specific RDC 16/13 requirements, and where there is, follow RDC 16/13 requirements (complemented to additional requirements from ISO 13485, if any).

(please note that his gets very complicated when having different target markets and thus several applicable regulatory requirements).

Unfortunately, "certification schemes" do not take this into consideration the way it should, usually "forcing"ISO 13485 requirements even if there's applicable, mandatory requirements in each applicable regulatory system.

 

[Marcelo]

Topic 3 : Role (s)undertaken by the organization under the applicable regulatory requirements. Is this the most important clause in the standard?

In the beginning of the standard, in the general requirements for the QMS (4 Quality management system, 4.1 General requirements) there's an inconspicuous new requirement that mentions that the organization shall "document the role(s) undertaken by the organization under the applicable regulatory requirements".

This was created as suggested by the European experts, in particular the ones working for regulatory agencies, because this was going to be a new requirement of the MDR (together with more define roles and responsibilities for economic operators0. The requirement came to be because it was difficult for regulators to understand what what the roles an organization in the EU had (and sometimes they had more than one). Little they know (or perhaps they did ?) that this turned out to be the most important requirement in the standard.

In the past, I used to say that the most important requirement of the standard was te one related to management reviews, because the objective of the review is to verify if your system is effective and is worked as intended, including fulfilling requirements. This is still very important.

However, which requirements should the system fulfill? In older editions, the definition of these requirements was rather basic - requirements from the standard, a general mention of regulatory requirements, and the like. But there was not a clear basis for these.

Now, we got the basis. Although the ISO 13485 requirement says a little different, the fact is that the identification of the applicable regulatory requirements depends on the role the organization undertakes, for each applicable regulatory system (which can be more than one role in more than one system).

For example, in Brazil, organizations can have different roles, most of the related to the AFE (company working allowance, which defines activities the organization is allowed to perform). If the AFE says that the organization can manufacture and distribute devices, then the roles would be Manufacturer and Distributor. These roles would be the bases for identification of applicable regulatory requirements (see in a following post comments on this step of identification).

This is really clear in the Introduction to the standard (0.1 - General) where is that the standard expects that the organization:

- identifies its role(s) under applicable regulatory requirements,
- identifies the regulatory requirements that apply to its activities under these roles,
- and incorporates these applicable regulatory requirements within its quality management system.

 

[Marcelo]

Topic 4 - Which regulatory requirements? And how?

Unfortunately, the requirements to identify applicable regulatory requirement is not in 4.1 together with the requirement to identify the roles. It's in

5.2 Customer focus

Top management shall ensure that customer requirements and applicable regulatory requirements are determined and met.

So, if you link the role requirement from 4.1 with the determination requirement of 5.2, the conclusion is that you have to identify all the applicable regulatory requirements for each role.

This can be a daunting task if you sell to dozens or hundreds of different markets, but this has to be done.

One way to do that is, instead of initially focusing in specific regulatory requirements, to focus on regulations (the documents in which the requirements are defined).

My suggestion is to create a matrix for each country, and to include the number/title/year of each applicable regulation.

One important caveat here is that ISO 13485 restricts the type of regulatory requirements you need to identify and comply with the claim conformity with ISO 13845. In 1.2, it states that:

The application of the term ‘regulatory requirements’ is limited to requirements for the quality management system and the safety or performance of the medical device.

So focus on these.

The matrix would then have all applicable regulations for each country. For example, for Brazil it would include the ones in the annex (in the Annex there's only ANVISA regulations, not INMETRO or any other applicable ones. Also, not all regulations in the annex are applicable to all devices. Also, the compilation is based on an original document from ANVISA).

Obviously, the explicit regulatory requirements would be anything written in any of the applicable documents.

Also, this list would need to be constantly updated, and any new or modified required, included in the QMS.

 

[Roland chung]

Hi Marcelo,

Can we combine QMS software validation with process validation, such as injection molding?

Is the QMS software validation also applicable for the software embedded in equipment for production and measurement?

Thanks,
Roland

 

[Marcelo]

Can we combine QMS software validation with process validation, such as injection molding?

Roland

Hello

Good question.

Yes, in fact, software validation is (although ISO 13485 does not make it very clear) as part of process validation. One way to think of software is that it automate processes (this i in fact the term used in 21 CFR 820), so the software use is always a part of a process.

This is made very clear in ISO TR 80002-2, in which the software validation begins with a process analysis and process risk analysis, and then going in what the software contributes to the process.

Is the QMS software validation also applicable for the software embedded in equipment for production and measurement?

Yes. In fact, we would only need to have the software validation requirement in 4.4, we could have cut out the other 2 instances, but due to some concerns, we kept the 3 instances on where the standard requires software validation (but in my opinion it still confuses more than help).

 

[Roland chung]

Yes. In fact, we would only need to have the software validation requirement in 4.4, we could have cut out the other 2 instances, but due to some concerns, we kept the 3 instances on where the standard requires software validation (but in my opinion it still confuses more than help).

The standard requires the "computer software" to be validated. Some people argue that the computer software should be application software. The embedded software (firmware) should be excluded, such as software embedded in the controller of production facility (e.g. injection molding machine) or in measuring instruments (e.g. Hi-pot tester).

 

[Marcelo]

The standard requires the "computer software" to be validated. Some people argue that the computer software should be application software. The embedded software (firmware) should be excluded, such as software embedded in the controller of production facility (e.g. injection molding machine) or in measuring instruments (e.g. Hi-pot tester).

Yes, I've seen this comment, but this is a historical problem withe the use of the term by ISO 13485, which as no definition of computer software. But this includes things such as programmable logic controllers (PLC) for manufacturing equipment. ISO TR 80002-2 even includes this as a first example of "computer software" that requires validation.

 

[Roland chung]

Yes, the ISO TR 80002-2 also includes an example of ETO sterilizer. So, what is the intent of ISO committee?

 

[Marcelo]

Yes, the ISO TR 80002-2 also includes an example of ETO sterilizer. So, what is the intent of ISO committee?

As I mentioned in the first post, I cannot formally speak for the committee, but it has always be my understanding that the validation clause does include firmware too, and this does not seem to be different from the whole point of the standard.

In fact, when discussing the upgraded requirement, the general idea was that every use of software should be validated, but then the approach to validation (depth and related activities) should be risk-based. There's never been a discussion if it was only "computer"as used in computers or not. Part of the problem may be that it's clear to the group discussing, but not to everyone else. Unfortunately, it's a common problem in standards development.