Software in Medical Devices, a blog 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.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed