Other

Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part 2

By |
Software Validation

This is part two of a two-part series on software validation and computer software assurance in the medical device industry.

Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part 2

In our previous blog post, we reviewed the top things to know about software validation and computer software assurance in the medical device industry. In this installment, we’ll take a closer look at computer software validation and provide tips and tools to manage your software in a compliant and efficient manner.

Main points

The FDA Draft Guidance on Computer Software Assurance

In September, 2022, the FDA released its draft guidance “Computer Software Assurance for Production and Quality System Software.” While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance on Software Validation, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). In this guidance the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”

There are many types of software used and developed by medical device companies, including those listed below. The scope of the 2022 draft guidance is on software used in production and quality systems software, as highlighted below.

  • Software in a Medical Device (SiMD) – Software used as a component, part, or accessory of a medical device;
  • Software as a Medical Device (SaMD) – Software that is itself a medical device (e.g., blood establishment software);
  • Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment);
  • Software in computers and automated data processing systems used as part of medical device production (e.g., software intended for automating production processes, inspection, testing, or the collection and processing of production data);
  • Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains the device history record);
  • Software in the form of websites for electronic Instructions for Use (eIFUs) and other information (labeling) for the user.

RELATED: Understanding Integrated Risk Management for Medical Devices

Understanding Your Software’s Intended Use and Risk-Based Approach

Defining the software’s intended use is an important aspect of managing your organization’s computer software assurance activities.

This then allows you to analyze and document the impact to safety risk if the software failed to perform to meet its intended use. One aspect that I appreciate the FDA adopting is the concept of ‘high process risk,’ when the failure of the software to perform as intended may result in a quality problem that foreseeably compromises safety and an increased medical device risk. The guidance has a number of examples to illustrate examples of high process risk and not high process risk. Previously, risk that purely a high risk to compliance only (i.e., no process risk) was essentially treated the same as risk that could compromise safety.

Commensurate with the level of process risk, guidance, and examples are presented to outline expected computer assurance activities, including various levels of testing, and level of documentation. Computer assurance activities for software that poses a high level of process risk include documentation of the intended use, risk determination, detailed test protocol, detailed report of the testing performed, pass/fail results for each test case, any issues found and their disposition, among others.

In contrast, guidance is provided that computer software assurance activities that pose no level of process risk can consist of lower level of testing, such as unscripted ad-hoc or error guessing testing. Prior to this guidance, the expectation was fully scripted protocols and documented results for each test case, which felt burdensome. For example, having to script out protocol steps to include user log-in steps for an electronic QMS module that facilitated the nonconformance process, which did not have a high level of process risk. The usage of the concept of high process risk and acknowledging that unscripted testing can be appropriate in times of low risk, will certainly help lessen the burden of compliance, without compromising safety.

Managing Your Software Efficiently

For those that think analytically like me, once can easily see the value of a Trace Matrix to keep my organization’s software organized and ensure the intended use, risk assessment, planned computer software assurance activities, and outcomes documented.

Similar to how it efficiently traces your medical device design inputs to outputs and links to your risk management, Jama Connect® is a great tool to also trace and manage all your software and software validation and computer software assurance activities. This includes documentation of the intended use, risk determination, and test protocols and reports performed. With its new validated cloud offering, SOC2 certification, and available Jama Connect Validation Kit, Jama Software also provides the tools and evidence you need to meet your organization’s computer software assurance activities.

RELATED: Jama Connect® for Medical Device Development Datasheet

Closing

Developing a risk-based process for software management, including software validation and computer software assurance, is key to staying compliant. Staying organized and using a tool like Jama Connect helps you do so efficiently.

To read part one of this blog, click HERE.


Michelle Wu
Latest posts by Michelle Wu (see all)