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.
|Standard||What is it for?||Who is managing it?|
|ISO13485||Defines the entire QMS (Quality Management System), specifies Design and Development Processes, etc||QA|
|IS14971||Defines risk management processes. For software it is clarified in IEC/TR 80002-1||QA or a dedicated Risk Manager|
|IEC60601||A series of standards with emphasis on electrical safety and essential performance. Defines Software SDLC among other things, but references IEC62304 as well||QA and Electronics Team with some input from Software and other teams|
|IEC61010||A series of standards, roughly similar to IEC60601, but specifically geared toward lab equipment and IVDs||QA and Electronics Team with some input from Software and other teams|
|IEC62304||Software development lifecycle (SDLC) for Medical software used in physical devices||QA and Software Team|
|IEC82304||Software development lifecycle (SDLC) for Medical software used in non-physical devices, such as software-only Medical Device (SAMD)||QA and Software Team|
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:
|Identify people’s presence in the room, without any medical purpose||Not a medical device, so not a subject to IEC62304|
|Check heartbeat for indicative purpose only||Class A|
|Check heartbeat for some irregularities but leave the diagnosis to a trained medical professional||Class B|
|Monitor hospital patient for sudden arrhythmia or cardiac arrest signs, then raise an alarm in case something is wrong||Class C|
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):
|Solution availability (both from engineering and operations perspective)||I’ve got a problem and need to check whether some Silicon Vendor has a solution for it. If not, then I can either adjust my requirements or design some sort of a solution myself, time/money permitting.
From operations perspective, there is no point for me to select a device with 108 weeks lead time; my device will be late to the market.
|Performance and support||The performance question is fairly simple – can it do what I want or not? If it can’t then there is no point going any further. If it can, then how do I prove that what they say is correct?
Which brings me to the support topic. A perfect Hardware solution without any documentation or software support is the same (at least in my eyes) as no solution at all.
|Evaluation kit and demos||It is often not possible to evaluate a solution just by browsing technical documentation. Anyone who ever had to select any product, starting with microprocessor and ending up with a washing machine, would surely agree.
Engineers need to try things, play with it, before they can come up with a conclusion. How else can they be sure it is good enough for the task?
|Functional Safety standards compliance||If there are two competing solutions on the market, both are equally suitable for me and one has at least some of the certifications/documentations while other don’t, then I will go for the one with Functional Safety pedigree any day.
If there are no devices with Functional Safety support, then I would be forced to do SOUP risk and requirements analysis, to validate it for use, which will have an impact on my time-to-market and budget schedules.
This means that for a Silicon Vendor it would be a significant competitive advantage to have this kind of certification, unless they have all the market to themselves, which is rarely the case.
|3rd-Party support and libraries||This is very much nice-to-have. If there are ready-made solutions (such as signal processing libraries for the hardware solution we’ve chosen), then I might look into this.||3|
|Training||As I’ve mentioned before, the development cycles in the Medical industry are being reduced to a minimum. The easiest way to start with a new device is to have training provided by the Silicon Vendor||2|
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.
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
|ASIL||Automotive Safety Integrity Level (risk classification as per ISO26262)|
|BSP||Board Support Package. A collection of code that can make devices on a specific board operational; in other words – a collection of drivers for specific hardware|
|COTS||Commercial Off-The Shelf [software]. A computer program (or part of thereof) that has been acquired commercially|
|ECG||Electrocardiogram. A snapshot of heart’s rhythm and electrical activity|
|EUA||Emergency Use Authorization. A fast-track route for letting Medical devices and drugs onto US market, normally used in emergency situations, such as pandemics|
|FDA||Food and Drug Administration. Governmental Regulatory body in the United States of America|
|HAL||Hardware Abstraction Layer. A collection of low-level drivers enabling operation of a specific hardware|
|IVD||In-Vitro Diagnostic [device]. A class of medical diagnostic equipment|
|MISRA||Motor Industry Software Reliability Association. A consortium that is publishing widely accepted coding standards for C and C++|
|QMS||Quality Management System. A formalized system that documents processes, guidelines, procedures and responsibilities|
|SAMD||Software As a Medical Device. A hardware-less medical device, such as healthcare app on a smartphone|
|SDLC||Software Development Lifecycle. Defines a process for software development|
|SIL||Safety Integrity Level (risk classification as per IEC61508)|
|SLOC||Software Level of Concern. Software risk classification as per FDA guidelines|
|SOUP||Software of Unknown Provenance. A software that is used for Medical device but either “Not invented here” or designed by a team that doesn’t follow IEC62304|
|SSC||Software Safety Classification (risk classification as per IEC62304)|
|TLA||Three Letter Acronym (but you’ve already guessed it, right?)|
|V&V||Validation and Verification|
|Vital Signs Lab|
|Vital Signs + People Tracking|
|Training videos for Vital Signs Lab|