Specific Software verification / validation requirements written in a standard?

[Pzimmermann92]

Hello.

I am trying to figure out the best way to follow our flowchart (QMS) in the quality procedure “validation of software applications”.

We have recently implemented software as part of a manufacturing process, which simplifies the search for the results of testreports of our tested PCBA’s. These results are checked by the operator to ensure a report was automatically stored by the test program (resulting from a corrective action due to incidentally missing reports). The search for the results is done via an SQL database visualisation program (custom written by an IT company within a microsoft based program for our need).

Unfortunately the QP was set-up by an employee who does not work here anymore, the references to wherefrom he has set up the flowchart are unclear, thus for me it is hard to understand why the flowchart was made the way it was made.

The problem: According to ISO13485 there should be a risk based approach for software validation. However i do nowhere find any specific requirements (also not in other standards such as 62304).

Now the software must be validated/verified. According to the flowchart, there is no need for validation, only verification (and also to be listed in the software application list with reference to the verification report).

But here comes the problem:

The last flow-chart step before the block which says: “Very limited risk involved, only verification of requirements or purchasing specifications apply” states: “Is output of the software independently verified 100%?”

In no standard, or otherwise on the internet i find a such a descriptive requirement. So i am looking for how to understand/interpret this question (Maybe we are missing a standard / TR / other document?)..

I hope someone understands my question and can help me further.

Thank you in advance!

Best regards, Patrick.

 

[yodon]

62304 is for medical device software so it's not in play here (and it even punts on the idea of software validation).

A good source (IMO) is FDA's guidance on computer software assurance. It provides a bit more on a risk based approach.

Historically, many companies used GAMP5 for non-product software validation. This (again IMO) isn't ideal for software applications but was at least providing a framework.

 

[Tidge]

But here comes the problem:

The last flow-chart step before the block which says: “Very limited risk involved, only verification of requirements or purchasing specifications apply” states: “Is output of the software independently verified 100%?”

In no standard, or otherwise on the internet i find a such a descriptive requirement. So i am looking for how to understand/interpret this question (Maybe we are missing a standard / TR / other document?)..

100% verification of a software output means that every time the software does something, a human also does the thing the software does, and records the results of their check. No one does this, which is why there is some assurance (through testing of established requirements) that the software is working appropriately, often through validating the software.

 

[DanMann]

There's also IEC/TR 80002-2 "Validation of Software for Medical Device Quality Systems", but it isn't harmonised to the EU or UK, so it doesn't have any official recognition, you have to buy it and I prefer the FDA guidance anyway.

 

[NaveenRKO18]

Can anyone provide a sample template for software validation as per iso/tr 80002-2?

 

[Tidge]

Can anyone provide a sample template for software validation as per iso/tr 80002-2?

You probably ought to start a new thread with more specific questions.... including the specific QMS area the software will be used in. This thread started with a post about non-product software that backed into a (likely misguided) question about 13485 application to NPS.

I don't have direct familiarity with 80002-2, but based on my reading of 80002-1 (aplying concepts of 14971 risk management to medical device software) I wouldn't expect it to be particularly groundbreaking. I would hope that whatever the contents of 80002-2, that they would be somewhat more "critical-thinking"-focused than GAMP 5's "decision matrix" approach to determining necessary deliverables.

I don't want to leave the impression that I disrespect either AAMI or ISPE. I find the AAMI TR resources to be presented in a straightforward way that can reinforce the requirements of standards, yet mileage varies (for me at least, someone who isn't an expert in everything) on what level of new knowledge comes from any given TR. GAMP 5 is IMO ultimately a somewhat complicated, rigorous (or at least "detailed"), specific approach to NPS that is not particularly well-suited (again, my opinion) for most of the areas of 13485. GAMP 5 certainly could be applied, but that would end up being a lot of overhead that would end up confusing folks.