Software in Medical Devices, by MD101 Consulting

To content | To menu | To search


Validation of software used in production and QMS - Part 1 introduction

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

1. On Monday, 29 June 2015, 09:25 by Kataput

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!

2. On Thursday, 9 July 2015, 17:08 by Mitch

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.

3. On Tuesday, 10 November 2020, 20:37 by Oliver

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

4. On Friday, 13 November 2020, 17:37 by Mitch
Hi Oliver, Thanks for your feedback! "creating validation documentation which ultimately doesn't make too much sense" --> 100% agree with that. This is the feeling I have on most of QMS projects. The only solution is to use a risk-based approach on software. Does a SW failure lead to an unacceptable risk on product or on QMS documentation? If no, then that software is low-risk and a very lightweight validation is enough. Trying to answer to your question about time required is not possible, though. It depends on the number of software present and the risk related to sw failures.
5. On Friday, 13 November 2020, 22:48 by 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!

6. On Tuesday, 2 March 2021, 09:04 by Ben

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.

7. On Tuesday, 2 March 2021, 23:36 by Mitch
Hi Ben, This list is an interpretation of statements found in AAMI TIR36 and ISO/TR 80002-2 guidances. For example, in AAMI TIR36, you have the section 4.2 titled "in scope?", with questions helping the reader identifying software in the scope, like: "a) Could the failure or latent flaws of the software affect the safety or quality of medical devices?" I can't reproduce all the questions, AAMI TRI36 is copyrighted.
8. On Tuesday, 10 August 2021, 09:43 by Mos

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?

9. On Sunday, 12 September 2021, 20:00 by Mitch
Thanks Mos for your comment.
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.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed