What Medical Device Software to Develop Under QMS: Webinar Summary

Randy Horton

Published on: January 12th, 2024

february 2024 webinar li twi banner post event edit

The line between the device and non-device components of medical device software can sometimes seem blurry. Making the wrong choice to not develop a software module under design controls may lead to expensive, time-consuming rework.

How do you decide which parts of your device fall under your QMS umbrella, and which don’t? And how do you account for changes to your device during development as well as its potential changes in the future?

With good planning and forethought, you can lay the groundwork for a strategy that evolves with your device, keeps development on track and prepares you for any way the wind may blow.

Orthogonal convened a webinar on February 2nd, 2024, tackling the challenge of determining when to develop software under design controls. Our panel of expert speakers brought a unique background and perspective to the conversation, leading to a rich and sophisticated discussion:

Brendan O’Leary, Digital Health Technology Consultant, provided the regulatory perspective from his experience working at the FDA’s Digital Health Center of Excellence.
Elisabeth George, Regulatory Fellow at Orthogonal, brought insights into international markets drawn from her tenures at Hewlett Packard, Agilent and Philips in lead regulatory and quality roles.
Clay Anselmo, Principal Quality and Regulatory Consultant at Shriner and Associates, shared his perspective as a regulatory consultant who has helped many companies tackle these exact challenges.

Video Recording

Key Takeaway Points

1. As medical devices continue to take advantage of modern software (distributed system architectures, interoperability, service-based development, etc.) to increase their capabilities, new risks and challenges emerge that require new regulatory and quality solutions. Among these challenges is determining which parts of medical device software should be developed under design controls. Some examples the seemingly ambiguous situations that medical device manufacturers face include:

Software functions that are classified as medical devices in some regulatory jurisdictions, but not in others.
Software functions that start as non-device functions but may “upgrade” in the future due to:
- Changes from a regulatory body in how specific device functions are classified.
- Manufacturer’s enhancements to existing devices that enable the device to take on more ambitious intended uses which are classified as a medical device by one or more regulatory bodies.
Systems which are not medical devices that collect and manage data that might be used in the future to train AI algorithms embedded in medical devices.
Software that is used to train and validate AI algorithms which are then embedded in medical devices.
Medical device functions that are embedded in larger systems (and software ecosystems) which are primarily composed of non-medical devices.
Non-medical device functions that are embedded into larger systems (and software ecosystems) which are primarily composed of medical devices.

2. The FDA’s Multiple Function Device Products policy, published in 2020, aimed to address challenges of the growing integrated world that medical products reside in by distinguishing between device and non-device functions. You are encouraged to present evidence of good architecture, design and impact analysis of non-device functions, which enables regulators to focus on the device’s clinically significant features during review. The framework provides an excellent foundation for addressing the issues raised in this discussion.

3. The lines between device and non-device functions get substantially blurrier when a medical device is integrated into a larger health software ecosystem. A software architecture that supports your risk, quality and regulatory strategies can clearly delineate those lines and protect them. It’s recommended to break down a medical device system into discrete products, delineating the functions in each product and defining the interfaces, both internally between functions within the product and externally between other regulated and non-regulated devices. This approach benefits you in the long run in many ways, including by facilitating clear interactions with regulators and preventing the accrual of technical debt.

4. Our speakers view the decision to develop under design controls as less of a binary choice and more of a bell curve, where the rigor of controls is scaled by risk. Good modern software development practices at a baseline require some form of continuity; the level of design controls implemented for a given function of a device should be fit to purpose. If you develop all features of a medical device software under these practices, and later on determine that a non-device feature is a device feature, you’ve already accomplished 80% of what’s needed for a QMS – with the remaining 20% being relatively easy to implement. Following this baseline and adapting your practices as needed will lower your level of rework and set you up for the future.

5. As companies increasingly recognize data as a strategic asset, you may encounter terms such as “device-grade data” or “QMSlite” for differentiating data managed under design controls or a similar system. Our speakers rejected this distinction. In their view, all data – regardless of whether its clinical use is immediately obvious or determined later – should be stored and managed in a way that preserves its integrity. The data management guidance provided by the FDA in Part 11 is a valuable resource.

6. The practice of medicine and the regulation of medical devices is different in every country. A product that is considered a medical device in the U.S. may not hold the same classification in another country, and vice-versa. You may or may not know which countries you will choose to sell your device in, so aligning with good software product development practices as described above is a good business decision, especially if a non-device function in one country (e.g., the U.S.) is considered a device function in other countries.

Watch Webinar Recording

Speakers

Clay Anselmo

Clay Anselmo, Principal Quality and Regulatory Consultant, Shriner and Associates

Clay is an internationally recognized regulatory compliance expert with an unmatched track record in resolving pre- and post-market quality and regulatory compliance issues. Clay has provided strategic input and direction and led complex quality-related projects for hundreds of medical device companies facing regulatory enforcement. Clay regularly provides strategic consulting on complex quality and regulatory matters including quality system development, remediation, regulatory submissions and clinical studies. In addition to his duties at Shriner & Associates, Clay currently provides strategic direction as a board member to a number of life sciences companies across the globe.

Brendan O’Leary, Digital Health Technology Consultant

Brendan O’Leary provides consulting services on digital health and medical device regulatory strategy to technology developers, healthcare organizations, trade and professional associations, and other stakeholders.

Brendan worked at the FDA for 14 years in a variety of roles, most recently as the founding Deputy Director of the Digital Health Center of Excellence and as its Acting Director throughout 2022. Brendan contributed to hundreds of precedent-setting decisions and co-authored dozens of policy documents that continue to provide the foundation for the FDA’s digital health efforts. He frequently represented the FDA on digital health and other topics through presentations at conferences and professional society meetings, press interviews, and interactions with Congress. Brendan also made significant contributions to the federal government’s response to SARS-CoV-2.

elisabeth george headshot 200px

Elisabeth George, Regulatory Fellow, Orthogonal

Elisabeth George is an experienced leader, business executive and consultant committed to shaping and leading global organizations in continuous improvement and innovative ways of using standards and regulations, not only for compliance but also for supporting customer value. She is committed to making an impact through her skills as a leader, her experience in Medical Device Regulations and Standards and her desire to be a learning partner in delivering positive business outcomes.

Elisabeth has held senior leadership roles for more than 30 years, joining Haemonetics in 1989 as a Director of Quality and Regulatory to Sr. Director and Vice President of Quality and Regulatory positions with Hewlett Packard, Agilent and Philips. She holds a Bachelors in Science, Biomedical Engineering from Boston University and a Masters Certificate in Engineering Management from Northeastern University.

Randy Horton

Randy Horton, Chief Solutions Officer, Orthogonal

Randy Horton is Chief Solutions Officer at Orthogonal, a software consulting firm that improves patient outcomes faster by helping MedTech firms accelerate their development pipelines for Software as a Medical Device (SaMD), digital therapeutics (DTx) and connected medical device systems. Orthogonal makes that acceleration happen by fusing modern software engineering and product management tools and techniques (e.g., Agile, Lean Startup, User-Centered Design and Systems Thinking) with the regulated focus on device safety and effectiveness that is at the heart of MedTech.

Horton serves as Co-Chair for AAMI’s Cloud Computing Working Group, as well as AAMI CR:510(2021) and the in-process Technical Information Report #115, all of which address how to safely move medical device computing functions into the cloud. He is a frequent speaker at conferences and webinars, including events hosted by AdvaMed, AAMI, HLTH, RAPS and the Human Factors and Ergonomics Society (HFES).