Software Validation vs. Validation of the Application of Computer Software

Please see below in blue the requirement of validation as in ISO 13485., 7.5.2.1
I want to understand with some examples what this means and is this the same or different from 'Software Validation'. While I am not too clear myself, I am having a tough time explaining this within and deciding if this is an exclusion.
We make patient monitors which has software that we code into the product. We program some chip for use in certain of our other medical devices that we assemble, and we also have fixtures for PCB assembly testing that runs on a software in our shop PC.
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.

Re: Software validation Vs Validation of the application of computer software.

It is the Software that you use to manufacture the product, not software in product you manufacture.

I think that you need to consider this not just under 7.5.2.1 but also under:

• 7.1 Planning of product realization "c) required verification, validation, monitoring, inspection and test activities specific to the product and the
  criteria for product acceptance"
• 7.3.1 Design and development planning "b) the review, verification, validation and design transfer activities (see Note) that are appropriate at each
  design and development stage"
• 7.3.6 Design and development validation "Design and development validation shall be performed in accordance with planned arrangements (see 7.3.1)
  to ensure that the resulting product is capable of meeting the requirements for the specified application or
  intended use"

somashekar said:

We make patient monitors which has software that we code into the product.

Click to expand...

Will the monitor work without the software? The software is a part of the design, and it should be validated as part of that.

somashekar said:

We program some chip for use in certain of our other medical devices that we assemble

Click to expand...

Same as above.

somashekar said:

we also have fixtures for PCB assembly testing that runs on a software in our shop PC

Click to expand...

Inspection systems should be validated just as inspection methods may need to be validated.

I don't know if this helps or not, but in the aero world, software is usually categorized as deliverable and non-deliverable.

Deliverable software is a product of your production process (in some form or another, whether purchased or created) and is subject to all of the same rules and requirements of production. Like process validation, first article, config mgmt, change control, etc.

Non-deliverable software is usually associated with inspection, testing, and validation and, as such, follows the rules of measurement and test equipment control. Like maintaining a list/register with change control and validation to make sure it is performing correctly, maybe some kind of periodic evaluation to make sure it hasn't degraded and is still compatible with the platform(s) it operates on.


Good luck.

When we speak in terms of software validation, there are 2 distinct variations of activities that are at times spoken of interchangeable.

Validation of software in medical devices speaks specifically to ensuring that the software works in its intended environment and that it has been adequately tested to address what risks factors have been assessed during your risk analysis process. This is a very deep level of activity since the code is typically generated in-house.

Validation of manufacturing software (software used to manufacture and test medical devices during the build process) speaks specifically to ensuring that software works for its intended use. A large part of manufacturing software is off-the-shelf and therefore considered a "black box" since you as the buyer did not code the software yourself. In this case, you would perform Process validation: IQ,OQ, and PQ activities to ensure that you are adequately addressing its intended use and that it meets your established requirements.

If you coded your manufacturing software in-house, then you would still do the process validation: IQ, OQ, and PQ activites, but you would start with software requirements up-front, so that your developers are building to a pre-determined set of requirements and testing to those requirements before you conduct your IQ,OQ and PQ activities.

So in your case, software used in the manufacture or testing of your medical devices, should be validated for its intended use prior to making actual commercial medical devices. Changes to the system should be documented under your change control process.

If you have software in your medical device, that will be validated as a part of your design V&V activities.

Hi,

this requirement is the pair of 21CFR820.70(i) in the ISO13485:2003.

(i)Automated processes. When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.

Click to expand...

The key difference first, 7.5.2.1 does NOT consider to QMS automation software (for example, review tools, training administration tools, signature related tools, office sws, etc.) .
The second important difference, that you have to comply ONLY with the requirements defined in 7.5.2.1. . Shall note, in 21CFR820.70(i) when applicable you also must comply with 21CFR11 and of course with the guidances as long as your device is in classII or class III, namely the part11 guidance and with the software validation guidance issued by FDA.

More importantly, no IQ/OQ/PQ method mandatory in ISO world, YOU set up YOURown method.

As it is true in FDA world also, do not forget the case USA contra UTAH medical.
http://medgadget.com/archives/2005/10/judge_rules_aga.html

http://www.mckennalong.com/assets/attachments/jarcho.pdf


br
Sz.

I would have to disagree on the point of 7.5.2.1. I believe it can be construed as a requirement for automated QMS to be validated if important quality related information is to be used as a part of Management Review Process.

True, FDA has no strict requirement for IQ,OQ,PQ, but you must be able to prove what is scientifically appropriate.

Utah Medical spent millions fighting that battle, so in most cases, its better to comply with what the industry(CGMP) is doing, rather than fight the hand that will allow you to be fed.

Part 11 is dead in my opinion. FDA has enough regulation in Part 820 to issue 483's in relation to computerized systems. John Murray, FDA's software expert stated that FDAs medical device division is not routinely using Part 11 because they don't even know how to effectively police it.

Hi,
why do you think "production and service provision" means more than "production and service provision"?
Having several 13485 audit behind, not even "production and service provision" were fully investigated
br
Sz.

7.5.2.1 General Requirements- Last sentence:
...This includes any processes where deficiencies become apparent only after the product is in use or the service has been delivered.

To me, this would include your feedback system(or in FDA world, Complaint Handling)....so most automated QMS's include a complaint handling system, therefore, validation of such software is required.

agree with this!

but again, for 13485 you do not have to validate every sw you use during the design and development effort as an examples I gave.
br
Sz.