Developing medical devices with software involves a wide-ranging set of unique challenges. We asked our software engineering team for their tips and suggestions. They offered advice covering Software in medical devices, FDA, Software as a Medical Device (SaMD), risks, cybersecurity, and Open Source software.

This blog offers 13 tips for developing software for medical devices.

Risks and Security

Understand the harms of the device. That’s a critical starting point for everything else you’re going to do. If you don’t know what the harms are, you won’t know where to focus your efforts and development. You won’t know how much complexity you need to add to the software how much segregation, how much redundancy. Understanding the harms and how the software contributes to them is a key. Absolutely critical for software development in medical devices.

Make sure to ask questions and try to thoroughly understand the device, especially when dealing with medical equipment and its associated security. Having a comprehensive grasp of the device’s functions and intended use will enable developers to make informed decisions. Additionally, understanding the device’s intended usage will aid in identifying potential risks to users or the device itself.

Security is an important part of designing software for medical devices. Any potential communication with a medical device has to be secure and encrypted in order to meet medical device regulations. One of the best ways to do this is to make use of established cryptographic communication protocols, such as Transport Layer security (TLS). That’s the same sort of protocol that a banking website might use to secure its communications.

The security protocol makes use of signing certificates. The device verifies before allowing any communication. These are like a set of keys and locks for the device, ensuring that any communication comes with the right key to a lock that the device holds. We help clients set up a cryptographic certificate signing authority system as a reliable, controllable and secure way to ensure that all communications and application of their medical device is safe and sound.

Modular Design

Keep software modular. Breaking the software down into smaller components provides the opportunity to test those small components. It also makes keep tracking of risks and harms enabling a more thorough job making sure software is written correctly.

During product development, execution of the design verification itself takes around 60% of the medical device design life cycle. The design development itself receives a lot of attention, which should only account for 30% of the total, but instead uses around 70% and puts the device verification under pressure to complete the task in 30% of the time. So, to avoid such situations, involve design verification strategies from day one. Always work on the principle of “Test as you fly and fly as you test”. Make sure to collect data from each stage, adding to the regression testing itself, from the start itself. That will help gain more confidence in the device.

Testability

Design things to be testable. This is super important depending on the size and scope of the device. Particularly if it has multiple components within the software. The ability to confirm that the output of a component is what it’s supposed to be enables traceability quickly and easily to where the possible problem is. Whether conducting validation testing at the end of the line, or when something is not going right for one of the project developers, the ability to locate the problem (or what the problem isn’t) quickly and easily is so nice. You may not realize how important this is, but when software is not testable, you will really miss it.

Once a device is testable, verify the results to see if there are any inaccuracies. If there are, develop algorithms to mitigate those inaccuracies and provide improvements based off them.  Then, document and provide a method to retrace what caused the initial errors and how they are being mitigated.

FDA

Every device is unique and has its own application, but often fits into categories and has some commonalities to existing devices. The FDA recognizes this with their 510(k) pathway when there are predicate devices. If you have access to previous designs, you can reuse some of the know-how to address common problems and issues with a particular type of device.

Become familiar with the plethora of guidances and standards that the FDA provides for a similar device to help build robust and safe software. Software in medical devices often goes beyond traditional tech approaches to risk management. For instance, in September of 2023, the FDA released a new guidance for cybersecurity in medical devices. Identify whether there are important applicable considerations or key requirements that will impact your software. This helps focus development with specific goals in mind.

Source of Software

When incorporating or basing your software off legacy code or code that you license, don’t be too attached to it. Understand how it works, but if the device is dependent purely on that implementation, look closely at why and whether you should use that old code or produce something new that’s a bit cleaner, nicer and easier to work with.

Be really careful with open-source software. Licenses often include elements where developers do not actually own any kind of the code or the software they develop around it, including the intellectual property. We use SBOM Studio, a tool to create the SBOMs. It rolls up all the different licenses and puts them all in one place. That makes it easier to look at them and determine if they fit the model for what we’re building.

Open source has a conflict with medical devices because they want to be as full featured and as rich as possible. Testing is a major part of the medical device lifecycle. One would not want to verify and validate extra features that may not actually be relevant to the device. It’s great for prototyping in the early stages, but it would be very rare to include it in a final, medical device.

User Experience

The quality of any software-based product, including medical devices, is perceived not only in terms of technical effectiveness but also by its adherence to User Experience Design principles and quality standards. Consumers and professionals interact with user-friendly and aesthetically pleasing devices in daily activities: adjusting the temperature of their homes with smart thermostats, checking the weather with their smartphones, or counting calories burned during a workout session.

Our tips for developing medical devices with software are far from exhaustive. We’d enjoy hearing from readers their favorite tips or pet peeves when it comes to developing or using medical devices that Include software. Read more blogs on medical device software or contact our team if you are interested in discussing your medical device development needs.