What You Need to Know About Medical Device Software Validation

Software is certainly not a new concept to the medical device world.

For years, the industry has utilized cutting edge technology in its development and it’s time the industry started utilizing cutting edge validation, as well.

Perhaps more than any other sector, medical device software truly represents the needs of its users, especially when it comes to improving the quality of life for patients and providers. In order to do so, however, there needs to be an emphasis on software validation.

FREE DOWNLOAD: Click here to download our Ultimate guide to Software as a Medical Device (SaMD).

What is medical device software validation?

Software validation is the process of confirming that an overall product—hardware, software, or software as a medical device (SaMD)—meets its intended use. In this instance, “intended use” refers to the high-level requirements set forth during the device’s design phase, i.e., the needs of the user. 

Medical device software validation generally occurs during or at the end of the development cycle. In many ways, validation is a chance to evaluate the medical device software that has been designed and answer some outstanding questions, like: 

• Does the software fulfill the needs defined in the intended use statement?

• Are there any identifiable risks? 

• Have any identifiable risks been mitigated?

• Does the software meet regulatory requirements?

However, this is not to say that software validation for medical devices is strictly a philosophical discussion. Validating software is still a technical undertaking; in the FDA guidance document General Principles of Software Validation, validation is defined as, 

Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.

The key phrase here is “objective evidence,” which indicates that software validation requires documented, empirical proof that you have built the right product. This can be accomplished through a number of real-world approaches, such as clinical trials, black box and white box testing, customer acceptance testing, modeling, and usability testing. 

With regards to design validation, FDA’s Quality System Regulation states that it, “shall ensure that devices conform to defined user needs and intended uses, and shall include testing of production units under actual or simulated use conditions.”

This means that while these tests may occur either in real or simulated environments, they must be performed by representative end users, and generally require a larger sample size than those used in functional testing. Additionally, medical device software validation must include the execution of the code.

How is medical device software validation different from software verification?

It would be difficult to discuss medical device software validation without including its counterpart, software verification. In fact, these two terms are so closely related, they are often confused or used interchangeably. However, they play two vastly different roles and specifications in the software development lifecycle.

The difference between software validation and software verification can be found by asking these two slightly varied questions:

• Verification: Are we building the product right?

• Validation: Are we building the right product?

Though only differentiated in the placement of just one word, these two queries represent two areas of work that are miles apart. Software validation is a process of checking if the product will meet the customer’s actual needs, while verification involves procedures for making certain that the software is well-engineered, free of errors, and functional. 

So, while verification will help to determine whether the medical device software is of high quality, it cannot be used alone to ensure that the product is useful.

How is medical device software validation regulated? 

Validation is a crucial step in ensuring the safety and efficacy of medical device software. Not only does it keep the focus on user needs, it also furthers a culture of building quality products that fulfill intended use and do what they claim to do. So, it only makes sense that it has become the focus of regulatory bodies across the globe.

EU market requirements for medical device software validation

There are several regulations and standards around the globe which apply to the validation of medical device software. The European Union Medical Device Regulations (EU MDR) require software validation, per Annex I, Section 17.2: 

The software shall be developed … taking into account the principles of development life cycle, risk management, including information security, verification and validation.

Another notable standard is IEC 62304:2006 — Software life cycle processes, which outlines its guidance for creating quality software systems. In fact, it’s so well-respected, that the standard is harmonized with EU MDR. IEC 62304 also establishes specific requirements for software validation. 

Manufacturers with devices in the EU market should also look to standards like ISO 13485, which covers design and development validation guidelines in section 7.3.6. 

Additionally, IEC 60601-1 also requires software validation in its section 14.11 "PEMS Validation.”

US market requirements for medical device software validation

In 2002, FDA released its final guidance document, General Principles of Software Validation, which gave ample space to defining key terms relating to software validation, and outlined the basic tenets of its approach to software regulation for medical devices. 

Of course, the world of technology and medical devices has changed drastically over the past two decades. The agency had planned to release an updated version in 2020, however now it looks like it will be postponed until 2022. 

While the current guidance document doesn’t explain exactly how to complete software validation, it does require it for all devices sold in the US. 

Currently, the two main FDA requirements for software validation are: 

1. The products you make and the processes you follow must meet or exceed FDA’s standards for production and inventory management. 

2. Every step of the validation process must be documented. 

Because FDA doesn’t know how your company intends to use its software, you’ll need to illustrate this through your validation plan. This process also includes determining the specifications and quality guidelines that define success, as well as creating a varied group of test cases to play out common scenarios in which the software will be used.

What are the steps for medical device software validation?

Much like any element in a QMS, the process of software validation is more than a box to be checked off. Again, this is your chance to ensure that the medical device software you’re developing is going to satisfy its intended purpose. 

However, for organizations new to the world of medical device software, or those who are looking for a more efficient and effective way to comply with regulations, here are five easy steps to follow for software validation that will ensure you’re able to market your product in the US or Europe.

Step 1: Create your software validation plan

Your validation plan is a crucial first step. Not only will it provide documentation and describe the entire software system and the environment in which it will operate, it also identifies any assumptions and limitations of the project, your established test acceptance criteria, the validation procedures you’ll follow, and the who’s who of your validation team and their individual responsibilities. 

This is truly your master document as you proceed through the rest of the steps in the software validation process. That being said, the validation plan may become a living document as you define further steps needed. Just be sure that you’re documenting those changes along the way.

Step 2: Determine your system requirements (SRS)

Outline the conditions that need to be in place for the software to perform as expected. These include infrastructure requirements, such as the necessary staff, facility and equipment, as well as the functional requirements, including performance and security requirements, system and user interfaces and the operating environment. Your SRS may also include a risk analysis to identify any gaps in your functional requirements.

Step 3: Create a validation protocol and test specifications

Now you must outline what you expect the software to do and how you’re going to prove that it works. This involves creating a test plan and test cases. Your test plan documents why and how you’re going to test and verify the medical device software. 

Your test cases will re-create common scenarios that prove the software can produce your regulated product or conduct a key business process. They are designed to uncover as many potential errors as possible and to demonstrate whether key features are performing properly.

Step 4: Conduct and document tests

Based on your test plan and test cases, this is where you actually conduct the tests and document the results, including successes, errors, and failures.

Step 5: Establish procedures and write your final report

After you’ve completed testing, you must establish and revise procedures for using the software. Writing, reviewing, and approving your final validation report is the last step before releasing the system for use within the company. This report should also include information on support, training, security backup, and recovery. 

FREE DOWNLOAD: Click here to download our Ultimate guide to Software as a Medical Device (SaMD).

See the bigger picture of software validation with Greenlight Guru

Software validation is one of the headier procedures in medical device regulatory pathways. It’s a chance to evaluate and improve your software and make certain it’s meeting the needs of users. Accomplishing this will require a holistic view of your device, including every change you’ve made along the way.

With Greenlight Guru, you can create detailed control objects, link complex configurations, and attach documents with a single click. And most importantly, never lose sight of any of it: easily navigate between test reports and protocols to your design control verifications and validations, while also seeing related design inputs, risk controls, and components.

Ready to experience the Greenlight Guru Difference? Contact us today for your free, personalized demo →