Software Development & Validation

As a software manufacturer, do we have to validate our product
(software) for it to be considered compliant, or is it the
responsibility of the client who buys our software to validate it in
their environment?

I have always thought that as manufacturer, we need to follow 21CFR820,
ISO13485 and 21CFR11, and additionally at the end of the manufacturing
process we need to validate the software in our environment. Then it
can be sold as “compliant”, even though clients would also need to
validate it in their environment for it to be validated. Am I correct
to think this?

Other posts have made me doubt on the necessity to actually validate
our product at the end of the manufacturing process, assuming that our
process is “compliant” with the standards and regulations.

Any thoughts? Thank you!

While you, as the manufacturer, do not need to validate your product, I, as a client, would want to know that the systems you design are created and tested systematically. Most especially I would want to know that you had a Change Control SOP governing any updates.

The more systematic you are in developing your software, the greater will be you clients trust in its reliability and the more willing they will be to purchase it. In an audit I would want to see that you have documented User Requirements, System Design, Test Plans, Test Results, etc. etc.

Bottom line is that you are not required to validate by the government but may want to do so order to attract clients.

When I started in the computer validation business, before 21§11, we had two concepts, verification and validation. As software developers, we verified the software met the functional requirements of the customer. We did component, integrated and hardware tests to verify our product met specifications. We considered validation to be the testing activities that occurred during and after installation at our customer’s site. Verification is the activity of assuring the product meets design specifications as expressed in the user requirements. Validation is the activity of assuring the product is fully useable and meets the client’s needs. Of course validation included the software life cycle, since validation usually shows what needs to change in the very first “fix”.

Many software products are verified, but about 50% of them fail validation usually not due to poor testing, but due to poor interaction between the client and the software designers. In other words, validation is more than just compliance to 12§11 or other software requirements. A good software vendor is concerned about their customer and offers validation services even if it is a COTS product.

Watch out for the GAMP5 spin on validation versus verification.

From my post on the Yahoo Tech Group site:

Our customers tell us that vendor software is not 21 CFR 11 compliant - it is “enabled”. Compliance involves steps that only the end user can complete. We start with a completed 21 CFR 11 assessment plus GAMP.

You should consider offering IQ and OQ (but not PQ) protocols - also GAMP5 equivalents. But you offer the protocol - it is not executed yet.

Beyond FAT, SAT, GAMP etc. we have never seen a benefit in an in-house validation. It only seems to be expenditure with no return. All our customers have different approaches to validation. We’re only just seeing them start to ask us for our protocols (using the GAMP5 “leverage supplier documentation” approach). Much of our FAT and SAT is now being used by customers as an appendix to IQ/OQ - so why validate it ourselves too?

When we get audited the topic of change control is big so…

For “Category 5”, change control applies after FAT for code and applies at any time for signed-off documents. When writing custom code, the whole thing is in flux until you lock it down for the FAT so change control is a little bit difficult to quantify. I’ve argued this with customers a few times who expect CC pre-FAT but when I show them how you actually prepare custom code they back down.

I’ve actually never sold the same custom code twice in 21 years of automation engineering. No two clients have ever had the same requirements. The only exception being shared libraries and core data processing functions.11

On the other hand for code you use again and again or a software package that hardly varies from one client to another, you need good change control. “Category 3” for example.

This is the point, without the right work from customer QA no software can be compliant, an looks like a lot of customers don’t realize it.

Hi Frank
Sorry I missed your email when you posted first.

You are nearly right.

The onus is on you to produce software programs that are validatable by the end user.

That means if your software is purely functional; i.e. it controls a sequence of actions that are measurable or visible. Then the end user validation is pretty simple and does not demand a great deal from the vendor.

If on the other hand your software includes algorithms that integrate variables and execute a reaction (depending on the calculations), or take any decision that can affect the quality, then the end user must carry out, an in depth life cycle validation exercise. This demands very detailed knowledge of the software design/evolution/testing and QA history.

Where the software is somewhere in between these two examples and handles predicate rule data, then enough end user validation is required to ensure security (freedom from corruption) and integrity of that data.

So to sum up, the onus is always on you to know what the end user is going to use your software for and ensure you have sufficient software data to support their validation.

Most pharmaceutical software manufacturers produce a FAT (factory acceptance testing) which is a vey detailed test schedule for the software. Your customers either witness the execution of the FAT or request a copy.

When your software has been designed inaccordance with the GMP requirements and the FAT has confirmed this, you are quite entitled to say your software is GMP compliant and validatable by the end user.

If further advice is required, please do not hesitate in contacting me.

Alex Kennedy