Explore the unique challenges and considerations of SaMD development.
Software as Medical Devices (SaMD’s) have continued to grow exponentially. While developing embedded hardware and software development may be on the rise, there are various teams who find themselves in numerous pitfalls because they misguidedly fail to pay attention to regulatory boundaries imposed by organizations like the FDA.
Different approaches to SaMD development can come with challenges for not only engineers but entire development teams. We are going to illustrate a few successful tactics as well as dangers from SaMD development projects.
In this blog we will explore:
- The Role of Design Controls
- Do's of SaMD Development
- Dont's of SaMD Development
- QMS for SaMD Development
The Role of Design Controls
Consolidating a strategy around strong design controls prevents delayed time-to-market. As the product awaits FDA clearance/approval, irregularities in areas like product definition or testing can further distort product development timelines. Many developers find themselves having to wrestle with regulatory compliance because they can’t check all the requirements under design controls.
21 CFR Part 820 is a vital regulation by the FDA and should be on your development team's radar.
If you haven’t you can check out our blog “What is CFR Part 820?” to learn more.
Under 21 CFR 820, there is a section (820.30) which dictates that user needs must be fulfilled solely by the medical device that is in development. Your team can ensure it is following this subsection of the regulation by:
- Product Requirement Definition:
- Detailing the user’s needs.
- Software Requirements Specification and Design Documentation:
- Detailing how your product (SaMD) will provide it.
- ISO 14971:
- Instituting risk management.
- Verification and Validation:
- Testing for evidence that the user’s needs are satisfied by your product’s usage.
21 CFR Part 820.30 calls for stringent documentation which is known as implementing "design controls”. In other words, design controls are meant to enforce documentation of any product definitions, reviews, approvals, or updates. The level of simplicity and straightforwardness, design controls will be easier to implement into the final product. It is important to note that if design controls are implemented too early in the process may result in loops of rework later in the design process.
Below we have illustrated a few successful tactics as well as dangers from SaMD development projects:
- DO: Use “testability” approach when defining product specifications
-
- When defining product specifications, it is important to not overlook The Software Requirement Specification (SRS) because it outlines what the software will do and how it will be expected to perform from functionality to user needs. Any specification listed in this document will be verified a multitude of times .
-
- A great approach is “testability”, or filling in the SRS with the tests in mind to support the verification processes. Your team should consider the following questions:
-
-
- Is that something we need to test?
- Does it tell us how to test it?
- Is it clear what passing is?
-
- DO: Take advantage of prototypes to boost design process
-
- Because of the growing importance of User Experience (UX), the FDA has identified UX as a factor to improve patient safety of SaMD’s.
-
- With clear user interfaces, navigation, and business logic, prototypes are a powerful tool for organizations like yours who seek to uncover any inconsistencies in design.
-
- Prototypes depict the limitations of product features and capacities based on user needs.
- DON’T: Underestimate the product level requirements
-
- A product requirements document (PRD) outlines the requirements of what your team is going to fully develop so any party or individual may understand what the final product should do.
-
- With a well-defined PRD, your team will set collective expectations around your product’s design and fulfillment. This will be an effective approach to building an efficient SaMD development lifecycle and allow for activities to be streamlined.
-
- With a badly-defined PRD, your team will be unable to meet requirements by failing to consolidate design goals and misguiding your developers and even engineers.
- DON’T: Ignore formal tracking of design inputs and outputs
-
- Without formal tracking of design inputs and design outputs, your product won’t be approved to market under FDA’s 21 CFR Part 820.
-
- Do not try and make a fully-designed product compliant after it has already been developed! Oftentimes, teams will focus on developing their product to a final stage but forget to validate the product using guidelines by the FDA.
-
- Your team will make it challenging to communicate with the FDA when your company isn’t enforcing 21 CFR Part 820.30 from the start of the development process.
How a QMS Can Help
FDA 21 CFR 820 mandates that medical device documentation be maintained and that changes in policy or procedure be recorded. A Quality Management System (QMS) will help you with the recording and documentation of all the processes mentioned above facilitating compliance with FDA 21 CFR Part 820.
Navigating the complexity of the regulatory industry can truly be made simple, and all of the weight should not fall on your shoulders. There are resources and tools, such as a QMS, that make your journey to market smooth and stress-free.
Sierra Labs Quality Management System, Sierra QMS, has helped multiple medical device companies implement proper implements management, document, and design controls. With our easy-to-use software, your quality manager will effortlessly access and reference the materials to perform their role. Above all of this, Sierra QMS is designed and aligned with current FDA guidance serving as an optimal compliance solution.
