Non-Product Software (NPS) Validation for Medical Device Manufacturers

Compiling a comprehensive list of all non-product software (NPS) and conducting an initial risk assessment are critical first steps in the validation process. While low-risk software likely won’t require a validation plan, it is required for medium-risk to high-risk software. Armed with a comprehensive list and a thorough rating of risks, you’re ready to dive directly into creating a validation plan and conducting the validation itself.

Developing Your Computer System Validation Plan

NPS is sometimes called computer system validation. Whatever you call it, it is a process. It is part of the master validation program, and there are inputs and outputs linked to other activities, and all activities must be documented to create evidence. “Incomplete NPS validation” nonconformity observations are not uncommon!

An important first step is to understand how NPS validation fits into the overall validation program and which specific software it covers. It is considered best practice to identify a separate process mechanism for NPS validation from your other validation efforts, such as for equipment validation or manufacturing process validations.

NPS Validation Is Linear and Generates Multiple Outputs

Before you begin, we recommend creating a template that documents what needs to be completed during the validation process for each piece of software. AAMI TIR 36:2007 and are essential reference standards as you work through this process. A template will ensure consistency between validation projects, avoid missteps, and reduce the time needed to complete the actual project. Your validation plan may include:

• System Design and Description Document (SDDD)
• Requirements Specification Document (RSD) and detailed specification(s)
• Validation activities performed through life cycle of software

Plus…

• The version of software at planned time of validation
• The validation steps being performed:
  • Configuration Testing (CT)
  • Functional Testing (FT)
  • Requirements Testing (RT)
• Documentation of validation activities
• Change management criteria or needs
• Revalidation review

You may wonder about the relationship of NPS validation to your Master Validation Plan (MVP) and whether they can be done simultaneously. Yes they can, but it depends on the complexity of your manufacturing and facility operations, how many independent NPS applications will be validated, and the overall risk level of software applications. As an example, your manufacturing may have various pieces of equipment all controlled and monitored by internal software applications. You can think of NPS validation as a subset of your MVP for certain equipment in the facility.

Determining the Level of Effort for NPS Validation

As we mentioned earlier in our first article, software introduces varying levels of risk, and your numerical rating of those risk factors will determine the level of effort you put into validation, qualification, and documentation.  You’ll want to clearly document a standard procedure for how risk is assessed and the corresponding level of effort for NPS validation

LOW Risk Level 1	MINOR Risk Level 2	MODERATE Risk Level 3	MAJOR Risk Level 4	SIGNIFICANT Risk Level 5
Document rationale for not performing verification or validation. Document use and operation.	Qualification of software where installation or confirmation is performed.	Validation of software along with a routine review performed.	Verification may be necessary depending on source code or development process; validation needed.	Verification and validation required for in-house NPS; confirmation of development process for external NPS.
GAMP5 category: Infrastructure & eQMS systems	GAMP5 category: Not used in GAMP5	GAMP5 category: Nonconfigurable software	GAMP5 category: Configurable software	GAMP5 category: Bespoke & custom software

Many companies use the GAMP5 categories shown above by default, but other factors come into play, including:

• If the software was purchased versus developed in house
• If it is configurable or not
• If it is standalone or part of a system

GAMP5 categories may not fit every company or situation, but it’s a good starting point. Also, remember that NPS risk ratings can change over time.

How to Handle Low-Risk NPS

It’s natural to think that a significant percentage of non-product software is low risk, but that’s not the case. When NPS is rated as low risk – especially off-the-shelf (OTS) software – you may simply document use and operation of the software rather than conducting full validation. That being said, you need to think about how the operation of the software may impact many other systems or processes, even if code and versioning is not under your organization’s control.

You’ll want to use your risk assessment template and document it on the NPS inventory list. In addition to your justification, you’ll want documentation to include information about the software system, the review process you used, and how often it will be reviewed (with each new version or every five years, for example).

It’s Not All on You – Maximize the Resources of NPS Developers

Many developers of OTS software will have a “validation package” available. You may not find it on the website, so contact support to ask if you don’t find it. You should take advantage of this documentation to reduce duplication and document actions for validation activities. You need to be flexible about this because it is unlikely that documentation received from the supplier will conform to your internal format, so you’ll have to devise a method for “transposing” supplier documentation, much of which may be in PDF format or online only.

What About Internet-Only Applications and Spreadsheets?

Subscription-based online tools are increasingly commonplace. They offer some advantages in that they are accessible from anywhere and frequently updated with new functionality and security patches. Those updates also pose a challenge from a validation perspective and raise cybersecurity concerns that must be managed. For instance, you need to assess how your data is being stored, who has the login information internally, and the impact on other processes if the application server “is down” or your internal internet connection is offline! Also, in the age of working from home, consider any new security risks this may introduce.

Spreadsheets are also commonly used in manufacturing processes for calculating information, in QA for documenting information, for QC calibration or testing, or even in final product testing for product acceptance. Even a “simple” spreadsheet should be considered in the overall NPS program. The important thing to remember is that you are not validating Microsoft Excel software code (you do not have access to the source code) but rather how the program is used. Macros, formulas, conditional formatting, and lock cells should all be evaluated. You’d be amazed how long erroneous formulas can hide in their cells undetected. Spreadsheets that are logs (noncalculation) can be treated as forms through document control. The FDA “ORA Laboratory Manual, Volume III, Section 4, Subsection 5, Development and Validation of Spreadsheets for Calculation of Data (2019)” makes for some excellent bedtime reading.

Creating the Documentation Needed to Write a Test Protocol

Before you can write your protocols and begin testing, you’ll need to document the software system and how it is used.

• System Design and Description Document (SDDD) – General description of software, architecture design, relationship to hardware, and whether it is standalone or part of a system. Installation requirements, functionality and operation, and version control identification should also be addressed.
• Requirements Specification Document (RSD) – Details requirements associated with use of the software. There is no defined number, type, or structure of requirements documents as this depends on the risk, category, and level of effort of the software being qualified, verified, or validated. An RSD can have subsections for user requirements, data integrity requirements, and cybersecurity requirements. Shown below is an example of RSD documentation for software driving an automated filling and sealing machine. Developing an RSD establishes the requirements needed to create the testing protocols

• Software Requirements Specification (SRS) – Details the requirements for overall program or major components / modules of a system, typically for moderate to highly complex systems. It describes the interaction with hardware components and equipment and how the software operates. Put simply, the SRS focuses on system requirements, whereas the RSD focuses on user requirements. There is a “cascade” or downward linkage between RSD to SRS to SDS where these are used to show dependencies.

Final Step: Write Protocols, Do the Testing, Summarize Results

You’ve made it this far, so you might as well enjoy the final installment in this series, which talks about writing your protocols, conducting the testing, and summarizing the results in a matrix. Of course, this article series just scratches the surface of what you need to know, so if you really want to take a deep dive into this topic, consider our intensive NPS software validation training course.

Get answers right now. Call