Validation of software used in production and QMS - Part 1 introduction
By Mitch on Friday, 19 June 2015, 12:34 - Processes - Permalink
Validation of software is an unlimited source of topics!
After discussing in a previous article the validation of software in development process, let's see how to validate software used in production processes and in the management of QMS documents and records.
Edit June 2016: this article remains relevant with the new requirements on software validation found in ISO 13485:2016.
Why validate?
Software may hide bugs, it may be misconfigured, it may be misused. For all these reasons, software may give wrong results and should be validated.
The requirements of software validation stem from these practical reasons.
FDA QSR
Regarding US regulations, software validation has been required for almost twenty years, namely since June 1, 1997.
The article 21.CFR.820.70(i) reads:
- 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.
Thus every software used in production or in the QMS by a manufacturer, shall be validated.
Likewise, the 21 CFR part 11 adds requirements about the management of electronic records and electronic signatures. If software used by a manufacturer manage such elements, it shall be validated.
ISO 13485:2003
ISO 13485 in this actual version requires to validate software used in production processes. Namely, section 7.5.2 Validation of processes for production and service provision of the standard reads:
- The organization shall establish documented procedures for the validation of the application of computer software for production and service provision that affect the ability of the product to conform to specified requirements.
There is no requirement to validate software used in any other process or in the QMS. The validation scope is very narrow, compared to US regulations.
ISO 13485:2015 DIS2
As we've already seen in a previous post, the draft of the future version of ISO 13485 always contains the requirements of software validation in section 7.5.2.
And it adds new validation requirements of software used in the QMS. The new requirement in section 4.1.6 reads:
- The organization shall document procedures for the validation of the application of computer software used in the quality management system.
Thus every software used in a company, which claims ISO 13485 compliance for all of its processes, shall potentially be validated.
ISO 13485:2015 should be released officially in 2016 and harmonized in late 2016 or 2017.
Thus, when this new version comes into the list of harmonized standards in Europe, companies will have to validate software within the same scope as US regulations.
Only 21 CFR part 11 electronic records & signatures requirements will remain US specific.
Scope of validation
The scope of validation doesn't include all software used by a manufacturer. The scope includes:
- Software tools connected to a production equipment, a control equipment, a measuring equipment:
- This is the most obvious case hence they are already in the scope of ISO 13485:2003
- Computer-Aided Production Management (CAPM), containing documents and records for production (production routings, inspection plans, production and inspection records...):
- This case is connected to the previous one and already in the scope of ISO 13485:2003
- QMS Software tool managing documents and records:
- Document Management tool, like Alfresco,
- Excel sheet containing QMS records, with macros or formulas, like a sheet containing CAPA and a macro to compute due date,
- Software tool managing customer complaints, hot-line tickets and requests:
- Tool to receive complaints by mail and store them in a database, like Request Tracker,
- Tool to manage software bugs, like Redmine,
- Software tool managing services delivered to the customer:
- Tool to give remote access to company documentation for technicians on the field,
- Tools to manage service reports,
- Any module of an Entreprise Resource Planning (ERP), dealing with the aspects above,
- Any bespoke or home-made software, dealing with the aspects above:
- Access database,
- Website and database developed by a subcontractor,
- Any excel sheet with formulas and macros,
- Cherry on the cake, any tool producing/managing electronic records according to 21 CFR part 11:
- Any software quoted above,
- Backup/recovery tools ensuring the safekeeping of electronic records in the timeframe required by regulations.
That's a lot!
Fortunately there are software applications not in the scope of the validation:
- Financial and administrative software outside the scope of the QMS,
- MS office (or any other suite) used for daily paper work, be careful with macros, however,
- Mailing system, be careful with mail server agents used to automate processes,
- Any software outside the scope of regulations and standards (easy to say but borderline cases are one hell of a question!).
Software part of the IT and network infrastructure can be excluded from the scope of the validation, at first sight:
- Operating systems,
- Network tools,
- Server tools (virtualization, load balancing ...).
But, if there is a risk that a failure of such software can challenge the validation of other software, then they shall be validated.
Hoping you're not too desperate!
Fortunately, there are escape plans. We'll see them in a further post.
Next time we'll see how to plan this validation, with the Validation Master Plan.
Comments
Dear Mitch,
Thank you for your article. Software validation is still a controversely discussed topic here in Europe...at least for SME.
I got a question to the exclusions you mentioned: why is MS office excluded? I know a lot of companies that use MS O to manage there requirements (Design Input) and other crucial design steps. This is, in my eyes, one product quality related topic, isn't it? I would like to know your thoughts on this.
Thanks again!
Hi Kataput,
Thank you for your comment.
A barebone MS Office document or spreadsheet can be seen as electronic paper. It can be admitted that MS Office does his job well enough to create and modify electronic documents and records. I agree with you that the controversy is in "It can be admitted that".
Challenging the capability of MS Office to write documents and records is like challenging the capability of paper and pen to write documents and records. As long as you use basic functions of MSO, you stay in a safe zone.
The risk is more in the storage of documents: how to make sure that the ink won't fade?, likewise how to make sure that old MSO files will be readable? But this is not MSO that we have to validate here, this is the long-term storage processes, allowing us to be compliant record storage requirements of regulations.
Note that it's not what I wrote for MSO macros. Macros are company-made piece of software and the need of their validation should be assessed with scrutiny.
Hey Mitch,
Great article, as many others on your website! :) I think it's super impressive that you publish these step-by-step guides for free and even open-source your templates. I'm trying to do something similar on my website as, ironically, the quality control of regulatory consultants doesn't seem to be very good and that way we can hopefully alleviate the regulatory pain which many companies typically experience :)
I've noticed that the (13485-compliant) validation of software seems to be a very controversial topic which is also poorly understood by most consultants, especially those who don't have software experience.
I looked through your templates and am curious: How much time would you typically spend on validating a specific software package? In my experience, even startups may already have upwards of 20 software packages in use which influence production processes and/or the quality of their product. There's hardly any time left to validate those before the QMS audit; even less so for removing/changing any should validation of some fail.
So it often ends up becoming an exercise in creating validation documentation which ultimately doesn't make too much sense.
So: Interested to hear your experience here on how much time it takes you and how you get this done in a pragmatic way.
Oliver
Thanks for your reply! Yeah, that is also my experience - applying a risk-based approach and having very light-weight documentation for certain (most?) software. As one auditor put it: "Software validation is where the 13485 became a bit unreasonable". I just wasn't sure whether other auditors and consultants also see it that way, but your experience confirms that. Thanks!
Hi Mitch,
In the Scope of Validation, you have defined very clearly what software needs to be validated in ISO 13485:2016, clause 4.1.6. May I know:
1) where did you reference from? Because I could not find a clear definition of what software needs to be validated in ISO 13485:2016.
2) which ISO document states clearly what software need or not needed to be validated.
Thank you for clarifying the question on software validation.I am curious about how one should validate an eQMS that is provided with supplier validation package, including URS (User requirements Specifications).
Does the software user still need to reproduce their own URS, compatibility check, back up and recovery, configuration management, etc.
If the validation package includes configurations and references to information in the system about security management, what more should the user validate?
Does the software user still need to reproduce their own URS, compatibility check, back up and recovery, configuration management, etc. --> Yes.
If the validation package includes configurations and references to information in the system about security management, what more should the user validate? --> you still validate your use of the eQMS against the URS. So you need some test plan and test report. Security is a specific topic within the validation process. If the vendor have their security certificate, this is probably fine. Auditing the vendor's security process would probably be overkill.