Did you wake up one morning with a great aspiration to help the world by designing a revolutionary medical device? Or are you in charge of a multibillion-dollar corporation with hundreds of medical devices on the market under your belt? Or perhaps somewhere in between? No matter what kind of company you run or what type of device you are manufacturing, software development will be a major part of your venture. Like it or not, devices that are not controlled by some kind of software are a thing of the past.
When developing software for your medical device, many of the challenges you will face are pretty standard in the software development world. There is simply no substitute for good developers, experienced architects, dedicated testing teams, solid development processes, or seasoned engineering management. For the purpose of this article, I will skip aspects related to software development in general and focus on issues specific to medical devices. The rest of this article is a 30,000-foot overview of the challenges Auriga’s engineers have run into while working on tens of medical device software projects of different shapes, forms, and sizes.
To set the stage, let’s talk about who needs new medical device software and why. Many of our customers already manufacture some type of device (did I mention this market’s stiff entry barriers? 😉 ). Sooner or later, the experienced players run into the “end of life” situation with the device they are manufacturing. Regardless of whether they are facing a shortage of the hardware components they’ve been using for many years or they are being undermined by a wise competitor who just released a new product with a slicker feature set, the time comes when a new generation of their product is due. It is important to point out that the product-release cycle in the medical device world is very long (in many cases, 5 to 7 years from inception to actual use in a hospital), so the importance of strategic long-term planning can’t be overestimated. Occasionally, we see a revolutionary breakthrough device that is defining a new market segment, but we more often see a more functional, better-performing, more user-friendly generation of something that already exists. Does that sound familiar?
Now that I’ve outlined who may benefit from our experience in that field, I will talk about some of the lessons we’ve learned over the years of working on medical device software projects.
1. Involve software team early
Ensure your software development team has solid experience working with hardware, embedded software, and operating systems. Get software engineers with that type of experience involved early, ideally at the initial stages of hardware design. This will save you tons of time and money later on. In many cases, hardware people will put together a design that “will work,” but your system-level software team will tell you what hardware is optimal for what operating system. Armed with the knowledge of the hardware they are working with and knowing the boundaries early on, your embedded software experts will help with answering questions like, Do we need multiple CPUs? Do we need a real-time operating system? How should we approach the BSP (Board Support Package) and HAL (Hardware Abstraction Layer)? What hardware drivers are available, and what will need to be written from scratch? You don’t want to compromise at this stage, as the design mistakes made here may be lethal (literally) down the road. Whatever you do, don’t forget to invite your system-level software guy to that meeting!
2. Your software team must have substantial IEC 62304 exposure
Invest in your software team’s training on the IEC 62304 and ISO 13485 standards and risk management standards. In recent years, these standards have de facto become your bible for developing medical devices and software for medical devices. Obviously, your software development process is only a part of your MQMS (Medical Quality Management System). But it is an absolutely essential part of it, so your software team must be well integrated into your overall MQMS.
What can be more important than getting your team up to speed on these standards? It is ensuring that the standards are being meticulously followed by the entire team. The software teams that are able to follow these standards are highly mature. Typically, these are the people with years of experience in writing mission-critical software for industries like aviation, medical, and defense. Our customers emphasize this frequently, because this level of maturity can’t be developed overnight.
3. Protect your algorithms by working with someone you trust
When you are manufacturing a device, what exactly is your IP? In many cases, it is not a new multicore CPU, sexy touchscreens, or cute marketing campaigns. More often than not, your IP is your mathematical algorithms and their software implementation. Successful product teams treat their algorithms as their most prized possessions. We’ve received algorithms as encrypted blocks (and we don’t take it as a lack of trust). And we’ve been hired to actually develop mathematical algorithms from the ground up. We’ve seen both extremes as well as situations in the middle. But whatever you do, treat your medical algorithms with respect. Only work with software teams you trust, and then protect yourself by following the appropriate legal processes.
4. Keep user experience simple and reliable
Usability is a vital aspect of your new device. Simply put, you may have the most reliable device on the market, but it won’t sell if it looks like something our grandmothers used, or does not give the doctor the information he needs to have at his fingertips, or does not adequately alert the nurse about an emergency. However, don’t overdo it! Keep in mind that your device must remain simple, straightforward to use, and reliable. A new cool feature that appeared on your iPhone out of the blue last month does not necessarily belong on your medical device. End users and clinical engineers are crucial to developing great medical software. Whatever you do, remember that your users have one of the most difficult jobs in the world (saving people’s lives!). They work under tremendous pressure. As software vendors, we need to do everything we can to simplify rather than complicate their jobs.
5. Modernizing your device does not have to be a complete redesign
As discussed earlier in this article, many of our large customers have a solid device (or tens of devices) on the market, but they are facing the challenge of face-lifting the device, making it more modern looking and user friendly. Recently, we worked on such a project in which the customer felt that the device was very functional and “worked fine” but “felt dated.” One of the possible solutions was to split the device into two separate devices. The original Class C (life-critical) device remained nearly unchanged, keeping the most critical indicators and controls. The additional (separate) device was a touchscreen with some new software. It provided convenience, non-essential reporting, and a modern look and feel. The second device was not Class C; it just talked to the original Class C device. This approach helped our customer save a tremendous amount of time and money during the FDA approval process.
6. Plan for device interoperability from day one
The days when two longhaired nerds and a dog could put together a serious medical device and install it in a local hospital are long gone. Of course, there is an exception to every rule, but most modern medical devices are very robust machines with multiple layers of software running on them. Moreover, they need to be able to talk to a variety of other devices and hospital information systems that may be from the same vendor or a variety of different vendors. The devices may need to talk to each other over different protocols, from legacy serial connections to Wi-Fi to Bluetooth to who-knows-what communication protocols will be available next year. This brings up the “interoperability” aspect of medical device software development. Your engineering teams need to ensure your hardware and software are designed for interoperability. Familiarizing yourself with the HL7 standard might be a great place to start!
Needless to say, this article only touches the tip of the medical-device-software iceberg (or, rather, several tips). But, if it made you think about how to organize your projects, it has accomplished its goal. Regardless of whether you decide to build your development team internally or get an external development company involved, do not compromise on these recommendations. Remember that we are talking about medical devices, so someone’s life may be on the line!
Please also watch our video about software for medical devices:
