SOP for ISO 13485:2016 Quality related Software validation

#1
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.
 
Elsmar Forum Sponsor

sagai

Quite Involved in Discussions
#2
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
 
#3
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
#4
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
#5
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

Staff member
Super Moderator
#6
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.
 
#7
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.
 
#8
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.
 
#9
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
Staff member
Moderator
#10
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
 
Thread starter Similar threads Forum Replies Date
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 4
C SOP Template needed for ISO 13485 6.3 Infrastructure ISO 13485:2016 - Medical Device Quality Management Systems 9
D Sample Calibration SOP for ISO 13485 General Measurement Device and Calibration Topics 4
L Do we need a Labelling SOP for ISO 13485? ISO 13485:2016 - Medical Device Quality Management Systems 5
V Where to add SOP of writing a Technical File in ISO 13485? ISO 13485:2016 - Medical Device Quality Management Systems 1
A Quality Objectives 5.4.1 - KPI SOP - ISO 13485 Audit Observations EU Medical Device Regulations 6
Q Post Market Surveillance SOP - ISO 13485 Audit Nonconformance ISO 13485:2016 - Medical Device Quality Management Systems 3
A Human Resources (ISO 13485 Clause 6.2) example of SOP ISO 13485:2016 - Medical Device Quality Management Systems 1
S Label Translation SOP - MDD or ISO 13485 requirements? ISO 13485:2016 - Medical Device Quality Management Systems 11
T How to verify SOP training effectivness - Section 6.2.2 in ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 7
D Recent changes to ISO 14971 - SOP required for managing standard revisions ISO 13485:2016 - Medical Device Quality Management Systems 1
F Linking an ISO 31000 Risk management SOP to ISO 17025 ISO 17025 related Discussions 2
I Software Design SOP to ISO 62304 (Software life cycle for Medical Device) IEC 62304 - Medical Device Software Life Cycle Processes 3
M Radiation (Gamma or E-beam) Dose Audit SOP - Quarterly dose audits based on ISO 11137 Other Medical Device Related Standards 8
W ISO 10005 Guidelines for Quality Plans - Do we need an SOP? ISO 13485:2016 - Medical Device Quality Management Systems 1
S Incorporating SOP Into ISO 9001 Procedures - 7.5.3 Identification and traceability ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
A COP, MOP, SOP - ISO 9001:2000 requirements? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 19
S SOP Numbering - About to change over from QS9000 to ISO 9001 Document Control Systems, Procedures, Forms and Templates 13
S Converting SOP MDD to MDR Noob ISO 13485:2016 - Medical Device Quality Management Systems 4
K What to include in SOP Definitions section Document Control Systems, Procedures, Forms and Templates 3
D Naming of SOP doc's - Specific to Calibrations ISO 13485:2016 - Medical Device Quality Management Systems 2
E SIP/SOP requirements for USB port used for charging IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
Anonymous16-2 SOP (Standard Operating Procedure) Numbering Document Control Systems, Procedures, Forms and Templates 7
C SOP unification. Revision No, Revision history Document Control Systems, Procedures, Forms and Templates 4
N Agile SOP for SaMD IEC 62304 - Medical Device Software Life Cycle Processes 3
R Is it required to have an SOP for external audits? Medical Device and FDA Regulations and Standards News 7
J Looking for a template SOP for UDI implementation for EU Medical Devices EU Medical Device Regulations 0
B How to apply external voltage to SIP/SOP IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
J Application of mains voltage on SIP/SOP connectors of medical device IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
Q Software SOP - Use and maintenance of an ERP system Software Quality Assurance 6
M What to do in SOP Phase of Head unit testing? IATF 16949 - Automotive Quality Systems Standard 0
H Should I mention machine/Equipment password In SOP? Qualification and Validation (including 21 CFR Part 11) 4
W SOP examples wanted - Soil, Concrete and Asphalt testing ISO 17025 related Discussions 3
pashah Looking for Clinical Evaluation SOP acc. MEDDEV and EU MDR Other Medical Device Related Standards 1
M SOP Sample for BC/ISO22301 (Business Continuity) wanted Business Continuity & Resiliency Planning (BCRP) 4
M Risk/Benefit vs. benefit-risk - Revising an SOP covering Risk Management with the MDR in mind EU Medical Device Regulations 10
A How to manage the QMS system and SOP during the transition from MDD to MDR EU Medical Device Regulations 4
V Protocol, report or SOP for threshold analysis? Human Factors and Ergonomics in Engineering 0
V Nature of references allowed to be cited in the SOP US Food and Drug Administration (FDA) 2
W SOP for Vigilance reporting covering multiple requirements Document Control Systems, Procedures, Forms and Templates 3
M Charging consulting fees for SOP development and guidance Document Control Systems, Procedures, Forms and Templates 13
J Just Venting - Do you refer directly to MDR or you just refer to SOP's? CE Marking (Conformité Européene) / CB Scheme 3
E CSR SHIPPING - Need suggestions for making SOP/WI for our shipping dept (automotive)... Customer and Company Specific Requirements 11
S Should there be a SOP on Cybersecurity? ISO 14971 - Medical Device Risk Management 1
T The difference between SOP and Kaizen Standardization Lean in Manufacturing and Service Industries 2
J Nonconforming product procedures SOP help :) Nonconformance and Corrective Action 2
G NIST SOP 29 - Assignment of Uncertainty - Question General Measurement Device and Calibration Topics 0
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
S SOP Training/Competence in 24/7 Operation contractor company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
K EU MDR - PMS (Post Market Surveillance) SOP - definition of "register(s)" EU Medical Device Regulations 2

Similar threads

Top Bottom