It has been part of our efforts to make continuous improvements so that we can make the process of managing your QMS as simple as possible.
You might wonder, why is there a need for multi-level design controls? How can this workflow be applied to your product development efforts? Here’s a look at why we have done this:
Medical devices tend to be complex
It’s rare these days for medical devices to be simple. The large number of devices now require an app or some sort of software to operate. There can be several layers which add complexity.
It’s not just very recent devices either; think about products that have been around for a long time; for example, an insulin pump. These sorts of products have multiple components - circuit boards, mechanical enclosures, and accessories that connect to it. Each might be developed or produced by different parts of a team.
A simple, classic example of a medical device is a vascular needle. You have a hub and a needle cannula. It’s a simple device, but you can break it down into a number of constituent components and subsystems.
This is the genesis of the new workflow in the Greenlight Guru system. You can break down products to whatever level you need to, and manage design control activities at each level.
Why does it matter?
When you put all of these components together, they represent a bigger system. For example, Software as a Medical Device (SaMD) can be made up of different sub-systems and code classes. You might want to manage each component in an agile development environment, while maintaining full traceability. Having multi-level design controls allows you to do this.
For electrical/mechanical products where you have many different parts, including firmware and software, it’s important because it keeps all of the project design control and risk management information in one place. You can still have that overall view of the project, but also the people who are working on each segment can break it down to focus on the part they are working on. It’s much easier than having to scour through an entire design controls documentation to find the particular information pertaining to the specific item.
Historically the Greenlight Guru workflow around design controls was focused around the key element of compliance. It was about ensuring that all of the key sections were there to ensure traceability and that they were organized, and captured correctly by product teams.
In an effort to keep improving the design controls workflow, we have listened to some great customer feedback and set out to provide more project management functionality. We’re not talking Gantt charts, scheduling, or anything like that, but the ability to manage information in a more succinct manner.
The idea is that companies can use and manage a product development project in the same way that their teams are organized. If we look at our own Greenlight Guru team as an example, there is a front-end development team and a back-end team. There’s a UI/UX component too. Each of these resources is focused on different parts of the Greenlight Guru software development, so if they can organize their user needs, requirements, and specifications in line with their particular focus, it’s just much more efficient. They can focus better on quality, rather than just checking a box.
How is this different?
From a previous Greenlight Guru experience, a lot of users were using the tags feature to identify various components or subsystems, and would filter by tags. We added enhancements to make tags visible in the design control traceability matrix.
If you have been using Excel, it’s simply not a great way to organize your design controls traceability matrix. There are several different specifications required and it’s very document-focused. Traceability becomes a real challenge with an Excel or spreadsheet approach. It requires copying and pasting into the spreadsheets, which is where things can get messy. “Inefficient and error-prone” tend to be accurate characterizations of managing via spreadsheet.
Sometimes companies will opt to use a tool like Jira. It has its place - one good benefit is issue-tracking and being able to show the progression of bugs or features you’re working on. However, there is no way of showing that traceability for compliance. No way to show the flow from user requirements, to design requirements, specifications, and V&V.
Multi-level design control is to elevate your system beyond compliance and provide solutions for true quality. However, there is still a need for compliance. Traceability and being able to see the flows and progressions are very important for compliance, so we have combined the best of both worlds.
Benefits of multi-level design controls
One key thing that comes to mind is that I expect customers who use multi-level may still utilize Jira for issue tracking. And Jira is a good tool for issue tracking. Just understand its purpose and intent. Multi-level design controls provide you with more project management abilities and allows for Software as a Medical Device (SaMD) to better manage their work. It doesn’t go into the weeds where you wouldn't want regulators like Jira does, with checking things in and out and monitoring progress.
If you’re using Jira, at some point those tasks need to translate into documented design control information. This is where Greenlight Guru's multi-level design controls come into play. It’s about showing full traceability. How will user needs or requirements be translated into specific design input or software requirements? How do software requirements then get translated into software design specifications or design outputs? How do you then prove that outputs meet inputs, and software meets the needs of the end user?
The advantage is that we translate from traditional software terminology and put it into medical device regulatory speak, then organize that information as needed. Software is something that is very easy to change. It doesn’t require tooling, machining or assembly per se - with that, Greenlight Guru gives you the visibility to understand the impact of those changes and do it in one place.
Consider the impacts for design inputs too as these drive all product development activity. Here you can define all of your product subsystems or sub-subsystems, create a hierarchy, then build your traceability focusing on the design inputs or requirements of the particular subsystem.
Multi-Level Design Control will allow medical device manufacturers, and in-particular SaMDs, to better manage components or sub-components by introducing hierarchical workflows. You can manage each system or subsystem logically by team.
This will allow product development teams to have a more structured, holistic view of their design’s components, providing a centralized workspace with real-time updates. It combines the best of both worlds for compliance and quality.
To find out more about this new development, check out our features here.