ISO 13485 Software Validation Requirements - Help needed

Hello! I need serious help on understanding what we need to do to meet the 13485 req't for SW Validation. We are good on automated spreadsheets & elec. test SW, however our ERP system which is about 20 yrs. old, was OTS but has been customized - eep!! We have been told anything from do a PFMEA & show on a risk-basis why you're not doing a validation for the ERP & how we've mitigated identified risks, validate the SSs & test SW to holy cow - it's a project that will take months of a full-time person. We are really stuck. Any help is really appreciated. Again, our goal here is solely to pass the REG audit. THANKS!!

rdesmond said:

eep!!

Click to expand...

To steal a line from the Hitchhiker's Guide: Don't Panic!

Here's what I would suggest you do.

Step 1: Admit you have a problem. I would write this up as a Corrective Action.

Step 2: Analyze the situation. You need to establish some basis for either doing a validation or not (risk based). This shouldn't be an ad-hoc approach. I would recommend a Validation Master Plan that describes how you assess risk / validation needs. You should also do an inventory of software used and determine (as part of the CA) if anything else should be addressed.

Step 3: Plan. Presuming your assessment leads you down the validation path, you'll need something to validate against. You don't (necessarily) need to validate the entire system. Document your "How We Use" requirements and use that as the basis for validation. (Bear in mind that validation is more than just verifying your requirements are met - you need to also show control of the software). Obviously all your customizations need to be tested.

Step 4: Reflect. Since you have a (long) history of using this, you're effectively doing a retrospective validation. Assess all the data gathered / managed to date and determine if there is any chance that there could be quality issues based on your validation results. For example, if you find a bug in the software during the testing, you'd need to determine if that could have led you to make erroneous decisions.

Step 5: Maintain. As noted above, validation is more than just testing. You need all the controls in place to ensure the software remains in a validated state after changes (which could be to the underlying software libraries, the OS, etc.).

If you're in a state of emergency, I would probably recommend you bring in some outside expertise to guide you through the process. If the audit is impending, you'll likely get a hit but if you already show you're taking action to correct the situation (and have a good handle on a systemic correction), it might soften the blow.

I am not sure if there is much to do for the sake of the iso13485 as regard to sw validation unless your core business relates to sw development activities...
I believe iso13485 requires sw validation only for sw used as part of production and service provisioninig, that's more or less all (could be some stuff for calibration if any ... )
So ... let's have a read of the standard first before planning anything.
Cheers!

sagai said:

So ... let's have a read of the standard first before planning anything.

Click to expand...

That line can get a bit fuzzy but that's why I suggested doing the master plan and establishing (with rationale) what's in and what's out.

Generally (my experience has been that), ERP systems are contributing to the (record keeping for) production and service provisioning activities. Defining the "here's how we use the system" is needed to establish that linkage.

That is okay Yodon, the only point is that people and companies are tend to fall into almost religious beliefs over the strictly regulatory matters without actually having a read an the understanding of it.

So, let's see what we've got here ...

BS_EN_ISO13485:2012
7.5.2 Validation of processes for production and service provision
7.5.2.1 General requirements
... The organization shall establish documented procedures for the validation of the application of computer software (and changes to such software and/or its application) for production and service provision that affect the ability of the product to conform to specified requirements. Such software applications shall be validated prior to initial use. Records of validation shall be maintained (see 4.2.4)
...
7.6 Control of monitoring and measuring devices
... When used in the monitoring and measurement of specified requirements, the ability of computer software to satisfy the intended application shall be confirmed. This shall be undertaken prior to initial use and reconfirmed as necessary.
...

Click to expand...

When I have a read of it, I see only two really limited cases when this software validation is needed:
1., If there is a software that could affect the ability of the product to conform to requirement in the only context of production and service provision.
2., If there is a software that used for monitoring and measuring purposes.

That's all.

Coming back to the original post. I think the important bit first to think what are the softwares if any that may fall into these categories, have a consensus over the list of such softwares that they are really fall into these categories and than consider the extent of the rigmarole.

My side note is that even a part of the ERP system functionality could in a really-really rare case fall into any of these categories.

Cheers!