Diagram showing categories and sub-categories of software at a medical device company superimposed on a painting of a landscape

Understanding the Software Landscape

“Just validate the software!”  That sounds simple but at a medical device company there are many types of software that need to be validated and the rules and requirements are different for each type. I put together this diagram of the “software landscape” to help people understand what type of software they’re working with. The diagram shows all the categories and sub-categories of software at a medical device company with examples of each type.

Product Software

First, we divide the landscape into product software and “non-product software.” Product software, if it’s regulated, falls under FDA design control regulations and international standards for medical device development such as IEC 62304. Product software includes all the software you develop plus any third party software included in your product. Within the regulated product software category there are three sub-categories based on the safety risk of the software (classes A / B / C per the IEC 62304 medical software standard). The fourth category “Enforcement Discretion” refers to low risk applications that are technically regulated by FDA but for which FDA has decided not to enforce regulations.

Diagram showing categories and sub-categories of software at a medical device company

 

Non-Product Software

On the non-product software side different regulations and standards apply and therefore different requirements for validation and documentation. I’ve divided the non-product software into three main sub-categories: software used in manufacturing, software used in product development, and software used in the quality system. I chose these three sub-categories because they tend to have different risk profiles and life cycles and they affect different groups in the company. 

Manufacturing Software

Software used in manufacturing can directly affect product quality and typically has the highest risks associated with it. For example, failure of an automated test system used in the manufacturing line could allow defective products to be shipped. This type of software is used by manufacturing personnel and validation of it is managed within the larger framework of process validation.

Design & Development Software

Software used in the design and development of a medical device can indirectly affect product quality. This type of software is used by product teams during development and may have a very short life span.  For example, a software test script that is used once during V&V testing.

Quality System Software

Software used to automate parts of the quality system, such as Doc Control or CAPA management, can indirectly affect product quality (and can directly affect compliance). This type of software may be used across the organization or just by a small group of users and often has a life span of many years.

Corner Cases

The categories and sub-categories illustrated here are a good ‘mental model’ for understanding how to manage different types of software but the reality we face in a medical device company is not always so neatly categorized. Some software can fall into two or more categories. For example, an ultrasound system may have hardware diagnostic software installed in it that is used in manufacturing and by service personnel but is never part of clinical usage. This could be considered product software (it is installed in the product) and non-product software. In cases like this companies need to carefully analyze the risks associated with usage of the software and manage it accordingly.

Validation of Non-Product Software

Non-product software includes a wide range of software–everything from an Excel spreadsheet to a software test script to a very complex PLM system. That means validation strategies and methods (and documentation) must be adjusted appropriately, depending on the risk and complexity of the software. A one-size-fits-all approach to validation will either over-validate or under-validate the wide variety of non-product software. To better understand these validation challenges, I recommend studying the FDA guidance for “Computer Software Assurance for Production and Quality System Software” and the international guidance ISO/TR 80002-2:2017 “Validation of software for medical device quality systems.” This international standard is based on the older AAMI TIR36:2007 guidance – Validation of software for regulated processes.

The ISO/TR 80002-2:2017 “Validation of software for medical device quality systems” can be purchased here:  ISO/TR 80002-2:2017

The FDA draft guidance for “Computer Software Assurance for Production and Quality System Software” can be downloaded (for free) here:  Computer Software Assurance

For some handy tips on performing validation of non-product software (or “Computer System Validation”), take a look at this article from Aligned Elements: Speed Up Your Computer Software Validation

Leave a Comment

Your email address will not be published. Required fields are marked *