Software in Medical Devices, by MD101 Consulting

New clause 4.1.6

The clause says:
The organization shall document procedures for the validation of the application of computer software used in the quality management system, including production and service provision.

That's brand new and could require a lot of man-hours in companies where the QMS relies on computerized system and produces lots of electronic documents and records.
That's however not so new for companies, which already implement 21.CFR regulation (see below).

The clause 4.1.6 continues with:
Such software applications shall be validated for their intended use prior to initial use, and after any changes to such software and/or its application. Records of such activities shall be maintained.

OK, that's logical. If we want to validate software, we need to validate them according to established criteria (the topmost one is the intended use), we need to revalidate when something has changed, and we need to record the validation results to prove that it was done.

The clause 4.1.6 ends with:
For each application of computer software used in the quality management system, the organization shall determine and justify the specific approach and the level of effort to be applied for software validation activities based on the risk associated with the use of the software

Pfew! We can choose our own approach and fine-tune the level of effort demanded by validation! But it shall be done according to the results of risk assessment.

My two comments (my two cents):

Comment 1: what kind of risk

Validation is based on risk assessment, high risk = heavy validation, low risk = light validation.
But what kind of risk assessment?
In the definitions section, we find the definition of risk and risk management, which both refer to ISO 14971. We can assume that the required risk management method is ISO 14971. However, there is no reference to ISO 14971 in clause 4.1.6, contrary to some other clauses dealing with risks elsewhere in the standard.
And what kind of risks should be assessed? Probably those, for which the root cause is a QMS software failure.
Knowing by experience how people don't feel at ease with software-related risks, I bet this risk assessment is going to burn a lot of man-hours in quality departments!

Comment 2: the least burdensome approach

I like this expression: least burdensome approach, because this is exactly what everybody is going to do. Translated in pragmatic words: everybody is going to do as little as possible to get through the validation.
This is the corollary of comment 1, if something is hard to achieve, I'd rather try not doing it. For example:

• A manufacturer which uses simple excel sheets (no formulas) to record CAPA could argue that there is very low risk of software failure, and as a consequence won't validate the sheets,
• Another, which uses an access database since 10 years without problems could argue that there is no need to validate something with a long history of use,
• A third one, which bought a license of a QMS management software could argue that the validation was done by the supplier management process.

These three examples could be adequate in some cases, and not adequate in others.

And 21 CFR?

To some extent, the new 4.1.6 clause is made to have ISO 13485 more in line with requirements of US 21.CFR regulation. More precisely, 21.CFR.870 (i):
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.
I put in bold or the quality system, hence software used in the production processes are already addressed by clause 7.5.2 of ISO 13485:2003. So software in quality systems, addressed by 21.CFR.870, are covered by the new clause 4.1.6.

Therefore manufacturers, which already apply 21.CFR regulations, won't be surprised by clause 4.1.6.

Conclusion

A lot of work is required to bring an existing and well automated QMS in line with the new clause 4.1.6. But if it's done in the frame of a regulatory strategy, it's worth the effort.
Thus it makes the QMS more ready to the changes in regulations (for example expected in Europe) and more in line with 21.CFR requirements about software validation.