SOP for ISO 13485:2016 Quality related Software validation

SM1990

Registered
Hello,
Can anyone please provide a general SOP for software validation of all quality related software/s.

Also can anyone please inform, what validation/verification tests can be written for web-based ERP-Software Collmex that we are using.

Any help or suggestions would be highly appreciated.
 

sagai

Quite Involved in Discussions
Hi there,
So, there is not much that tells you in the medical domain, how this software tool validation should be done.
Quite embarrassing, I know, 've been there.

Before we would halting the core operations of our company and propose to be busy for the next century with validating software tools, a bit of thinking I would propose.

Why are we doing it?
To what extent we should do it?
How do we would like to do it?
and back to the beginning, what is the benefit of it for our company?

Apart from having answers for all of the above, the kind of key question for this tool validation is to assess that to what extent the unrecognized erroneous behavior of the software tool can lead that this error can propagate as such to compromise patient safety.

Kind of simple like that.
And line up all the measures, testing, all others accordingly.


For ERP, I have a nice bottle of champagne to gamble that you have nothing to do other than list it, set the use case, justify why not sensible to write a single line of a test case, for the sake of ISO13485.

Hope this helps
Saby
 

SM1990

Registered
Hi there,
So, there is not much that tells you in the medical domain, how this software tool validation should be done.
Quite embarrassing, I know, 've been there.

Before we would halting the core operations of our company and propose to be busy for the next century with validating software tools, a bit of thinking I would propose.

Why are we doing it?
To what extent we should do it?
How do we would like to do it?
and back to the beginning, what is the benefit of it for our company?

Apart from having answers for all of the above, the kind of key question for this tool validation is to assess that to what extent the unrecognized erroneous behavior of the software tool can lead that this error can propagate as such to compromise patient safety.

Kind of simple like that.
And line up all the measures, testing, all others accordingly.


For ERP, I have a nice bottle of champagne to gamble that you have nothing to do other than list it, set the use case, justify why not sensible to write a single line of a test case, for the sake of ISO13485.

Hope this helps
Saby

Hi Saby,

thanks for taking out the time to answer my querry.

I am from a research background in Biology and since last few months I am started working in the role of Quality Manager and regulatory affairs in a Medical Device manufacturing company. We are manufacturing a medical device which is classified as class IIa (it is a noninvasive device).

We had an Audit and the auditors pointed out that the ISO 13485:2016 Section 4.1.6 states that any software related to the QMS should be validated before to the prior use.

We are using this ERP-software Collmex (web based) since last 5-7 years. We use it to keep the customer records, to create quotaion, to create order, to create bills, create new products, manage inventory of our medical device and accessories.

So we need to have a general SOP stating how all the QMS related softwares are validated/verified and revalidated in our company.

For the softwares used in our company like erp-software collmex and some other softwares which come with a measuring instrument we are just the end users.

None of these softwares compromises patient safety.

So we are thinking to what extent should we do the validation/verification of the softwares.

What should be the right/systematic/reasonable approach to create a general SOP for this purpose (taking into account all the affected (QMS-related) softwares. And to what extent we should have a testing protocol for these softwares?

Thanks,
S
 

sagai

Quite Involved in Discussions
Hi there,
It was asked so many times and it bugs me so much of seeing the time wasted on it rather than on tasks giving value for us (chasing covid, chasing hunger and all the rest of it), so yes, I volunteer to put together some draft to look into in a week time and share here.
Cheers
Saby
 

mihzago

Trusted Information Resource
One very important thing to keep in mind -> validation is not equivalent to testing. Testing is one of many activities that can support validation. Most people I came across are under impression that when it says to validate the system it automatically means testing is required.
You could possibly validate a software tool without running a single test, but that would depend on what software tool it is, and how you use it.
For example, if it's off-the-shelf and you don't have any custom configurations, then I most likely I wouldn't do any script-based testing.

You still have to document that YOU validated the software. Consider activities such as defining the intended use and user needs, risk assessment, vendor evaluation (leverage any documentation that the vendor provides, for example their validation records), review activities (e.g. demo, inspection, etc.), and finally testing if all previous information does not give you sufficient confidence that the software you're trying to validate works in accordance with your requirements.

Also, remember that you must have a procedure for computer system validation. In that procedure you could describe which activities are required depending on the type, risk and complexity of the software.
 

yodon

Leader
Super Moderator
I will agree with @sagai that too much focus is often on testing. There are other considerations. And before you conclude that the software doesn't compromise patient safety, give it some more thought. An ERP system might help you manage inventory and if the system failed and allowed incorrect product to be used, that could lead to patient harm. If the system manages complaints and a complaint gets lost, there could be a repeat occurrence. Maybe you're right in that it can't lead to patient harm but be sure you give good documented rationale. Oh, and risk to not meeting regulatory requirements should also be considered!

I always recommend a Master Validation Plan to set the stage for a risk-based approach to deciding what validation is needed.

It's never a bad idea, as part of validation, though, to look at a few things:
  • Are controls in place to ensure data integrity? It's not infrequent that I see systems set up giving everyone admin access or there's a single login for multiple people. (This is one reason why you can't purchase a pre-validated system - it has to be validated in your environment as you use it).
  • Are you running it in a supported environment? ERPs have a database back-end which may be separately maintained. Is the database engine compatible with the manufacturer's specifications? This also extends to the hardware the system is running on. If cloud-based probably not a concern but there may be client side considerations as well (even if client side is browser based, are all your users using supported browsers?).
  • Are you using the system in the manner intended?
  • Are there any known issues published by the manufacturer that could impact your use?
  • Is the data being properly backed up and secured?
  • If you market in the US or are pharma in EU, there are electronic record / electronic signature requirements you may need to meet. Is the system meeting those? What about audit trail?
That's just off the top of my head; I'm sure there's other things I'm not thinking of but that gives you an idea.
 

SM1990

Registered
Hi there,
It was asked so many times and it bugs me so much of seeing the time wasted on it rather than on tasks giving value for us (chasing covid, chasing hunger and all the rest of it), so yes, I volunteer to put together some draft to look into in a week time and share here.
Cheers
Saby


Hi Saby,

thank you very much for your helpful initiative.
 

SM1990

Registered
One very important thing to keep in mind -> validation is not equivalent to testing. Testing is one of many activities that can support validation. Most people I came across are under impression that when it says to validate the system it automatically means testing is required.
You could possibly validate a software tool without running a single test, but that would depend on what software tool it is, and how you use it.
For example, if it's off-the-shelf and you don't have any custom configurations, then I most likely I wouldn't do any script-based testing.

You still have to document that YOU validated the software. Consider activities such as defining the intended use and user needs, risk assessment, vendor evaluation (leverage any documentation that the vendor provides, for example their validation records), review activities (e.g. demo, inspection, etc.), and finally testing if all previous information does not give you sufficient confidence that the software you're trying to validate works in accordance with your requirements.

Also, remember that you must have a procedure for computer system validation. In that procedure you could describe which activities are required depending on the type, risk and complexity of the software.


Hi,

thank you very much for the reply.

Some of the things which you have mentioned have definitely made me change the way I was thinking about the software validation process.

Will try to implement your suggestions.
 

SM1990

Registered
I will agree with @sagai that too much focus is often on testing. There are other considerations. And before you conclude that the software doesn't compromise patient safety, give it some more thought. An ERP system might help you manage inventory and if the system failed and allowed incorrect product to be used, that could lead to patient harm. If the system manages complaints and a complaint gets lost, there could be a repeat occurrence. Maybe you're right in that it can't lead to patient harm but be sure you give good documented rationale. Oh, and risk to not meeting regulatory requirements should also be considered!

I always recommend a Master Validation Plan to set the stage for a risk-based approach to deciding what validation is needed.

It's never a bad idea, as part of validation, though, to look at a few things:
  • Are controls in place to ensure data integrity? It's not infrequent that I see systems set up giving everyone admin access or there's a single login for multiple people. (This is one reason why you can't purchase a pre-validated system - it has to be validated in your environment as you use it).
  • Are you running it in a supported environment? ERPs have a database back-end which may be separately maintained. Is the database engine compatible with the manufacturer's specifications? This also extends to the hardware the system is running on. If cloud-based probably not a concern but there may be client side considerations as well (even if client side is browser based, are all your users using supported browsers?).
  • Are you using the system in the manner intended?
  • Are there any known issues published by the manufacturer that could impact your use?
  • Is the data being properly backed up and secured?
  • If you market in the US or are pharma in EU, there are electronic record / electronic signature requirements you may need to meet. Is the system meeting those? What about audit trail?
That's just off the top of my head; I'm sure there's other things I'm not thinking of but that gives you an idea.



Hi,

thank you very much for the reply.

Some of the things which you have mentioned have definitely made me change the way I was thinking about the software validation process.

Will try to implement your inputs while undertaking the software validation tasks.
 

Ronen E

Problem Solver
Moderator
Hi there,
So, there is not much that tells you in the medical domain, how this software tool validation should be done.
Quite embarrassing, I know, 've been there.

Before we would halting the core operations of our company and propose to be busy for the next century with validating software tools, a bit of thinking I would propose.

Why are we doing it?
To what extent we should do it?
How do we would like to do it?
and back to the beginning, what is the benefit of it for our company?

Apart from having answers for all of the above, the kind of key question for this tool validation is to assess that to what extent the unrecognized erroneous behavior of the software tool can lead that this error can propagate as such to compromise patient safety.

Kind of simple like that.
And line up all the measures, testing, all others accordingly.


For ERP, I have a nice bottle of champagne to gamble that you have nothing to do other than list it, set the use case, justify why not sensible to write a single line of a test case, for the sake of ISO13485.

Hope this helps
Saby
One of the best posts I've seen anywhere, on any topic, ever! :applause::agree1::yes::vfunny:

Ronen
 
Top Bottom