Medical software development and its potential issues

Due to recent events in the Medical devices’ market, the tendency to shorten development cycles has become very real. Several years ago, productizing a typical IVD would take up to two years and anything below that would be seen as an extraordinary (and almost heroic) effort. However, given the current public and governmental pressure for faster development of diagnostics devices (such as Covid-19, for example), many companies were forced to shorten the development cycle in quite a drastic way. Nowadays a typical project takes a year to complete; start-to-finish in 9 months is also not unheard of. However, this approach is forcing companies to rethink their attitude to third-party software, hardware and V&V process selection and to impose new requirements to software and silicon vendors.

A typical Medical project has to prove compliance to various regulatory standards, and even when the public is demanding faster product development, these standards aren’t going anywhere. As a result, no company can place their product on the market (EUA was an exception) without proving compliance to ISO13485, ISO14971, IEC60601 (or IEC61010) and a robust SDLC, normally associated with IEC62304. I am not going to describe each standard in detail (this article isn’t supposed to be “War and Peace” in size) but would just like to briefly mention their role in standard Medical device software development, from a Software perspective.

Note that the description above is overly simplified but I believe it should give enough information on what is required from the Software Team to do their job for Medical software development.  For the purpose of this article I will concentrate on IEC62304 requirements.

As in many industries (for example, Automotive with its ASIL), Medical software is also a subject for safety classification, called Software Safety Class (SSC), starting from level A (no unacceptable risks), through level C (risk of serious injury). Note that software classes aren’t the same as Device classes as defined in MDR and IVDR.

To put this into perspective, I recently became interested in mmWave technology, specifically in Texas Instrument IWR6843AOP for Vital Signs application. This seem to be an interesting piece of kit, which can detect a heartbeat or even do a touch-less ECG (for your convenience I’ve put some links at the end of the article, just in case you’re wondering what I am talking about). To determine the SSC for the software that will be using the device, we need to identify the Intended Use for the resulting product. For example:

This list is not exhaustive (obviously!) and some Medical companies may elect to up their game and reclassify the software to a higher level. For example, Apple Watch ECG functionality was classed at Software Level Of Concern (same as SSC but in FDA speak) to Class B, even if it is primarily for indicative use only.

Now that we have defined the role of software classification at the beginning of the formal process of the product development, let’s delve into two very significant topics: SOUP and Tools. While managing Tools is relatively straightforward (if it is used in formal development, validate it for use), the SOUP (or Software Of Unknown Provenance/Pedigree) is a more complicated story.

SOUP is something that is typically NIH (Not Invented Here), but not always. In general, if the software wasn’t designed under IEC62304 (or another robust SDLC, for which formally documented evidence exists), then it is classed as SOUP. For example, if an Algorithms team in the company are responsible for creating algo libraries, which are then incorporated into the software created by the Software team, then it may be treated as a SOUP within the realms of the Software Development and Software Test teams. Also, the standard doesn’t see a difference between Commercial Off-The Shelf (COTS) or Open Source software, so if there is no robust documentation set that is accompanying the software, then it is a SOUP. Even if I, as a software engineer, created perfect code at home to be used for my client’s project but I can’t provide the documentation stack for it (including V&V records), then it is SOUP, even if the client’s project is run by me.

The IEC62304 standard requires manufacturers to specify set of requirements (functional, performance, hardware and software) for each SOUP item, then do risk analysis on whether SOUP can introduce additional risks. This means that the teams are either forced to select manufacturer pre-validated SOUPs or do the validation themselves (writing requirements, analyzing risks, checking Open Issues List, doing formal validation, etc). The latter can be very time consuming and given the ever-reducing time schedules, difficult to achieve.

Silicon Vendors in the Medical Industry

Now let’s talk about the role of Silicon Vendors in the Medical Industry. In an ideal world, I should be able to go onto a manufacturer’s website, select a hardware solution, tick the “validated for Functional Safety” checkbox and get the software and all the applicable certification either free of charge (after all, such companies aren’t in software business, they are selling hardware solutions) or for a fee (which in many cases will still be cheaper than paralyzing the Test Team for several weeks if not months).

A typical Medical Device structure is as follows (simplified of course):

Very much all Silicon Vendors providing their customers with HAL/BSP, data processing libraries, design examples and extensive support information ranging from datasheets to fairly comprehensive “How do I …?” examples. This helps users to reduce their time to market and simplifies their development. For example, the IWR6843AOP comes with Vital Signs Lab support, where the theory of operation is explained, examples given and even the software to play with the device is provided. Pretty good then, isn’t it?

However (there is always a “however”!) my personal experience with HAL/BSP packages from various vendors hasn’t been very positive so far. In my experience the level of software quality and supporting documentation frequently falls short of that required for use in Medical Devices. Consequently such software should be analysed then a determination should be made on whether we can accept and use it as it is, or flag it for a re-write in order to make it compliant. Which is what many companies are doing – just rewriting vendor’s code in order to make it compliant (and to eliminate a SOUP item in the process).

While TI code is fairly well written (still fails MISRA checks with some issues detected, though), I am still presented with the challenge – shall I use it as a SOUP or not. Unlike many other solutions, this one comes with IEC61508 certificate for SIL3 (roughly equivalent to IEC62304 Class C), which kind of helps (at least I can be sure that the code was developed with Functional Safety in mind). The SOUP process still applies and the fact that MISRA checks fail, doesn’t make my tasks much easier. At least they have a Compiler Functional Safety qualification list, so I don’t need to validate the compiler as a Tool, which saves me time. It would be better for me if their software would come with IEC62304 even as a self-certification or a notified body certificate (which may be quite problematic as notified bodies are very reluctant to perform a formal standalone IEC62304 certification; they normally do it as part of ISO13485 audit, but that’s out of the question for silicon vendors as they aren’t Medical companies per se).

Which brings me to a definition of my selection process for hardware solutions:

Although the chart above is self-explanatory for the most part, let’s summarise the things I will be looking for during the process and assign an importance to every question on a scale 1 to 3, (1 being the most important to 3 is not important at all):

Conclusion

To summarise the above, there are two ultimate goals that needs to be fulfilled by any Medical device manufacturer:

• Create a robust, reliable and safe solution, which will perform within its Intended Use
• Do it quickly, with the fastest time-to-market possible, while maintaining the adherence to applicable standards

The Silicon Vendors play a very important role in this. If their solution isn’t reliable or require a significant effort to make it work, then the resulting product may not be as safe and reliable as it was intended to be. Likewise, the lack of certification and comprehensive support will increase time to market as companies would be forced to make an additional V&V effort in order to make the solution fully compliant.

In short, this is what I would like to see from Silicon Vendor’s offerings for the Medical market:

• Reliable and safe solutions
• Documentation stack that will help reduce time to market (see SOUP and Tools discussion above)
• Comprehensive training and support package to help develop a product in a timely and safe manner

All this will help me and my clients to develop Medical Devices that will achieve their ultimate goal – to help people live healthier and overall better lives.

Glossary

I understand that some of the terminology used in this article may not be familiar to all readers, so here is an explanation on what these TLAs mean

Links