Featured Product
This Week in Quality Digest Live
Management Features
Master Gage and Tool Co.
Why it matters for accurate measurements
Lee Simmons
Lessons from a deep dive into 30 years of NFL and NBA management turnover
Mike Figliuolo
Sure, you have to be professional, but have a good time anyway
Margaret Graziano
Unlocking the power of organizational culture
Graham Ward
Asserting yourself and setting clear boundaries

More Features

Management News
A tool to help detect sinister email
Developing tools to measure and improve trustworthiness
Manufacturers embrace quality management to improve operations, minimize risk
How well are women supported after landing technical positions?
Adds increased focus on governance
Survey shows 85% of top performers rely on it to achieve business objectives

More News

Kyle Rose


Understanding QMS Software Validation Requirements in ISO 13485:2016

Quality system software validation is nonnegotiable

Published: Monday, April 2, 2018 - 11:02

As I’m sure many of you know, the ISO 13485 standard for medical devices was updated in 2016, which means the time to transition your quality management system (QMS) is now. Most auditing organizations have either cut off ISO 13485:2003 recertifications or will be doing so very soon.

I was recently at a client’s location helping the company through its 2016 transition audit when an auditor from one of the largest notified bodies mentioned that less than 3 percent of its U.S. clients are ready to transition to ISO 13485:2016. As a leader in the quality consulting arena, we wanted to share some of our tips and best practices to make sure your organization is ready to ace its transition audit.

We’ll focus on the inclusion of a new requirements for quality system software validation in ISO 13485:2016. Section 4.1.6 outlines the process for validating computer software used in the quality system as follows:
The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application.

“The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software. Records of such activities shall be maintained.”

As you read through this section in the standard, you’ll probably realize that adjustments to both procedures and records will need to be made to your quality system to show your company’s compliance with the new revision.

The first detail to focus on is creating a quality procedure, or standard operating procedure (SOP), for the evaluating and validating software used in the quality system. The procedure should reference ISO 13485:2016 and “outline a risk-based approach to evaluating current, updated, and new software” that will be used in the quality system. This procedure will help guide your company to properly evaluating all QMS software throughout its life cycle.

Next, you should create a team to evaluate which pieces of software are being used in the quality system, and evaluate the risk of each of those applicable pieces of software. This assessment can include Excel spreadsheets, databases, Solidworks/CAD files for design activities, issue-tracking software, complaint-management software or CRM systems, PLM systems, ERP systems, and distribution software programs. The evaluation process should be documented, and the results should be tied to actions.

Often, when we work with our clients through this process, we use a gap analysis model and prioritize the highest-risk items first. If you decide to use a gap analysis during software evaluation, we recommend starting with a requirement review, which includes a user-, system-, and software-level analysis.

Requirement management serves as the foundation for software development and use within the quality system. Without full traceability of the software, it would be difficult to achieve compliance of managing risk and efficacy throughout the software’s life cycle. This traceability starts from the software requirements and follows through to risk analysis and verification or validation activities.

The next step in your software life cycle assessment is a review of the software system architecture and software design rationale. When potential hazards aren’t properly identified, no control measures can be implemented to address and mitigate the potential risks. Adding certain tools to your quality system regarding software can help better identify commonly overlooked hazards. In our experience, the most common reasons for overlooked hazards are:
• The risk management process, specifically for software systems, needs to be improved. Risks caused by off-the-shelf software (OTS) or software of unknown provenance (SOUP) are often not identified properly. This could be due to improper definitions of these types of software or not classifying software into different categories.
• A standardized process to identify, evaluate, and validate each category and classification of software is not established. Creating such a process will provide a consistent procedure to aid your company through establishing and assessing proper software controls.

Once you have completed your architecture and design review, software verification and validation activities must be performed to assess whether your software system is in a state of control.

Based on our experience, clients will sometimes proceed with software verification or validation activities without completing the necessary prerequisites (i.e., requirement management and risk analysis). We highly recommend that our clients have a clear understanding of how to achieve compliance throughout the complete software life cycle, so that verification and validation activities take place once the software has been configured to its usable form.

Achieving compliance will also include software maintenance and configuration management strategies from the beginning of the software life cycle until its end. Last year, 79 percent of all software-related FDA recalls were caused by software defects that were introduced to the system during changes made to the software after its initial production and distribution. Maintaining a state of control of your software and assessing all software changes after verification or validation is critical to compliance.

Properly assessing your company's QMS software can be difficult to do. Luckily, the Greenlight Guru electronic quality management system (eQMS) provides users with an easy-to-use application and a full validation package (IQ/OQ/PQ) to help them properly validate their systems and show compliance to the new standard. So, while only 3 percent of U.S.-based companies are ready for their new ISO 13485:2016 audit, our client was able to breeze through the audit with the support of the Greenlight Guru eQMS platform.

Consultants such as Rook Quality Systems are also helpful in achieving compliance to the updated standard. We are estimating that about three to six months of consulting work is required to get new companies audit-ready.

First published on the Greenlight Guru blog.


About The Author

Kyle Rose’s picture

Kyle Rose

Kyle Rose is a medical device expert, specializing in development of efficient quality systems for small and startup medical device companies. As President of Rook Quality Systems, Rose works as a the contract quality manager for multiple medical device companies overseeing overall quality strategy and ensuring compliance through documentation and auditing services. Rose is a certified quality auditor (CQA) and has regulatory and submission experience for a variety of markets including FDA, CE Mark, Health Canada, and CFDA. Mr. Rose encourages the simplification of quality systems to reduce the quality burden and improve compliance through training and efficient QMS design.