Empower your teams with insights and solutions that transcend the challenges of medical device software development.
Navigate the complex terrain of medical device software development and learn crucial insights and practical solutions to propel your projects forward.
In this webinar, Romer De Los Santos, Senior Consultant at Jama Software®, guides you through:
- The new SaMD Framework, which features ISO-aligned document templates and customization capabilities
- Variant Management in Jama Connect®, the key concepts required, and how it can revolutionize your workflow
- Insights into the nuances of navigating complex medical device software projects
- A brief exploration of the impact of US and EU regulations shaping the software landscape
Below is an abbreviated transcript of our webinar.
Effective Strategies and Solutions for Successful SaMD Project Execution
Romer De Los Santos: During this presentation, I’ll go over the challenges facing development teams working on medical device software, the key features of the Jama Connect SaMD Framework, and how you can use Jama Connect’s categories and reuse and sync features to manage releases and variants. A successful software development project in the medical device industry is a careful balancing act between documentation and development activities. Development teams have tight deadlines that are driven by market conditions. At the same time, they’re responsible for generating the required quality records according to each region where their device will be marketed. Since this isn’t a regulatory discussion, we’ll just focus on the EU and US as examples.
Medical device software development in the EU is governed by IVDR and MDR regulations. The risk classification in some software activities will differ depending on the regulation it falls under. Unlike in the US, there is no specific distinction between SiMD and SaMD software. It’s all considered medical device software. You’ll need to consider if the software you are developing is an accessory to a medical device or if is it a medical device on its own. If it is an accessory, it’ll need its own technical file. If it is sold as an integral part of the system, it should be included in the system’s technical file.
RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences
De Los Santos: In the US, there is a distinction between software in a medical device and software that is a medical device on its own. With the advent of AI, machine learning, cloud computing, and other innovations, the FDA has been drawing up new guidance to help modernize oversight on software development. The concept of device software functions are a key part of its modernization efforts. Each device software function has its own risk classification. The FDA has indicated that they intend to target their oversight over software that is an extension of one or more medical devices, software that transforms a mobile platform into a medical device by using attachments, displays, sensors, or including functions like a regulated medical device, software that performs patient-specific analysis and provides specific outputs or directives used in the diagnosis, treatment, mitigation, cure, or prevention of a disease or condition.
The Center for Devices and Radiological Health (CDRH) at the FDA created the Digital Health Policy Navigator to help manufacturers determine if their product’s software functions may be the focus of FDA oversight. This past September, the FDA released its new guidance on cybersecurity in medical devices. The guidance encourages the use of a secure product development framework when building software. It specifies some new deliverables such as a security risk analysis that is distinct from and in addition to the safety risk analysis specified in ISO14971.
Manufacturers will need to analyze security risks from the design and development phase through device maintenance and eventually to product end-of-life. Manufacturers are encouraged to use threat modeling to analyze security vulnerabilities in the environment where the device will be used. You’ll also need to consider all interfaces to and from the system and the Off-The-Shelf software (OTS) and Software of Unknown Provenance (SOUP) components that the system depends on. Software Bill of Materials (SBOMs) must be generated and analyzed for potential vulnerabilities. This represents more work for teams but is absolutely required in today’s interconnected world. In addition to all the required documentation for the design history file, developers also need to consider how to manage their fast development iterations, how to handle parallel development and variant and release management, how to properly triage and disposition defects, and how to manage third-party components that are part of their system.
RELATED: Jama Connect® for Digital Health Solution Overview
De Los Santos: The Jama Connect SaMD Framework is intended to alleviate some of the documentation burden while each company has its own procedures. The framework provides basic document templates that comply with requirements specified in IEC62304 and ISO14971. Furthermore, each document template includes a customizable export template for your convenience. It’s designed to keep things as simple as possible by minimizing the number of different item types and fields. The framework is versatile and includes the ability to trace to items outside of Jama Connect. This framework is designed to cover the most common use cases and is intended as a starting point for your own process. Jama Connect can easily be configured so that the tool adapts to your process rather than the other way around.
To watch the entire webinar, visit:
Effective Strategies and Solutions for Successful SaMD Project Execution
- [Webinar Recap] Effective Strategies and Solutions for Successful SaMD Project Execution - December 5, 2023
- Jama Connect® Features in Five: SaMD Framework - October 13, 2023