Guest Column | May 11, 2022

Your How-To Guide: Developing Advanced Signal Processing Software For Medical Devices

By Kenneth L. Londoner, cofounder and CEO, BioSig Technologies, Inc.

Programming code GettyImages-871030872

Software is rapidly emerging as a critical product differentiator in the medical device industry. While launching an innovative product is no small feat, keeping your new device relevant and competitive may represent the greatest market challenge. New or enhanced software is critical to this endeavor, but the process of developing, upgrading, and expanding software capabilities is not without its own set of complications and hurdles to overcome.

Developing software for a medical device must consider what drives the product’s value by analyzing the market (i.e., the end user) while accounting for the feasibility, regulatory, and safety complexities associated with its use. Unlike many consumer-software companies, which can beta test new applications with a broad, diverse base of end users (and adjust based on consumer feedback), there is no beta testing equivalent for technologies that deal with patients’ lives and health. To put it simply, a medical product must 1) function and perform as designed, and 2) anticipate and resolve in advance every safety concern or potential risk associated with the use of the device.

While the software development life cycle described here is widely applicable to a wide range of medical devices, for the purposes of this analysis, my comments will focus on software development for cardiac devices — and more specifically, implementing advanced signal processing software into a cardiac device. But before diving into these specificities, let us turn to the beginning of the life cycle.

Identifying User Needs

During the first phase of the software development life cycle, formally known as the idea or concept phase, clinical experts will analyze the customer (the physician) and the market. Then, in consultation with clinical partners, cardiac experts will develop proposals for potential new product ideas or reasons for redesigns that could benefit the physician customers and, ultimately, the patients receiving treatment. From there, software engineers provide feedback on the proposals, considering feasibility, time, cost, and other associated requirements that may present development challenges. 

Design & Development

The design & development phase is where the bulk of the design work is conducted and documented, and where most of the expenses associated with developing a new product are incurred.  Once the product development terms have been agreed upon, the next step is establishing the user requirements specification (URS) and software requirements specification (SRS). Perhaps self-explanatory, the URS defines the user’s needs (the physician) while the SRS describes the exact functions and performance expectations of the software.1

Then, while the development engineers write the code to build out the software features, the software test engineers develop verification test design (VTD) cases  to demonstrate that the product operates in accordance with the intended requirements. VTD is one of the most critical aspects of the design and development process and is consistently cited as the number one issue during FDA inspections.2 Developed incrementally throughout the software development process, the VTD’s are the non-subjective progress reports that assess whether the software is meeting its intended end use and end user needs.3

The Importance Of Risk Management

If software deficiencies or failures are detected, engineering teams must work together to establish mitigation mechanisms.4 Risk management activities begin during the design & development phase and continue throughout the life cycle of the device. For example, if a software component does not function properly, a potential mitigation mechanism could be ensuring the deficiency will have no effect on patient safety. But mitigation mechanisms may not always be so straightforward. Depending on its risk management level, the issue may require the FMEA process and review by the Change Control Board (CCB). The Change Control Board is made up of representatives from the development team responsible for overseeing the development process.  They will convene on a regular basis to discuss any proposed software changes, challenges, defects, etc.

Organizations commonly overlook the role of the Change Control Board, and many projects fail due to a lack of CCB intervention.5 But early communications about changes and ensuring all relevant stakeholders are aware of the project requirements and goals are critical to the development process.

Incorporating Advanced Signal Processing

Advanced signal processing capabilities can address the widespread healthcare demand for more accurate, efficient tools for data analysis. Digital signal processing involves extracting and analyzing physiological information and data from the body to better inform clinical diagnosis or treatments.6 In the field of cardiology, signal processing software can offer physicians advanced cardiac signal information that may improve physicians’ workflow and decision-making and enhance procedural outcomes.

In cardiology and beyond, advanced signal processing capability is the definitive, innovative, underlying competitive advantage of the product itself.

Potential features of an advanced digital signal processing software include:

  • advanced filtering that removes noise or artifacts that could compromise the data integrity/validity;
  • the ability to deliver real-time, high-fidelity diagnostic signal data; and
  • customizable, personalized features that support the software’s integration into existing clinical practices and workflows.

Leveraging this type of innovative technology requires a well-executed software development process, requirements, and a team of engineers with the expertise to synthesize complex, abstract mathematics and algorithms. Embedding advanced software into a cardiac device relies on an information technology expert, known as a digital signal processing (DSP) engineer.

Competitive algorithms are based on the DSP engineer’s ability to analyze volumes of signal frequencies and amplitudes to develop the optimal algorithms that account for the end user’s needs, the goals of the hospital or healthcare organization, and the feasibility requirements established by software engineers, clinical trial results, and regulations.

User Interface: Intuitive Usability

Once the signal processing engineer has designed the optimal software algorithms, the engineer should validate their algorithm clinically, then collaborate with the software engineers to integrate the algorithms into the user interface. Throughout the development life cycle, the essential goal is to ensure the advanced software remains intuitive for the end user. Software usability is one of the biggest challenges in the medical device industry, so the user requirements established early on are critical throughout the development life cycle.

In my experience, the sole reason for incorporating an advanced signal processing software is to empower the end user with more efficient, accurate, and intelligent clinical data. As a clinical decision-making tool, the advantage of this type of software exists in both the superiority of the data it provides and the seamless delivery of that data to the users that need it.

Market Release & Postmarket Surveillance

After the development life cycle is complete and the product is ready for manufacturing and distribution, the role of the software engineer remains a critical piece of the puzzle. After the product launches, your company may track the end user’s experience to collect meaningful data and ensure product satisfaction. Clinical users’ feedback can also provide the building blocks for future software versions, upgrades, or adaptions when — you guessed it — the software development cycle starts over again.

References

  1. User Required Specifications, Cambridge Med Solutions, January 15, 2014: https://c-m-s.com/user-requirement-specifications/
  2. How to Design Medical Devices with Sustainability in Mind., Med Device Online, March 30, 2022:
  3. https://www.meddeviceonline.com/hub/bucket/industry-perspectives-manufacturing
  4. Design Validation and Regulatory Requirement, Medical Design Briefs, January 1, 2017:  https://www.medicaldesignbriefs.com/component/content/article/mdb/features/articles/26238
  5. Software Risk Management for Medical Devices MD+DI,: https://www.mddionline.com/news/software-risk-management-medical-devices-0
  6. Definitive Guide to Change Management for Medical Devices, Green Light Guru, January 22, 2021: https://www.greenlight.guru/blog/change-management-medical-devices
  7. Bio-Signals in Medical Applications and Challenges Using Artificial Intelligence, Swapna et al. Journal of Sensor and Acuator Networks. February 25, 2022. 

About the Author:

Kenneth L. Londoner is the cofounder and CEO of BioSig Technologies, Inc. He is a capital markets and capital architecture expert and a senior life sciences executive. Having started his career as a research analyst for J. & W. Seligman & Co., Inc., an institutional money management firm, he found himself at the forefront of the biotech industry in the early 1990s. His passion for medical innovation led him to cofound, govern, and bring to the public market several life sciences companies, including BioSig Technologies, Inc. BioSig aims to improve the outcomes of cardiac ablations for the treatment of arrhythmias.