Evaluation of software life span - ISO 13485

Hi all!

We had a mock audit, in preparation of the ISO 13485 audit coming REALLY soon. One of the comment regards the life-span determined for our product: a software. Basically, the comment was that we need to backup our statement. But How? I would have an idea of how to do this for hardware, but software? And we sure don't want to state that software is good for as long as the associated hardware works...

Any idea???
Thanks!

softn:ware evaluation:

1. Software is written by humans:

2. Software requires a trail and breakin period:

3. Sofware requires that is will meet socks requirements in the
connecting programs.

4. Benchmark test

5. What is the Overlap of the software.

6.Questions, Reliability, personal, functional, baised, safety, security, etc.

world quality said:

softn:ware evaluation:

1. Software is written by humans:

2. Software requires a trail and breakin period:

3. Sofware requires that is will meet socks requirements in the
connecting programs.

4. Benchmark test

5. What is the Overlap of the software.

6.Questions, Reliability, personal, functional, baised, safety, security, etc.

Click to expand...

We did some benchmark, did full functional testing, ran risk analysis etc... In our mind, we would say something like 2 years for the lifetime expectency of the software, based on the fact that the product is new, that "frequent" updates might appear... but is such an affirmation sufficiently backed-up?

Thanks

Have you considered the standard IEC 62304 - Medical Device Software - Software life cycle processes?

Regards,

Jo

I'm confused. Is the product the software or is the software just part of the product?

If software is the product then you can determine the expected life based on perceived need. The bits won't wear out, contrary to what some would believe.

If the software is part of the product then I don't see the need to determine what the software life is - the focus should be on the product life which could be based on mechanical wear and tear, reliability analysis, etc. We've never had any clients that had to determine the software life span outside of the product consideration.

Ok... to make the follow-up, we determined the product life expectancy (product = software) based on the development life-cycle and it seemed to have pleased the auditor. Basically, we based our choice on the fast improvements of the software and limited its installation through software burning process. Auditor appreciated the fact that we considered the life expectancy of the DVD in our considerations (hence, we looked at everything related to our product).
THanks for your help... I sure will know IEC 60304 from now on has this is the norm that "scared us" during the audit...

Thanks again!

consider following thoughts...

given that software=product;
Will it be an acceptable approach to identify an 're-evaluation criteria & frequency' in lieu 'shelf life'?

[for an product which is tested&released to market] assigning shelf life doesn't matter for the following reasons;

1) based on design&testing, the product will perform as long as the prescribed environment[H/w and S/w] is available and
2) anyway it will be validated by client, before being put to use.
3) after implementation, it will be governed by performance-evaluation or routine re-qualification procedures identified and hence the validity of the software is continually updated.
4) over and above the client's-qualification practices, the software manufacturer could additionally take up re-evaluation/re-qualification depending on the attributes upon which the software performance is dependent.
4.1 It could be market releases of versions of OS, Database, memory, ram, OS, etc.,
4.2 it could be range/limits of performance, loads on the software or feedback from client...

thanks
valiveti.