Software validation (4.1.6 ISO 13485:2016)

[cam5603]

Hi everyone,

In our company we have an ERP for finance activities and to record some data concerning inventories of our products (stock, lot number, expiration date...). However, all datas are paper based first. We enter these datas only in a second time in the ERP.

Do you think that we have to validate this ERP to comply with the standard ISO 13485:2016 ?

Thank you in advance for your answer !

 

[Marcelo]

Hi everyone,

In our company we have an ERP for finance activities and to record some data concerning inventories of our products (stock, lot number, expiration date...). However, all datas are paper based first. We enter these datas only in a second time in the ERP.

Do you think that we have to validate this ERP to comply with the standard ISO 13485:2016 ?

Thank you in advance for your answer !

You need to validate the use of the ERP, and the use of any software in the QMS.

 

[RichardJ_CH]

Well, I'm not sure it is that black and white.


In my experience the question is: "what is the master?". I ran paper-based systems having electronic shadows for document display. This required me to prove control over the papers, but allowed me not to validate the electronic system.


Regards,
Richard

 

[Marcelo]

Well, I'm not sure it is that black and white.


In my experience the question is: "what is the master?". I ran paper-based systems having electronic shadows for document display. This required me to prove control over the papers, but allowed me not to validate the electronic system.


Regards,
Richard

ISO 13485:2016 was modified to require validation for the application of all software (but using a risk-based approach to both the validation and validation activities). There's no option to question, unfortunately, s the focus was to required validation for ALL application of software.

 

[RichardJ_CH]

Hi Marcelo


With all respect I still feel it is not so black and white.


There are four areas where SW can be used, one among which is in the QMS itself and there, as you state, the "validation of the application of computer software used in the quality management system" has to be performed.


This SW automates a process that needs to be assessed as a part of the risk-based approach and validated based on #4.1.6. However, this process can be plain old-fashioned, manual, without any SW. Then, of course, there is no SW validation.


The point I was making is to have an old-fashioned paper-based process as the master and provide copies (clearly labeled as such) electronically. Then, there is no need for validation of this SW as long as you can argue that it isn't a part of your QMS (such as a printer).


At least this way I have succeeded in the past years. But, as you point out, maybe it is better to just make a list of all QMS SW and validate it.


Best regards,
Richard

 

[Marcelo]

The point I was making is to have an old-fashioned paper-based process as the master and provide copies (clearly labeled as such) electronically. Then, there is no need for validation of this SW as long as you can argue that it isn't a part of your QMS (such as a printer).

Not sure I understand your example. You write things in the computer, then print them and use only the printed ones? Or also use the electronic ones?

Anyway, this is a document management system, and it has to comply not only with the documentation requirements, but now also with the software validation requirements.

At least this way I have succeeded in the past years. But, as you point out, maybe it is better to just make a list of all QMS SW and validate it.

What do you mean by "succeeded"?

Anyway, prior versions of ISO 13485 did not require validation of application of QMS software, only application of software in production and monitoring, so your example was not required to be validated before. Now it is.

But you are right that all application of software would not require validation. For example, software used in financial planning which has no direct relationship with the the device. However, these softwares should be clear identified as out of the scope of the system, and most of the time they are not.

 

[Rincewind]

I just want to add that I kind of agree with RichardJ_CH.

Two weeks ago, I visited a company that just had its ISO 13485:2016 audit. Their argument with the certification body was that, although they use software for the purchasing process and logistics, they print out all of their documentation to ensure traceability and therefore work paper-based and do not view the software as part of the QMS and do not validate it.

This was accepted by the certification body. I have to say I was surprised myself, i did not think this was possible.

 

[Marcelo]

Two generic comments here:

1) Passing an audit does not mean that you comply with the requirements. Due to several reasons (such audits are performed by sampling, and unfortunately a lot auditors do not really know the requirements well), passing an audit only means that you may have satisfied one particular auditor. This does not mean that the next audit (if, for example, another auditor comes) will also pass. Anyway, it's the responsibility of the organization to be compliant, not of the auditor.

For example, we are doing a project in Brazil in which we are evaluating compliance of some manufacturers, and they all are certified to ISO 13485, have CE mark, etc (some have been even had an certification audit the week before our visit). They still fail more than 90 % of the requirements (and most are taken directly from standards and regulations), but we are asking them in a way most auditors do not ask (we created something I called "International Good Regulatory Practices"to use as a basis).

This is also one of the reasons I started this thread: Some possible misunderstandings on the application of ISO 13485

2) I usually do not make suggestions here to pass the audit, I make suggestions to do what I think is right (and thus you can pass all the audits).

With this in mind:

Two weeks ago, I visited a company that just had its ISO 13485:2016 audit. Their argument with the certification body was that, although they use software for the purchasing process and logistics, they print out all of their documentation to ensure traceability and therefore work paper-based and do not view the software as part of the QMS and do not validate it.

This was accepted by the certification body. I have to say I was surprised myself, i did not think this was possible.

I just want to add that I kind of agree with RichardJ_CH.

Two weeks ago, I visited a company that just had its ISO 13485:2016 audit. Their argument with the certification body was that, although they use software for the purchasing process and logistics, they print out all of their documentation to ensure traceability and therefore work paper-based and do not view the software as part of the QMS and do not validate it.

This was accepted by the certification body. I have to say I was surprised myself, i did not think this was possible.

Oh, I've seen several instances of things like that being accepted, but as I mentioned above, that does not mean that they really comply with the requirement.

In particular, if the company writes the document in the computer, they will have to guarantee that the requirements for documentation are fulfilled, even if in the end they only use the printed ones, because they do have a software document management system. So, I don't think the situation you mention is acceptable, even if the certification auditor did accept that. The problem as I see it is, this auditor accepted that today, he (or another auditor) may not accept that tomorrow.

 

[DEVigil]

<snip>

In particular, if the company writes the document in the computer, they will have to guarantee that the requirements for documentation are fulfilled, even if in the end they only use the printed ones, because they do have a software document management system. So, I don't think the situation you mention is acceptable, even if the certification auditor did accept that. The problem as I see it is, this auditor accepted that today, he (or another auditor) may not accept that tomorrow.

It seems that you are arguing that no one can have a paper-based QMS that conforms to requirements. I disagree. I do have one (not that I *want* one - I would *much* rather have an EDMS to use).



In my paper-based system, all QMS documents and records are printed hard-copy that is stored in files and/or binders. I should not need to validate the software on which I wrote the documents (a very common word-processing program) any more than I would have had to validate the typewriter or pen I would have used previously instead of a computer. The software in no way *manages* the documentation system - I do that with master document books, logs, and forms (all on paper). I do have electronic back up of all files, but they are *only* the back ups. The system of record is paper.



Just like it was done before there *were* computers or software.

 

[Marcelo]

It seems that you are arguing that no one can have a paper-based QMS that conforms to requirements.

I did not say that, as this is not the focus of the discussion. The focus in on the software, and I just mentioned that if you use software to write your documents and then print it, you have a software document management system that has to comply with both documentation requirements and software validation requirements.

I'm not sure where you read that this means a paper-based QMS cannot comply with the standard.

In my paper-based system, all QMS documents and records are printed hard-copy that is stored in files and/or binders. I should not need to validate the software on which I wrote the documents (a very common word-processing program) any more than I would have had to validate the typewriter or pen I would have used previously instead of a computer. The software in no way *manages* the documentation system - I do that with master document books, logs, and forms (all on paper). I do have electronic back up of all files, but they are *only* the back ups. The system of record is paper.

The same thing applies to Excel spreadsheets, Both processes information. You need to validate that the processing is ok. If there's a bug in "very common word-processing program", you can print the wrong thing. I'm not sure why people get it with the Excel example (which has known processing errors), but not with work processors (when the use is basically the same).

This is not related to software "managing" anything, it's related to the use of the software inside your process.

Now, I know that a lot of people thinks that you do not need to validate those (even the ISO 13485 handbook says that), but again, this does not mean that it's correct.