Kenneth MacCallum

When should you use Open Source Software in Medical Devices?

Open Source Software (OSS) is software with a copyright license that includes the right to view and alter the source code and to distribute derivative works. Usually, OSS is available free of charge and therefore offers the possibility to get a significant head start on your medical device development.

In this blog, I’ll be talking about using OSS libraries within a Software System of a Medical Device or In Vitro Diagnostic Device. You’ll notice that I’m using all sorts of IEC 62304 terms. Incidentally, the general term for software that has not been developed in accordance with 62304 for your medical device or IVD is software of unknown provenance (SOUP).

There are many different licenses, from highly permissive ones (like MIT and BSD) that impose few if any restrictions on the legal use of the software to more restrictive licenses (like LGPLV3) which force you to release derivative works under a similar OSS license and stipulate providing the capability to the user of modifying or upgrading the library.

Why use it?

Some OSS has such a vast community of contributors and users that it’s rare to have a problem that someone else has not discovered, fixed or addressed with a work around. This is often more effective than paying for a maintenance contract with a proprietary software vendor. Many OSS libraries are simply solving a problem that has been well understood for ages and someone felt it was worth putting the software out there freely to save others the effort.

Don’t underestimate the advantage of having the source code. Documentation is great, but if you really need to know the nuances of how code works – or doesn’t work – you can’t do better than looking at the source. Anyway, sometimes you can’t help using OSS. It’s almost impossible nowadays to use an OS that does not have a substantial amount of OSS in it.

Why not?

There are still a bunch of valid reasons to avoid OSS. Plenty of terrible code is out there; this is true for both open and proprietary libraries. Just because something is available does not make it valuable. It is your responsibility to decide whether a library is truly suitable for your application. Even if you decide to embrace the use of OSS, you should still think carefully about whether a particular library will truly help you. Often it’s more work to incorporate existing SOUP than to write it from scratch. Also, if a software item is Class C, you won’t be using any code that was not developed under 62304, open source or not.

What about license gotchas!

When developing medical devices and IVDs, there are many regulations and guidances that must be followed and these are often interpreted as incompatible with many licenses. One valid concern that comes up frequently is clause 4d of the LGPLV3. This states that you must either enable the user to alter and recompile the library, or to swap out the library with a newer version. How can we be sure that the safety and efficacy of our device will not be impaired by such an occurrence? After all, we’re the ones who are responsible if an adverse event occurs and someone is harmed. One solution might be to simply avoid code with this license. Another solution is to evaluate the potential risk and mitigate only if necessary. A possible mitigation is to make it clear to the user that altering the software configuration of the device – just like altering the hardware of the device – could impair its function. This could be augmented with GUI warnings if alterations are detected.

What to do?

It’s highly likely that whatever happens you will end up using some OSS. With this in mind, here are a few things that you should do. Keep track of what OSS you’re using and the licenses. Incidentally for Class B and up, there’s a bunch of required tracking, documenting and testing of SOUP; the additional burden of tracking licenses is often not excessive. Read and understand the license of each library you are thinking of using. Fortunately, most OSS uses one of just a few main licenses; you’ll become familiar with them and understand the implications of each.

Sometimes it makes sense to evaluate the implications of one of the terms of a license during your Risk Management process. If you can mitigate, great. If you can’t then don’t use it.

Decide whether the terms of each license are compatible with your business model. If not, then you can’t use that library. If the license forces you to release a critical piece of intellectual property then you’re stuck. Note that in some cases the software might be available under an alternative, closed source license as well.

Evaluate the library to be sure you understand how to use it, how it works and its suitability for your application. As with any SOUP, it’s up to you and your team to gain sufficient understanding of it to use the libraries effectively. Note that you should go through this investigation early in your design process so you don’t have to change tack midway through.

What about bugs?

When you find bugs in OSS you will likely follow the same process of characterizing and searching for solutions as with any SOUP. With OSS you will likely do web searches, explore forums, reach out to the developers and finally if necessary, dig into the source and fix it.

I can think of quite a few times that a project I’m working on has been saved by making our own modifications to a library’s source. If you’re leveraging the thousands of hours of volunteer effort that goes into writing OSS and you find and solve an issue, I recommend that you push it back up or post it to give it back to the community.

So?

The use of Open Source Software libraries is almost a fact of life now in medical device development. I believe it’s a wonderful resource but – as with all SOUP – it must be carefully and purposefully managed to ensure the products we develop remain safe and effective.

Kenneth MacCallum, PEng, is a Principal Engineering Physicist at Starfish Medical. He works on Medical Device Development and loves motors, engines and trains as well as the batteries that power them. His blogs are standards in our annual Top Read Blog lists.

Image ID 53649975 © Aurielaki | Dreamstime

 

 

Commercialization Consult



6 responses to “When should you use Open Source Software in Medical Devices?”

  1. Steve Younger says:

    What about FDA requirements of traceability?

  2. According to the FDA’s guidance on the use of off the shelf software (OTSS), if the OTSS presents a minor level of concern (LOC) then only basic documentation is required. If there’s a higher LOC then further scrutiny, analysis and control is required.
    Practically speaking, for any big codebase, using open source software (OSS) is not that different from using arcane, proprietary libraries that no-one has looked in for ages, even if they were produced by your own company. You still need to analyze it for risks and control it appropriately. OSS offers the advantage of being able to look under the hood if you need to, as part of that analysis.
    As far as traceability is concerned, the FDA requires the same old connect-the-dots between requirements, hazards, and testing, regardless of the source of the software.
    An advantage of OSS is that you have the option to either lock down a particular binary or a particular version of the source tree, depending on your needs. Switching to different revisions of either is a very similar can of worms to either proprietary software or in-house developed software and will require that same sequence of requirements analysis, architecture, hazard analysis and verification in all cases.

  3. It is critical to not overlook the security issues associated with reuse of OSS. Not that OSS is any more or less secure than other software, but it does come with its own unique set of management challenges. Namely, when you license “OTSS”, the vendor is likely to be on the look out for security issues in their software and actively supplying fixes. When it comes to OSS, you are the only one capable of knowing what OSS you are using and if any of those components have, or are found at some point to have, any known vulns. Tracking your OSS components against, say the NVD, is not something most companies are prepared to do. Fortunately, there are automated tools that do the work for you.

  4. Thanks for the response Matt. I’ll expand your point a bit: as a medical device developer/manufacturer, you are likely the only one capable of knowing whether any SOUP – not just OSS – in your system poses a risk of harm, whether related to cybersecurity or patient and user safety. The key here is that your risk management process needs to continuously evaluate how harm could be caused by the use of SOUP in your system based on the latest information available to you. In many cases there is no security risk, but still a real risk of harm. In other cases it might be a security vulnerability such as you imply. It is good to know that there are tools to help keep informed on the latter.

  5. GV says:

    Question: This is for a SaMD clous based SaaS. We use a code scanner that spits out a list of some 4000 libraries being used. The list contains OSS that our application use ( Direct Dependency) and then OSS that our application uses, uses ( transitive dependency). All-in-all it comes down to ~4000 line items. How meaningful / useable is it to do an exhaustive risk assessment on all 4000 line items? 2. If we keep doing this who will develop the medical device? 3. Developers change , so do the open source libraries. This pace of change is rapid. How do we keep up? The way you’ve explained above, if we are to operate that way then I need a tiger team of 5 people doing nothing but OSS every release. Any guidance on how we can make this OSS meaningful to deal with

  6. Hi,

    I feel your pain! It’s certainly hard nowadays to avoid including a ton of SOUP, some of which is OSS. You’re right, it may be an insurmountable task to review and test all of that code. Keep in mind that the most burdensome requirements apply to class C software items, a little less so for Class B, and a bunch less for Class A. That means you may be able to carve the effort down a bunch through risk management and careful architecture – keeping the severity of harm low for the functions that utilize the bulk of those libraries. There is also the testing aspect of it: class B and C require substantial unit testing to reduce the probability of events that could lead to harm. Maybe some of that testing on your system can be automated?

    Keep in mind that this applies to all SOUP, not just OSS. If someone else developed the code or is maintaining the code, then you need to figure out how to use it safely in your medical application. IEC 62304 lays out the requirements of how you should go about this.

    Kind regards,
    Kenneth MacCallum
    Principal Electronics Engineer

Leave a Reply

Your email address will not be published. Required fields are marked *

Join over 6000 medical device professionals who receive our engineering, regulatory and commercialization insights and tips every month.

Website Survey

Please answer a few questions about our website.

Take Survey No Thanks