ALM and Design Controls: Do SaMD and SiMD Manufacturers Need Both?

One consequence of the massive growth of software as a medical device (SaMD) and software in a medical device (SiMD) is the growing overlap between the realms of software development and medical device development.

Many software development teams are new to the MedTech space. And typically these dev teams are used to using what we can loosely refer to as application lifecycle management (ALM) tools like Jira, Gitlab, or Azure DevOps. These tools are built to help oversee software applications from conception through development, deployment, maintenance, and eventually retirement. 

However, while ALM solutions are great tools for building software applications, they do have some limitations when it comes to operating in the highly-regulated medical device industry. 

In this article, we’re going to take a closer look at ALM and the regulatory requirement of implementing design controls in the medical device industry. So if you’re wondering whether you need a design controls tool, or if your ALM can perform that function instead, read on.

FREE DOWNLOAD: Click here to download a checklist for premarket submission documentation for devices containing software.

How are ALM and design controls related?

Conceptually, application lifecycle management and design controls share a number of similarities. ALM solutions are commonly used across a variety of industries to help build and maintain high-quality software applications with more efficient development cycles. 

Design controls are also a means of ensuring that the product at the end of medical device design and development is safe, effective, and of the highest possible quality. 

Both ALM and design controls have processes for updates and changes to products and, despite some chronic misunderstanding on the subject, design controls can be carried out using Agile. This leads to a fairly common question: can my organization use documentation from an ALM tool to fulfill the regulatory requirements for design controls? 

Do SaMD and SiMD companies need solutions for both ALM and design controls?

While it may seem easier to use the ALM tool developers are used to for satisfying design controls requirements, I wouldn’t recommend it. It’s important to understand that design controls are a regulatory requirement authorized by the Federal Food, Drug, and Cosmetic Act. When FDA inspectors are auditing your QMS, they will expect to see the documentation of your design controls, and they will expect to see it in a specific format.

ALM solutions are great tools for supporting software development, but they are not built for compliance with regulations in the MedTech space. That’s why I advocate for SaMD and SiMD companies to draw a line between design controls and their ALM, rather than trying to make one work for the other. 

For example, let’s look at the difference between the user stories that a software development team uses and the design inputs required for regulatory purposes. A dev team will write user stories in a way that makes it easy for a developer to know what they should be working on (e.g. create an uploader following GraphQL parameters). 

Design inputs, however, specify requirements for the device that will then need to be verified against design outputs (e.g. the device shall allow for 250 MB files to be uploaded by the patient).

While that may seem like a simple semantic difference, it becomes important when FDA inspectors are auditing your QMS. The language of design controls should be “audit-facing”, meaning done in the way that regulatory agencies like FDA are expecting to see. Attempting to use ALM documentation and language for your design controls will leave you vulnerable to findings during an audit.

By drawing that line between design controls and software development activities like user stories, companies can ensure they can both ensure regulatory compliance and give developers flexibility in how they work.

What are the benefits of using distinct design controls software?

Now, when I say “draw a line” between them, I don’t mean that these systems should never communicate or that a design controls solution can take the place of a tool like Jira. In fact, Greenlight Guru Quality integrates with Jira and has API endpoint potential with other ALMs you might be using. 

But there are several things that a design controls solution like Greenlight Guru Quality will do for you from a regulatory perspective that an ALM won’t. 

Getting the regulatory record right

It’s worth repeating this point—design controls are a regulatory requirement, and you must have documentation that demonstrates you’ve followed the regulations. Being unable to find the appropriate documents and records during an FDA inspection is not a small matter. 

The FDA’s Form 483 observations can be extremely expensive and time consuming, and if you fail to demonstrate that you’ve handled the problems FDA observed, you could easily end up with a warning letter (which are made public and can take years to resolve).

That’s why we built Greenlight Guru Quality to ensure our customers always have access to the most up-to-date versions of their documents at a moment’s notice. Greenlight Guru Quality will generate documents for you that are required by FDA, such as your traceability matrix. 

It will also help you manage your Software Requirements Specification (SRS) and your Software Design Specification (SDS) to demonstrate traceability between the two documents. And all of that documentation is maintained in an audit-ready format.

Is it possible to develop some sort of extreme workaround to do all of this in an ALM? Maybe, but also consider that if you’re using ALM software in this manner, then it will need to be validated per FDA’s Computer Software Assurance (CSA) guidance. 

Connecting risk management with design controls

Another benefit of using Greenlight Guru Quality for your design controls is the integration of risk management with design controls. This isn’t just a regulatory requirement, either. Effective, comprehensive risk management is how we build safe and effective medical devices. 

There is always a patient on the other end of the devices we build, whether they are mechanical or SaMD. That’s why you must be able to tie your risk management to your design controls, demonstrating how you’re mitigating the risks you’ve identified as you work through the risk management process.

Doing all of this within an ALM is not only extremely difficult, it’s also risky (no pun intended) from both a regulatory and ethical standpoint. Tools like Greenlight Guru’s Risk Solutions are built specifically to help companies assess, document, and mitigate risk throughout the device lifecycle while ensuring you can demonstrate traceability with the rest of your QMS.

FREE DOWNLOAD: Click here to download a checklist for premarket submission documentation for devices containing software.

Greenlight Guru Quality complements your ALM with compliance and integrations

At the end of the day, ALMs are excellent tools for project management, testing, quality assurance, customer support, and service deliveries—but none of those are considered a Regulatory Record. 

Many of our customers at Greenlight Guru use an ALM like Jira, and they still see tremendous benefit in having a solution that ensures they are buttoned up from a regulatory perspective. To get a personalized look at how Greenlight Guru Quality can work with your ALM to keep you compliant, get your free demo of our software today →