7.5.6 Validation of processes for production and service provision

Hi all,

We are a small company that produces software for medical devices. We are a supplier for a company that is certified ISO 13485 and we are following the client's processes and procedures. We have also our procedures and we are certified ISO 9001. We want to get certified ISO 13485. I am not sure if the clause 7.5.6 Validation of processes for production and service provision is applicable to us, especially regarding the procedures for validation of the application of computer software used in production and service provision. We are not involved in the medical devices production or storage and we use the same tools for projects as our clients. On the other hand, all the code sources and projects documentation are stored in the client's repositories. Thank you.

 

Without intending to speak for the OP, there are good reasons a software shop supplying software development services to a medical device manufacturer should have an ISO 13485 cert. The (13485) auditors are considering outsourced software development shops to be critical suppliers and certification to 13485 would be intended to preclude having the manufacturer's auditors have to audit the software shop. My company provides software development services for medical devices and that's precisely the reason we got certified.

To the point of the questions, it's likely you are doing "production" although it may not feel like it. If you build the software and provide binaries, you've effectively provided a finished component. In that respect, there is software that you use in the production: compiler / linker / IDE.

Now whether validating that software is a worthy exercise is a different story. I would argue that validating an IDE does not provide value and the testing you do on the binaries is better confirmation that the software (IDE) performed its intended role.

If you do take the journey towards 13485 certification, you should likely see other applications that should be considered for validation. Static analysis tools, issue tracking tools, etc. That's not to say that validation is added value on these, necessarily. I'm just suggesting that it would be a good idea to start an inventory of applications used throughout your processes (management as well as software development) and establish a risk-based approach to (non-product) software validation. The FDA (draft) guidance on computer software assurance, I think, is an effective and efficient approach.