Software Validation - Contract manufacturer of Components (PCBA's)

Registered

We are a contract manufacturer of components (PCBA's). We do not manufacture finished medical devices. We are not registered with the FDA. We receive prints from our customers that detail the product and its requirements they are purchasing from us.

We take design and development as an exclusion. Sterilization and UDI are non-applicable items and we do not assemble PCBA's that are used in implantable devices.

Section 7.5.6 states that "The organization shall validate any processes for production and service provision where the resulting output cannot be or is not verified by subsequent monitoring or measurement and as a consequence, deficiencies become apparent only after the product is in use or the service has been delivered". "The organization shall document procedures for the validation of the application of computer software used in production and service provision".

As a contract manufacture, assembling printed circuit boards with material purchased off the shelf, where the outputs are fully verified through our approval process, we do not assemble or sell the finished medical device (sell completed PCBA's to medical device companies that install our PCBA's into the finished medical device), are we required by the ISO 13485:2016 standard to validate computer software such as Microsoft Office, CCAM and software that came preinstalled in equipment used for assembling PCBA's?

We do not write macros or modify software used in the computers/production equipment and the software is controlled by the manufacturer. The software loaded into the equipment used in production is preloaded into the machine by the manufacturer, created specifically for that piece of equipment and controlled by the manufacturer (cannot be modified).

Registered

Based on the small information you gave you need to do a risk analysis of each software you are using in the process. Probably Office software do not have the same impact in the process as the software you are directly using in production to design and manufacture parts. For the software you identify they are critical, you probably need to do a software validation. That not necessary means that you need to validate all the software. You only need to validate functionalities you are using in the process. An other important aspect, you need to confirm that you are using the software in it intended use. If not it can be more complex.

Registered

Based on the small information you gave you need to do a risk analysis of each software you are using in the process. Probably Office software do not have the same impact in the process as the software you are directly using in production to design and manufacture parts. For the software you identify they are critical, you probably need to do a software validation. That not necessary means that you need to validate all the software. You only need to validate functionalities you are using in the process. An other important aspect, you need to confirm that you are using the software in it intended use. If not it can be more complex.

We did make a list and perform a risk analysis which shows a low risk. Most of the software that was loaded on the automated equipment does not receive any software updates, we use it for its intended purpose. We did perform equipment validation on each piece of automated equipment used in production (IQ/OQ/PQ) which shows the equipment is functioning the way it should function or as expected. Can the validation reports completed for equipment validation be used to cover software validation? For example, a Heller Reflow Oven we input oven profiles (use the software that is loaded into the machine by the manufacture, do not modify or update that software which is controlled/installed by the manufacturer) and save the settings for future use. We used recommended settings by the material manufacture when inputting these profiles.

Registered

I think if most of your software are loaded on your equipment I think most of the validation maybe done by the way of your IQ/OQ/PQ process. It will certainly cleaver to keep track of all changes done on any software. An other thing is you final quality control that can address some part of risk mitigation. Some thing is important you need to have a minimum to say about that and demonstrate you did a good analysis.

Hi dbaz..
As I can understand from your detailing, the s/w of your pick and place equipment could be one case to validate.
From the bare PCB panel that is loaded for machine learning, you will complete the machine programming (learning) for each of the PCB in the panel. Having verified and recorded your components reel or stick or tray loading, and having verified and recorded the polarity if any., your inputs are checked. When you run the first panel placements and complete the inspection, and find that the placements are just as needed, and record this, you are validating the machine programming s/w to be meeting your desired requirement.
You may be doing all this. If so, then please call it as the machine learning s/w validation report and make sure you have this for each of the PCBA.

Registered

Yes, we run the first panel where the panel is 100% visually inspected for correct component, polarity placement, presence, soldering defects, etc. Once the first pieces is accepted, production runs that work order and in-process inspections are performed during the run. We do this for all part numbers. Our equipment validation forms are titled Installation & Operational & Performance Qualification and the name of the equipment along with the serial number is recorded under the title. Do I really need to change the title of the form we are currently using for equipment validation or can I just add to the performance part of our report by including machine learning s/w validation for the final approval?

No issue with what's been posted already but I don't think it would be a complete software validation. Software validation has to consider more than just testing. Presuming we're talking about purchased software, there are a number of considerations. Did you install the software correctly (is any infrastructure software at the necessary level per the manufacturer, do you have the latest version with patches applied, are there any known bugs with the software that you need to avoid, ...). As far as I can tell, the only testing you would be doing with what's mentioned above would be "happy path" testing. Will your software properly respond to unexpected inputs or conditions? The "PQ" aspect for software might not be a factor but there could be some considerations (memory leaks if the software runs for extended time, etc.). Finally, do you have a process in place to monitor when the software changes or when the environment in which it runs changes? These could impact the validation. You should also periodically monitor for any new known issues or things like (security) patches.