Software Validation of Cloud Based Tools

Most medical device manufacturers use many, many software programs, systems, or services to automate quality system This software is not to be confused with product software – that is, software that runs as part of a medical device.  Medical device in this context could be custom hardware devices or Software as a Medical Device (SaMD).  Often this type of software is categorically referred to as “Non-Product Software”, “Quality System Software”, or “Tools.”

Software programs or services are used in many ways to automate quality system processes, and many of those processes are part of the product software development lifecycle.  For example, software systems are very often used to manage software requirements and specifications, track bugs or defects, manage software source code versions/branches, plan software development and verification activities, automatically execute test cases and evaluate pass/fail criteria, and many others.  Automation of quality system processes using software is highly encouraged as it reduces potential for human error, often captures richer data from the process, and ensures repeatability as staff members change.

However, both US regulations and international standards expect or require software that is used to automate quality systems processes to be validated for its intend use.  Validating this software clearly makes sense and should be part of our overall effort at assuring “product software quality.”  The FDA gives guidance on validating this type of software in the General Principles of Software Validation.  The approach, rigor, and on-going monitoring required to validate Non-Product Software greatly depends upon the “risk to product quality” resulting from failures of that Non-Product Software.  A common mistake is to attempt to approach validation of tools with a one-size-fits-all mentality or naively thinking that some standard (e.g., GAMP) will be appropriate for all types of tools.  Manufacturers, in their effort to assure quality, end up wasting enormous time and resources conducting very low value validation paper-work that, ironically, leads to less assurance of quality.  Obviously a “process risk analysis” should be used to properly plan and scale the validation – but that is another topic for another time.

A significant challenge that a manufacturer or developer will face is with the use of tools where the configuration will rapidly change.  Often we find this situation with cloud-hosted tools where the tool vendor will be deploying new versions/updates frequently.  This presents a challenge for one to argue that the tool “continues to be” in a validated state.  This raises many questions and every tool may likely have a different set of answers:

  • Should a manufacturer re-validate the tool each time a new configuration/version is pushed?
  • Can the manufacturer control the pushes and decide when to accept the new version?
  • Does the tool vendor notify of new releases?
  • Does the tool vendor identify what has changed from the previous version? and to what detail do they provide?
  • Does the tool vendor have any scheme for major, minor, and patch level releases?
  • Is there a way to deploy a test environment to validate the new release prior to deployment to the live environment?
  • Does the overall process, for which the tool automates some portion, have downstream quality control checkpoints that would catch potential software errors?
  • Does the automated workflow self-check in any way such that potential tool software errors might be caught?

There are likely many other questions to ask as well.  The answers to these questions, along with the process risk analysis, will help you formulate a plan appropriate and efficient for that tool or maybe even a class of tools.

About the author

Brian is a biomedical software engineer - whatever that is! Started writing machine code for the Intel 8080 in 1983. Still enjoys designing and developing code. But probably enjoys his garden more now and watching plants grow ... and grandkids grow!

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:




Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now



Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN, TX) and Canada.