Software Bill of Material (SBOM) for Medical Devices

Image: https://en.wikipedia.org/wiki/Operating_theater#/media/File:Hybrid_operating_theatre_gemelli_rome.jpg

Software Bill of Material (SBOM) for Medical Devices

Modern devices are becoming increasingly more complex. Higher user expectations for product features and connectivity have developers looking to include third-party code instead of creating functionality from scratch. Some of these third-party libraries are fairly large and complex. Having third party origins, you’re likely to find code that is maintained by other people on a completely different development cycle and with different development methodologies.

As with code, adding features also adds issues. For example, adding internet connectivity to any device brings the unwanted side effect of network security vulnerabilities to that device. For medical devices, this is a major concern. The FDA and CE Mark guidelines are placing more and more focus on cybersecurity and its implications on safety.

If third-party code is actively maintained, there is probably a bug tracking feature where current issues are being identified and fixed issues are recorded. For open source projects, this usually consists of a trip to the project’s code repository. For closed source projects, there might be a special website to view this information.

When complying with the IEC-62304 medical device software life cycle standard, there are requirements to regularly review the status of any included SOUP (Software Of Unknown Provenance) for known issues in the existing code (section 7.1.3). This review should also consider available updates, fixed issues, and changes in licensing. With this information in hand, informed choices can be made about the timing of version upgrades.

Depending on the size of the project, there might be several libraries involved. And those libraries possibly include other libraries, which rely on other libraries, etc. This usually snowballs a single feature into a list of lots of projects.

In an embedded project, the list of software libraries could include a networking stack like LwIP, or an operating system like FreeRTOS. A desktop application might include a database like MySQL or an AI package like TensorFlow.

So how do you keep track of all the software as it evolves and changes? You make a list. It’s a BOM (Bill of Materials), just like you would create for any type of assembly. At the simple end of the spectrum is a piece of paper with a list of components and libraries that have been used in the project. For each component, key information, such as the version number, author, license type, etc. should be listed. Someone can work through the list and update the fields as necessary with each review or change.

At the other end of the spectrum is software that’s designed to specifically tracks this information. For each piece of software, a number of fields create a database record that holds the various vital pieces of information. One record can point to other records, showing the relationship of the various pieces of software and making it less likely something will be overlooked.

Regardless of the method used, it’s imperative to have the means to track all the parts of your system. Then regular comprehensive reviews can take place and allow you to keep your records up to date to allow informed choices for the development and maintenance processes.

DojoFive brings modern tools, techniques, and best-practices from the web and mobile development environments, paired with leading-edge innovations in firmware to our customers to help them build successful products and successful clients. We have talented engineers on hand ready to help you with all aspects of your EmbedOps journey. Bring your interesting problems that need solving – we are always happy to help out. You can reach out at any time on LinkedIn or through email!