Written by Todd Brian, Validated Software.
This is the first in a series of posts about medical devices and software certification. Among the topics we'll explore in this series are:
- Off-the-shelf software, and the costs of saftey-critical products
- The regulatory environment for the medical device market
- Various industry standards for medical devices
We're going to define a medical device as any electronic device that uses software to perform its intended purpose within the health-care industry; the actual product might even be the software alone.
The Emerging Market for Medical Devices
In a 2007, a working group of participants from a variety of organizations, including the US Food and Drug Administration (FDA), the medical industry, think tanks, and academia collaborated on a report titled "Future Trends in Medical Device Technologies." The report discussed the direction of the medical industry.
The working group predicted that, within 10 years, home and tele healthcare will become firmly entrenched, so long as a supporting host of sensors, monitors and remote devices that are sufficiently advanced will become available to support these roles.
Some of their other predictions included:
Expensive medical testing will be replaced by devices that provide full-time monitoring, advanced detection, therapy, and active intervention. While many of those examples would likely be implemented in something beyond typical embedded devices, the survey included devices based on smart sensors, monitors, glucose-monitoring devices, and drug delivery systems as well.
The training of doctors will benefit from Internet-based medical databases and services. Virtual reality, robotics, and computer-aided diagnostics were all mentioned as technologies that will continue to grow over the next decade.
Software needed to make these devices operable can be seen in common smartphones and such other electronics as remote control, Bluetooth, Zigbee, and other wireless protocols. Fault tolerant file system or embedded databases would be the basis for delivery of powerful chemotherapy drugs, or even sending GPS coordinates to family members in an emergency, find more info about the top natural remedy that's used for several conditions.
Let's look closer at this subject of software to be able to see its impact on medical devices, and the important choices that must be made by designers.
Designers with experience in embedded device software know that software begets yet more software. Each line of code that enables a new “visible” feature requires 10 to 100 lines of code to support it. Let's take, for example, a new feature added to an existing defibrillator design. The goal is to record all information that is captured from the patient during a cardiac event, the defibrillator’s intervention, and post-intervention data, and store it for real-time and future use.
This is not an unreasonable goal. All of this information is currently available, such as information the defibrillator gathers and uses to determine the optimal intensity, frequency and duration of the electric shock it administers. However, in the past it used a simple memory file system to capture and analyze the cardiac data. Now it must convert the data to a common file system such as FAT32. Amazingly, adding what seems to be a trivial feature enhancement requires tens of thousands of lines of code.
Upgrades will not stop with a file system. Soon, a touch screen and 2-D and 3-D graphics will also be expected. In the not-too-distant future, the system should be tied into the health-care IT system using wireless communication. Now, with that level of system exposure, patient privacy and data concerns require even more software be added to protect the software that was just added. We’ll look again at this concept of cost per line of code.
For even the largest companies, staffing this kind of expertise is not only expensive, but it can undermine the company's value-add focus. Smaller companies and startups have no choice but to turn to third party “off-the-shelf” (OTS) software.
For many consumer products such as cell phones, third party software is easily used. That is not true in medical applications. OTS software is not easy to navigate and the not-invented-here (NIH) syndrome is strong in this industry, especially given the potential for litigation. While medical device manufacturers do use third-party software, it is not always developed with their specific needs in mind.
Perhaps that factor — the lack of custom fit of OTS software to a given task — is a contributor to the rapid increase in product recalls. We'll discuss that topic in part two of this series.